Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тоже не возражаю. Правда, ИМХО дело не в сахаре, а в том, что по реальным потребностям выполнить некую выборку или змену для всего набора имеет смысл часто, а вставляют все же чаще по одной. Жизнь такова

Жизнь она разная бывает. Не стоит так категорично
Кстати в большинстве OLTP update и delete (да и select тоже, что греха таить)
ТОЖЕ идут по одной записи

T>>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.

R>Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему.

Причём здесь "на слабо"?

Вот тебе интересна какая-то тема. Её надо обязательно изучить. Любое теоретическое изучение будет неполным, поэтому надо изучить практически.

Значит, надо сделать систему.

Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.

R>Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.

Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.

R>По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.

А если она не решается? Ась?

(вообще-то решается, конечно, но отнюдь не простым вставлением par и pseq. Преобразования будут потяжелее. И для разных типов систем — синхронные, асинхронные — разными, с разным результатом.)

T>>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки.
R>Так проблема была в низкой гранулярности?

Не "была", а "будет".

Это я рассуждал о будущей системе, которую я сейчас прикидываю.

R>По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.

Её, как и всё остальное, надо проверять.

Бремя доказательства лежит на высказавшем.

R>>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.

T>>Э-эх.

R>Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.

Я про другое.

Ты сперва добейся независимой работы этой сотни агентов.

А то ты о самом сложном говоришь, как о решённой задаче.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Так если набор, почему же ты не согласен, что мы именно с набором и оперируем ?
Я не согласен с тем, что "там где-то внутри цикл".

В SQL циклов нет — есть именно что наборы. Есть операторы понижения мерности наборов — на вполне любую величину. Есть операторы повышения мерности.
Реальное ограничение теоретического SQL только одно — он оперирует предикатами первого порядка.
Но это же не размерность данных!

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Я тебе тоже объяснял, что дело вовсе не в реляционной алгебре.
Вот этот момент мне так и не понятен.
PD>Да кто же спорит, Антон ? Я разве сказал, что не оперирует ? Я просто сказал, что оперирует и с отдельными записями.
Ты и споришь. Ты, по какой-то неясной мне причине, докопался до insert.

>>Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию?
PD>Да нет, конечно, не трудно, но я никак не пойму, в какой ошибке ты меня упрекаешь ? В реляционной алгебре ? Я же объяснил, что не о ней речь.
В трактовке реляции как линейного массива и трактовке SQL как сокращенной записи цикла.

PD>По диагонали тоже ?
Если ты переформулируешь задачу от "шахматных" терминов к реальным, то окажется, что номер диагонали — это сумма row и column, и SQL вполне себе позволяет вот такой запрос:

select row+column as diagonal, sum(value) as diagonalSum from matrixData group by row+column

Невозможными в SQL являются совсем другие запросы.

PD>Именно к LinQ.
Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Я тебе тоже объяснял, что дело вовсе не в реляционной алгебре.
S>Вот этот момент мне так и не понятен.

Да что же тут непонятного. Ладно, еще раз. Есть оператор языка, который работает с набором, но при этом не обращается к отдельным элементам. Как он там внутри работает — мне все равно, а поэтому реляционная алгебра тут ни при чем. В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать.

PD>>Да кто же спорит, Антон ? Я разве сказал, что не оперирует ? Я просто сказал, что оперирует и с отдельными записями.
S>Ты и споришь. Ты, по какой-то неясной мне причине, докопался до insert.

А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные

Кстати, в SQL есть-таки работа с отдельными элементами не только для вставки. Я об этом просто забыл, а ты не напомнил, может потому, что в C# это не очень популярно, скажем так. Думаю, ты догадался, о чем речь идет. Курсоры. Типичный IEnumerable. Работает с отдельными записями набора.

>>>Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию?
PD>>Да нет, конечно, не трудно, но я никак не пойму, в какой ошибке ты меня упрекаешь ? В реляционной алгебре ? Я же объяснил, что не о ней речь.
S>В трактовке реляции как линейного массива и трактовке SQL как сокращенной записи цикла.

Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром.

PD>>По диагонали тоже ?
S>Если ты переформулируешь задачу от "шахматных" терминов к реальным, то окажется, что номер диагонали — это сумма row и column, и SQL вполне себе позволяет вот такой запрос:
S>

S>select row+column as diagonal, sum(value) as diagonalSum from matrixData group by row+column 
S>

А что такое row и column ? И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов.

Если же речь идет о моем вымышленном языке, то там не реляционная алгебра вообще будет, а некий "матричный набор действий". Вырезать подматрицу. UNION двух матриц. Сложение и умножение их. И т.д. И вырезать диагональ даст вектор а не набор элементов у которых row+col == const.


PD>>Именно к LinQ.
S>Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?

В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный. Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Так если набор, почему же ты не согласен, что мы именно с набором и оперируем ?
S>Я не согласен с тем, что "там где-то внутри цикл".

Принимается. Корректирую свое высказывание — где-то там есть в большинстве случаев некая массовая операция (то есть операция хуже чем O(1)). Годится ?

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Тоже не возражаю. Правда, ИМХО дело не в сахаре, а в том, что по реальным потребностям выполнить некую выборку или змену для всего набора имеет смысл часто, а вставляют все же чаще по одной. Жизнь такова

G_K>Жизнь она разная бывает. Не стоит так категорично

Нет, не согласен.

Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Именно к LinQ.
S>>Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?

PD>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный. Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.

Если ты про тот топик, где тебе показывали решение для работы с матрицами через линк, то на твое предложение пройти по диагонали, тебе там же и объяснили, что источником данных служит IEnumerator, который как раз и задает порядок обхода изначальной структуры. При этом его в шарпе очень легко описать для обхода матрицы в любом порядке — хоть по строкам, хоть по столбцам, хоть по диагонали, хоть змейкой, хоть случайной выборкой...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да что же тут непонятного. Ладно, еще раз. Есть оператор языка, который работает с набором, но при этом не обращается к отдельным элементам. Как он там внутри работает — мне все равно, а поэтому реляционная алгебра тут ни при чем.
Как это ни при чем? Операторы как раз реализуют расширенную реляционную алгебру.

PD>В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать.
Ок, понятно.

PD>А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные
Нет. Не будет никаких проблем. Можно вставить сразу набор. Совершенно необязательно для этого вствлять "отдельные" записи.
Всё, что нужно — это иметь конструктор наборов. Точно так же, как С++ поддерживает константы определенных типов, SQL достаточно поддерживать описание констант типа "набор".

PD>Кстати, в SQL есть-таки работа с отдельными элементами не только для вставки. Я об этом просто забыл, а ты не напомнил, может потому, что в C# это не очень популярно, скажем так. Думаю, ты догадался, о чем речь идет. Курсоры. Типичный IEnumerable. Работает с отдельными записями набора.
Курсоры — это "тёмная сторона силы". Без них SQL продолжит корректно работать.

PD>Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром.
Совершенно верно. Есть массовые операции. И если хочется поговорить о проблемах SQL, то нужно это учитывать.

PD>А что такое row и column ?
Как что? Это компоненты составного ключа.
PD>И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов.
Совершенно верно. Я уже говорил, что реляция — это набор фактов, т.е. кортежей. Факт — это точка в N-мерном пространстве.
Если в реляции нет записи с координатами (0, 0), то такого факта нет.

PD>Если же речь идет о моем вымышленном языке, то там не реляционная алгебра вообще будет, а некий "матричный набор действий". Вырезать подматрицу. UNION двух матриц. Сложение и умножение их. И т.д. И вырезать диагональ даст вектор а не набор элементов у которых row+col == const.
Вектор в SQL — это реляция с одномерным ключом. Поэтому вырезание диагонали — это ровно "набор элементов, у которых row+col == const". По определению.
Вырезание подматрицы, UNION двух матриц и прочие пожелания прекрасно выражаются операторами реляционной алгебры.


PD>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный.
Это заблуждение.

PD>Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.
Почему не понравилось? Тебе привели решения с перебором матрицы по диагонали. При желании можно хоть шахматным конем ее перебрать.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу

Можно, Павел, можно. Учим матчасть.
Вот тебе простой пример:

insert into People(name) 
  select "Павел"
union
  select "Антон"

На всякий случай напомню, что здесь фигурирует три реляции. Две из них сконструированы при помощи специального синтаксиса оператора select, который возвращает "реляцию из одной записи", а третья — при помощи union первых двух.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Принимается. Корректирую свое высказывание — где-то там есть в большинстве случаев некая массовая операция (то есть операция хуже чем O(1)). Годится ?
Годится, но пользы от такого высказывания — o(0).
Потому, что
а) "в большинстве случаев" — утверждение крайне размытое. С тем же успехом его можно заменить на "иногда" или "может статься, что".
б) Не очень понятно, асимптотику от какого параметра мы сравниваем с O(1).
в) Не очень понятно, почему мы вообще критерием "массовости" операции мы ставим ее затратность. Затраты на операцию в SQL, вообще говоря, зависят далеко не только от ее аргументов.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете

Не согласен (c) Нельзя выбрать одну запись или таблицу
Можно выбрать набор из одной записи или всех записей таблицы

PD>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу

insert into test(id)
select rownum from dual
group by cube (1,1,1)

Здравствуйте, Sinclair, Вы писали:

S>Годится, но пользы от такого высказывания — o(0).

Ну нет

S>Потому, что
S>а) "в большинстве случаев" — утверждение крайне размытое. С тем же успехом его можно заменить на "иногда" или "может статься, что".

Антон, ты прекрасно понимаешь, о чем я говорю. Естественно, SELECT count(*) from tbl не есть массовая операция. И другие есть. Но если запрашивается набор, то это массовая операция. И т.д.

S>б) Не очень понятно, асимптотику от какого параметра мы сравниваем с O(1).

Количество записей. Для простоты одну таблицу рассмотрим. Если линейный выбор — O(N), иначе O(log(N))

S>в) Не очень понятно, почему мы вообще критерием "массовости" операции мы ставим ее затратность.

А где это я про затратность в применении к SQL вообще говорил ?. Я тут вообще молчу — заменить LinQ конструкцию я могу, а SELECT чем я заменю ? Остается просто принимать как есть. Что тут обсуждать — разве что качество ее реализации в разных БД.

>Затраты на операцию в SQL, вообще говоря, зависят далеко не только от ее аргументов.

Безусловно.

Здравствуйте, Sinclair, Вы писали:

S>Можно, Павел, можно. Учим матчасть.
S>Вот тебе простой пример:
S>

S>insert into People(name) 
S>  select "Павел"
S>union
S>  select "Антон"
S>

Спасибо за совет, мне такое действительтно не приходило в голову , но суть дела это мало изменяет. Посоветуй такой способ ввода данных в реальных формах


S>На всякий случай напомню, что здесь фигурирует три реляции. Две из них сконструированы при помощи специального синтаксиса оператора select, который возвращает "реляцию из одной записи", а третья — при помощи union первых двух.

Спасибо за разъяснение

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете

G_K>Не согласен (c) Нельзя выбрать одну запись или таблицу
G_K>Можно выбрать набор из одной записи или всех записей таблицы

Да, я же об этом и псал чуть раньше. Неточно выразился, сорри.

PD>>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу

G_K>insert into test(id)
G_K>select rownum from dual
G_K>group by cube (1,1,1)

Ну не знаю. dual — это что ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gluk_Kazan, Вы писали:

G_K>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете

G_K>>Не согласен (c) Нельзя выбрать одну запись или таблицу
G_K>>Можно выбрать набор из одной записи или всех записей таблицы

PD>Да, я же об этом и псал чуть раньше. Неточно выразился, сорри.

PD>>>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу

G_K>>insert into test(id)
G_K>>select rownum from dual
G_K>>group by cube (1,1,1)

PD>Ну не знаю. dual — это что ?

фиктивная табличка в Oracle. Когда нужно вернуть данные откуда угодно, но не из этой таблицы
В отличии от MSSQL в Oracle фраза from обязательна

Здравствуйте, Sinclair, Вы писали:

PD>>В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать.
S>Ок, понятно.

Ну слава богу

PD>>А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные
S>Нет. Не будет никаких проблем. Можно вставить сразу набор. Совершенно необязательно для этого вствлять "отдельные" записи.
S>Всё, что нужно — это иметь конструктор наборов. Точно так же, как С++ поддерживает константы определенных типов, SQL достаточно поддерживать описание констант типа "набор".

Ладно, принято. я об этом уже писал.

PD>>Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром.
S>Совершенно верно. Есть массовые операции. И если хочется поговорить о проблемах SQL, то нужно это учитывать.

Нет, о проблемах SQL я говорить не хочу. Не моя это тематика. Я в SQL только благодушный дилетант

PD>>И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов.
S>Совершенно верно. Я уже говорил, что реляция — это набор фактов, т.е. кортежей. Факт — это точка в N-мерном пространстве.
S>Если в реляции нет записи с координатами (0, 0), то такого факта нет.

А я тебе говорю отнюдь не про SQL и реляции. В общем, один про Фому, а другой про Ерему. Давай закроем эту часть.

S>Курсоры — это "тёмная сторона силы". Без них SQL продолжит корректно работать.

Но они есть. "Если звезды зажигают, значит, это кому-то нужно"


S>Вектор в SQL — это реляция с одномерным ключом. Поэтому вырезание диагонали — это ровно "набор элементов, у которых row+col == const". По определению.
S>Вырезание подматрицы, UNION двух матриц и прочие пожелания прекрасно выражаются операторами реляционной алгебры.

Точно про Фому и Ерему


PD>>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный.
S>Это заблуждение.

PD>>Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.
S>Почему не понравилось?

Он это "кривым обходом" обозвал

>Тебе привели решения с перебором матрицы по диагонали. При желании можно хоть шахматным конем ее перебрать.

Здравствуйте, AndrewVK, Вы писали:

MC>>Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками.

AVK>Что значит параллель? Оригинальный SQL, без императивных расширений, это и есть функциональный язык.

Декларативный он, да. Но не функциональный ни в одном месте.

Здравствуйте, fmiracle, Вы писали:

F>Чего ты хочешь? Такой инсерт, который пишется вручную, но при этом позволяет вставить сразу несколько записей? Сделать его не проблема, только в нем никакой пользы по сравнению с серией одиночных инсертов. Вот его и не добавили.

В MySQL есть.

INSERT INTO tab (col1,col2..) VALUES (val11,val12...),(val21,val22...),...

Здравствуйте, AndrewVK, Вы писали:

Хорошо, ты не согласен. Объясни, пожалуйста, возможно, я заблуждаюсь — почему ты считаешь "оригинальный SQL, без императивных расширений" функциональным?