Здравствуйте, samius, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В общем-то верно. Добавляется одна запись. Но тогда ФП не есть замена императивному коду, а только дополнение. Так ? S>Не замена, не дополнение, а альтернатива.
А в чем разница между заменой и альтернативой в данном контексте ? ИМХО если альтернатива — то можно на нее полностью перейти (заменить), ну а если дополнение — перейти можно в части того, где это дополнение работает.
S>Не нужно копировать ВСЕ BST ради вставки одного элемента. Кол-во вновь созданных элементов при любом "изменении" не превышает высоту дерева (изменение в ковычках потому как дерево не меняется). И вставлять придется не в существующее дерево, а в новое дерево, которое будет в основном состоять из старых элементов.
Ну нет, такое мне не надо. За каким богом мне дублировать эту массовую структуру при каждой SearchAndInsert. Я его и BST ценю за log N,
S>Вот код, совместимый с предыдущими примерами:
S>[c#] S> static Node<T> Insert<T>(this Node<T> tree, T value) S> { S> if(tree == null) S> return new Node<T>(value, null, null);
Это понятно.
S> var eq = Comparer<T>.Default.Compare(tree.Value, value); S> if (eq == 0) S> return tree;
И это тоже.
S> return eq > 0 S> ? new Node<T>(tree.Value, Insert(tree.Left, value), tree.Right) S> : new Node<T>(tree.Value, tree.Left, Insert(tree.Right, value));
S>Для модификации данных использовать LINQ однозначно зло! Но если дерево мутабельное, то можно сделать следующим образом: SearchAndInsert вызывает поиск узла с value и если его нет, то чтобы вернул узел, куда будем вставлять новый. Это делается линком. После того как узел получен, SearhAndInsert делает небольшой анализ и либо возвращает его, либо создает новый узел и модифицирует существующий. Т.е. мы не модифицируем Search->SearchAndInsert, а делегируем SearhAndInsert=>SearchForInsert.
S>Пойдет? И LINQ замешан и Insert есть, причем даже императивный/модифицирующий.
Вполне. Правда, он должен вернуть не только узел, куда вставлять, но еще и куда (Left-Right). Но на императивном варианте это неудобно. Там реально возвращают адрес нулевого указателя, который надо заменить на результат вставки.
PD>>Если речь идет о дереве — то оно базируется все же на концепциях структур данных, которые опять же ИМХО ни от чего не зависят, ибо базис.
S>Павел! Без обид, у Вас базис не полный.
А у кого он полный ?
>Изучите функциональные подходы для работы со структурами данных.
Извини, но разве функциональный подход что-то может изменить в структурах данных ?. Я же не об алгоритмах говорю.
Влад утверждает, что дерево — это последовательность. Если речь идет о пути поиска минимума или просто поиске в BST — согласен, это последовательность. Но если речь идет о просто дереве, то, разумееется, можно в нем придумать способы последовательного обхода, но называть дерево последовательной структурой...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
PD>А в чем разница между заменой и альтернативой в данном контексте ? ИМХО если альтернатива — то можно на нее полностью перейти (заменить), ну а если дополнение — перейти можно в части того, где это дополнение работает.
В моем понимании замена — это значит выкинуть старое и применить новое. А альтернатива — это когда можно выбирать.
PD>Ну нет, такое мне не надо. За каким богом мне дублировать эту массовую структуру при каждой SearchAndInsert. Я его и BST ценю за log N,
log N справедливо и для ФП подхода.
S>> return eq > 0 S>> ? new Node<T>(tree.Value, Insert(tree.Left, value), tree.Right) S>> : new Node<T>(tree.Value, tree.Left, Insert(tree.Right, value));
PD>А вот это нет. Почему не
PD> return eq > 0 PD> ? Insert(tree.Left, value) : Insert(tree.Right, value));
Потому что узлы не модифицируемые и на каждом этапе нужно создать новый.
S>>Пойдет? И LINQ замешан и Insert есть, причем даже императивный/модифицирующий.
PD>Вполне. Правда, он должен вернуть не только узел, куда вставлять, но еще и куда (Left-Right).
Проще вернуть один узел и проанализировать его, ведь вставлять может не потребоваться. А если потребуется, то после анализа будет ясно, в какую сторону.
>>Изучите функциональные подходы для работы со структурами данных.
PD>Извини, но разве функциональный подход что-то может изменить в структурах данных ?. Я же не об алгоритмах говорю.
Что есть структура данных без способов работы с ней?
PD>Влад утверждает, что дерево — это последовательность. Если речь идет о пути поиска минимума или просто поиске в BST — согласен, это последовательность. Но если речь идет о просто дереве, то, разумееется, можно в нем придумать способы последовательного обхода, но называть дерево последовательной структурой...
Более чем уверен что Влад утверждал о последовательности именно как о способе обхода дерева.
S>В моем понимании замена — это значит выкинуть старое и применить новое. А альтернатива — это когда можно выбирать.
Ну ладно, не будем спорить о дефинициях
PD>>Ну нет, такое мне не надо. За каким богом мне дублировать эту массовую структуру при каждой SearchAndInsert. Я его и BST ценю за log N, S>log N справедливо и для ФП подхода.
S>>> return eq > 0 S>>> ? new Node<T>(tree.Value, Insert(tree.Left, value), tree.Right) S>>> : new Node<T>(tree.Value, tree.Left, Insert(tree.Right, value));
PD>>А вот это нет. Почему не
PD>> return eq > 0 PD>> ? Insert(tree.Left, value) : Insert(tree.Right, value)); S>Потому что узлы не модифицируемые и на каждом этапе нужно создать новый.
Вот! Именно об этом я и говорю. Код, который ты написал, по сути ничем не отличается от моего — в плане алгоритма. Но я не создаю ничего, кроме одного new элемента и модификации одного указателя (на него). А ты пересоздал зачем-то элементы. Не слишком дорогая плата ? Тем более. что мою рекурсивную SearchAndInsert ты все равно переписал, и даже она длинее (в байтах текста кода)
S>>>Пойдет? И LINQ замешан и Insert есть, причем даже императивный/модифицирующий.
PD>>Вполне. Правда, он должен вернуть не только узел, куда вставлять, но еще и куда (Left-Right). S>Проще вернуть один узел и проанализировать его, ведь вставлять может не потребоваться. А если потребуется, то после анализа будет ясно, в какую сторону.
Согласен. Хотя мне алгоритм со вставкой по ходу действия кажется логичнее и яснее.
PD>>Извини, но разве функциональный подход что-то может изменить в структурах данных ?. Я же не об алгоритмах говорю. S>Что есть структура данных без способов работы с ней?
Хм... Все же структура первична, а алгоритмы ИМХО вторичны. Структура данных двоичное дерево есть структура, в которой у каждого элемента не более дух потомков. И это все. Пока все. Это разветвленная структура. Как обходить, к примеру, это дерево — это другой вопрос, кстати, и способов аж 4 есть.
PD>>Влад утверждает, что дерево — это последовательность. Если речь идет о пути поиска минимума или просто поиске в BST — согласен, это последовательность. Но если речь идет о просто дереве, то, разумееется, можно в нем придумать способы последовательного обхода, но называть дерево последовательной структурой...
S>Более чем уверен что Влад утверждал о последовательности именно как о способе обхода дерева.
А это бога ради. В конце концов ваша любимая сериализация и есть в конечном счете обход произвольной структуры с выкладыванием в линию. Но это не значит, что произвольная структура есть последовательность.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Потому что узлы не модифицируемые и на каждом этапе нужно создать новый.
PD>Вот! Именно об этом я и говорю. Код, который ты написал, по сути ничем не отличается от моего — в плане алгоритма. Но я не создаю ничего, кроме одного new элемента и модификации одного указателя (на него). А ты пересоздал зачем-то элементы. Не слишком дорогая плата ?
Нет, у иммутабельных структур есть серьезные преимущества, которые часто окупают накладные расходы. А создание элементов в дотнете дешевая операция.
PD>Тем более. что мою рекурсивную SearchAndInsert ты все равно переписал, и даже она длинее (в байтах текста кода)
, то оно не работает.
PD>Согласен. Хотя мне алгоритм со вставкой по ходу действия кажется логичнее и яснее.
Только императивщикам.
S>>Что есть структура данных без способов работы с ней?
PD>Хм... Все же структура первична, а алгоритмы ИМХО вторичны. Структура данных двоичное дерево есть структура, в которой у каждого элемента не более дух потомков. И это все. Пока все. Это разветвленная структура. Как обходить, к примеру, это дерево — это другой вопрос, кстати, и способов аж 4 есть.
Кто-то недавно говорил что знает только один способ вставки элемента в BST
S>>Более чем уверен что Влад утверждал о последовательности именно как о способе обхода дерева.
PD>А это бога ради. В конце концов ваша любимая сериализация и есть в конечном счете обход произвольной структуры с выкладыванием в линию. Но это не значит, что произвольная структура есть последовательность.
Очевидно что не значит. Но если мы можем применить к ней методы работы с последовательностями, то почему нет? Зачем выдумывать методы работы со структурой когда можно использовать готовые?
Вот я с помощью метода Walk могу ходить по вложенным директориям, по двоичному дереву, по связному графу (даже с циклами) особо не напрягаясь. Следовательно я ко всему этому могу применять LINQ левой пяткой если речь не идет о выжимании тактов и битов. А для моей работы такты и биты не актуальны в 90% случаев.
Здравствуйте, samius, Вы писали:
S>Нет, у иммутабельных структур есть серьезные преимущества, которые часто окупают накладные расходы. А создание элементов в дотнете дешевая операция.
Хоть дешевая, хоть нет, а лишнее пложить незачем.
PD>>Тем более. что мою рекурсивную SearchAndInsert ты все равно переписал, и даже она длинее (в байтах текста кода)
PD>>Согласен. Хотя мне алгоритм со вставкой по ходу действия кажется логичнее и яснее. S>Только императивщикам.
S>>>Что есть структура данных без способов работы с ней?
PD>>Хм... Все же структура первична, а алгоритмы ИМХО вторичны. Структура данных двоичное дерево есть структура, в которой у каждого элемента не более дух потомков. И это все. Пока все. Это разветвленная структура. Как обходить, к примеру, это дерево — это другой вопрос, кстати, и способов аж 4 есть.
S>Кто-то недавно говорил что знает только один способ вставки элемента в BST
Я говорил. И что ? Вставка в BST делается одни способом, а способов обхода двоичного дерева (не BST) таки 4 . Что тут не так ?
PD>>А это бога ради. В конце концов ваша любимая сериализация и есть в конечном счете обход произвольной структуры с выкладыванием в линию. Но это не значит, что произвольная структура есть последовательность. S>Очевидно что не значит. Но если мы можем применить к ней методы работы с последовательностями, то почему нет? Зачем выдумывать методы работы со структурой когда можно использовать готовые?
Что мы можем применить ? Методы обхода произвольной структуры ? Бога ради, в конце концов любая структура есть граф, и его можно обойти, и, обходить придется последовательно, потому что иначе мы не умеем (без потоков), у нас в конце концов процессор последовательно работает . Но делать из этого выводы что все есть последовательность — это уж слишком.
S>Вот я с помощью метода Walk могу ходить по вложенным директориям, по двоичному дереву, по связному графу (даже с циклами) особо не напрягаясь. Следовательно я ко всему этому могу применять LINQ левой пяткой если речь не идет о выжимании тактов и битов. А для моей работы такты и биты не актуальны в 90% случаев.
В общем, я с этим могу согласиться. У меня наоборот все, поэтому он мне и не нужен.
И все же какое-то чувство неудовлетворенности у меня. Да, тебе легче работать (левой пяткой , быстрее, да, все понимаю. Но когда я вижу код, который мог бы (а машинном исполнениии) быит намного лучше — мне это не по душе...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Нет, у иммутабельных структур есть серьезные преимущества, которые часто окупают накладные расходы. А создание элементов в дотнете дешевая операция.
PD>Хоть дешевая, хоть нет, а лишнее пложить незачем.
Не лишнее, оно окупает бонусы иммутабельности.
S>>Кто-то недавно говорил что знает только один способ вставки элемента в BST
PD>Я говорил. И что ? Вставка в BST делается одни способом, а способов обхода двоичного дерева (не BST) таки 4 . Что тут не так ?
Вставка есть как минимум изменяющая исходное дерево и неизменяющая.
PD>Что мы можем применить ? Методы обхода произвольной структуры ? Бога ради, в конце концов любая структура есть граф, и его можно обойти, и, обходить придется последовательно, потому что иначе мы не умеем (без потоков), у нас в конце концов процессор последовательно работает . Но делать из этого выводы что все есть последовательность — это уж слишком.
Не все есть последовательность, а ко всему применимы методы работы с последовательностями.
PD>И все же какое-то чувство неудовлетворенности у меня. Да, тебе легче работать (левой пяткой , быстрее, да, все понимаю. Но когда я вижу код, который мог бы (а машинном исполнениии) быит намного лучше — мне это не по душе...
А мне не по душе когда я вижу избыточный и дублирующийся код, думая о том парне, кому придется его поддерживать.
D>Фактически, енумератор, возвращающий листовой элемент, представляет собой связный список енумераторов (это можно увидеть декомпилировав код), длиной с глубину просмотра, а это log(N). Поэтому, при перемещении к следующему элементу, приходится проходить весь список енумераторов. D>Отсюда и получаем N * log(N).
Угу, хотел добавить, что при любой рекурсии итераторов динамически создается их цепочка длиной в глубину рекурсии (обсуждали это здесь еще в 2005-м году), и затраты на переход к след. элементу зависят от длины цепочки.
PD>>Хоть дешевая, хоть нет, а лишнее пложить незачем. S>Не лишнее, оно окупает бонусы иммутабельности.
Тут не договоримся.
S>>>Кто-то недавно говорил что знает только один способ вставки элемента в BST
PD>>Я говорил. И что ? Вставка в BST делается одни способом, а способов обхода двоичного дерева (не BST) таки 4 . Что тут не так ? S>Вставка есть как минимум изменяющая исходное дерево и неизменяющая.
Вставка куда бы то ни было не может не изменять. Если не согласен — как тогда вообще изменить-то ?
PD>>Что мы можем применить ? Методы обхода произвольной структуры ? Бога ради, в конце концов любая структура есть граф, и его можно обойти, и, обходить придется последовательно, потому что иначе мы не умеем (без потоков), у нас в конце концов процессор последовательно работает . Но делать из этого выводы что все есть последовательность — это уж слишком. S>Не все есть последовательность, а ко всему применимы методы работы с последовательностями.
Теоретически (абстрактно) совершенно безупречное рассуждение. Они даже не только в мире ИТ применимы.
PD>>И все же какое-то чувство неудовлетворенности у меня. Да, тебе легче работать (левой пяткой , быстрее, да, все понимаю. Но когда я вижу код, который мог бы (а машинном исполнениии) быит намного лучше — мне это не по душе...
S>А мне не по душе когда я вижу избыточный и дублирующийся код, думая о том парне, кому придется его поддерживать.
А мне не по душе, когда я вижу код, который мог бы работать быстрее, думая о том парне, которому придется с этой программой работать
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Вставка есть как минимум изменяющая исходное дерево и неизменяющая.
PD>Вставка куда бы то ни было не может не изменять. Если не согласен — как тогда вообще изменить-то ?
Дык и не надо менять-то. Цель не в том чтобыизменить дерево, а в том, чтобы получить дерево, которое бы содержало все элементы исходного и добавляемый.
S>>А мне не по душе когда я вижу избыточный и дублирующийся код, думая о том парне, кому придется его поддерживать.
PD>А мне не по душе, когда я вижу код, который мог бы работать быстрее, думая о том парне, которому придется с этой программой работать
В моем случае перень не заметит разницы даже с секундомером.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, samius, Вы писали:
S>>>Вставка есть как минимум изменяющая исходное дерево и неизменяющая.
PD>>Вставка куда бы то ни было не может не изменять. Если не согласен — как тогда вообще изменить-то ? S>Дык и не надо менять-то. Цель не в том чтобыизменить дерево, а в том, чтобы получить дерево, которое бы содержало все элементы исходного и добавляемый.
Это уже игра в слова. Вставка в моем понимании и есть — взять дерево, добавить элемент и получить новое дерево (пусть мне кто-то скажет, что это прежнее дерево!). Но при этом не меняется истинный root, не меняются никакие ссылки (кроме точенчного изменения в месте вставки) и ничего не копируется — ни данные, ни управляющая информация). Изменения по памяти — O(1). На то оно и дерево. А иначе я могу и упорядоченный массив взять, и он многое из того, что дерево позволяет (Log N поиск хотя бы), да только вставка в нем O(1) не пройдет ни по памяти, ни по времени. И именно за эти свойтсва я ту или иную структуру применяю или отвергаю в данной ситуации.
S>>>А мне не по душе когда я вижу избыточный и дублирующийся код, думая о том парне, кому придется его поддерживать.
PD>>А мне не по душе, когда я вижу код, который мог бы работать быстрее, думая о том парне, которому придется с этой программой работать S>В моем случае перень не заметит разницы даже с секундомером.
Значит, для твоих задач это действительно не важно.
«Жасминовые тирсы наших первых мэнад примахались быстро…»
Мне отчасти до боли сделалось жаль наш бестолковый русский народ, а отчасти было досадно: ничего нельзя поручить русскому человеку… Дали ему в руки жасминовый тирс, а он обрадовался, и ну — махать им, пока примахал этот инструмент окончательно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Здравствуйте, samius, Вы писали:
S>>>>Вставка есть как минимум изменяющая исходное дерево и неизменяющая.
PD>>>Вставка куда бы то ни было не может не изменять. Если не согласен — как тогда вообще изменить-то ? S>>Дык и не надо менять-то. Цель не в том чтобыизменить дерево, а в том, чтобы получить дерево, которое бы содержало все элементы исходного и добавляемый.
PD>Это уже игра в слова. Вставка в моем понимании и есть — взять дерево, добавить элемент и получить новое дерево (пусть мне кто-то скажет, что это прежнее дерево!). Но при этом не меняется истинный root, не меняются никакие ссылки (кроме точенчного изменения в месте вставки) и ничего не копируется — ни данные, ни управляющая информация).
Это побочный эффект императивной вставки.
PD>Изменения по памяти — O(1). На то оно и дерево. А иначе я могу и упорядоченный массив взять, и он многое из того, что дерево позволяет (Log N поиск хотя бы), да только вставка в нем O(1) не пройдет ни по памяти, ни по времени. И именно за эти свойтсва я ту или иную структуру применяю или отвергаю в данной ситуации.
А я по другим свойствам. Но об алгоритмических оценках помню.
S>>В моем случае перень не заметит разницы даже с секундомером.
PD>Значит, для твоих задач это действительно не важно.
действительно.
Я думаю что это нормальный процесс пробования инструмента. Через подобный процесс долны пройти все творческие люди. Иначе не было бы фигур изо льда, выпиленных бензопилой.
Другое дело, если человек из опыта ничего не вынесет полезного...
Здравствуйте, samius, Вы писали:
PD>>Это уже игра в слова. Вставка в моем понимании и есть — взять дерево, добавить элемент и получить новое дерево (пусть мне кто-то скажет, что это прежнее дерево!). Но при этом не меняется истинный root, не меняются никакие ссылки (кроме точенчного изменения в месте вставки) и ничего не копируется — ни данные, ни управляющая информация). S>Это побочный эффект императивной вставки.
Это не побочный эффект. Это самое что ни на есть прямое действие — я хочу вставить, и не хочу лишних действий, иначе потеряю преимущества, связанные с использованием этой структуры данных. Я именно за эти преимущества ее выбрал или отверг. Если можно копировать — а на что мне тогда дерево... массив удобнее...
PD>>Изменения по памяти — O(1). На то оно и дерево. А иначе я могу и упорядоченный массив взять, и он многое из того, что дерево позволяет (Log N поиск хотя бы), да только вставка в нем O(1) не пройдет ни по памяти, ни по времени. И именно за эти свойтсва я ту или иную структуру применяю или отвергаю в данной ситуации.
S>А я по другим свойствам. Но об алгоритмических оценках помню.
Вот именно. Они, вообще-то, не должны ни от языка, ни от среды ни от императивное vs функциональное зависеть не должны. Они таковы в силу природы вещей. Хотя испоритить их (структуры данных) неудачным алгоритмом или средой исполнения можно .
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>А я по другим свойствам. Но об алгоритмических оценках помню.
PD>Вот именно. Они, вообще-то, не должны ни от языка, ни от среды ни от императивное vs функциональное зависеть не должны. Они таковы в силу природы вещей. Хотя испоритить их (структуры данных) неудачным алгоритмом или средой исполнения можно .
Т.е. ФП испортило структуры данных? Или ФП это неудачное исполнение?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>>>А я по другим свойствам. Но об алгоритмических оценках помню.
PD>>Вот именно. Они, вообще-то, не должны ни от языка, ни от среды ни от императивное vs функциональное зависеть не должны. Они таковы в силу природы вещей. Хотя испоритить их (структуры данных) неудачным алгоритмом или средой исполнения можно .
S>Т.е. ФП испортило структуры данных? Или ФП это неудачное исполнение?
Не исключаю. Впрочем, не будучи знатоком ФП, выводы делать не буду. Возможно, некая иная реализация имела бы иные свойства в этом плане. В частности LinQ явно унаследован от SQL. А если бы унаследовались от некоего языка для работы с иерархическим данными ? Возможно такое ФП ? (хотя бы в принципе, полезность не обсуждаю)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>Т.е. ФП испортило структуры данных? Или ФП это неудачное исполнение?
PD>Не исключаю. Впрочем, не будучи знатоком ФП, выводы делать не буду. Возможно, некая иная реализация имела бы иные свойства в этом плане. В частности LinQ явно унаследован от SQL. А если бы унаследовались от некоего языка для работы с иерархическим данными ?
LINQ растет из Haskell-а, а у того с иерархическими данными все впорядке. К SQL LINQ имеет отношение лишь схожим QuerySyntax в реализации C#.
PD> Возможно такое ФП ? (хотя бы в принципе, полезность не обсуждаю)
Возможно ли что в ФП будут другие методы работы с неизменяемыми структурами? Исключено.
А как только ФП начинает использовать изменяемые структуры, то получается гибрид императива с ФП, что уже нельзя отнести к ФП.
Нет понятия "абсолютно быстрый код", но есть понятие "достаточно быстрый код за такую-то цену".
Да, императивный код быстрее (намного ли?). Но он начинает сливать при распараллеливании, т.к. сам себя ждет для того чтобы эксклюзивно изменить состояние.
У всего своя цена.
Здравствуйте, samius, Вы писали:
S>LINQ растет из Haskell-а, а у того с иерархическими данными все впорядке. К SQL LINQ имеет отношение лишь схожим QuerySyntax в реализации C#.
Я вот эту реализацию и имел в виду. Но возможны же другие ?
PD>> Возможно такое ФП ? (хотя бы в принципе, полезность не обсуждаю) S>Возможно ли что в ФП будут другие методы работы с неизменяемыми структурами? Исключено. S>А как только ФП начинает использовать изменяемые структуры, то получается гибрид императива с ФП, что уже нельзя отнести к ФП.
Гм...
S>Нет понятия "абсолютно быстрый код", но есть понятие "достаточно быстрый код за такую-то цену".
Ну это уже другая тема, давай не будем.
S>Да, императивный код быстрее (намного ли?).
>Но он начинает сливать при распараллеливании, т.к. сам себя ждет для того чтобы эксклюзивно изменить состояние.
Что значит сам себя ? Ждет один поток сигнала от другого. И без ожидания написать многопоточный код , вообще-то, нельзя, просто в силу наличия общих модифицируемых данных. А если ты хочешь сказать, что можно от них избавиться, перейдя к иммутабельным данным, то это применимо очень и очень не всегда. Для дерева ты это сделаешь, проиграв в быстродействии, ладно. А для файла на диске ? Его-то не сдублируешь и копию не сделаешь.
S>У всего своя цена.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, samius, Вы писали:
S>>LINQ растет из Haskell-а, а у того с иерархическими данными все впорядке. К SQL LINQ имеет отношение лишь схожим QuerySyntax в реализации C#.
PD>Я вот эту реализацию и имел в виду. Но возможны же другие ?
Реализации QuerySyntax? Да. Они есть и меньше смахивают на SQL и только.
S>>Да, императивный код быстрее (намного ли?).
PD>Намного. В 4-6 раз на простом тесте.
PD>http://rsdn.ru/forum/dotnet/3528765.1.aspx
Линк не олицетворяет собой весь функциональный код и имеет оверхед даже над ним. Вы сравниваете производительность линка и цикла, в то время как мы говорили (может быть только я) о разнице между вставкой в иммутабельную структуру и в мутабельную. Там будет разница порядка нескольких процентов.
>>Но он начинает сливать при распараллеливании, т.к. сам себя ждет для того чтобы эксклюзивно изменить состояние.
PD>Что значит сам себя ? Ждет один поток сигнала от другого. И без ожидания написать многопоточный код , вообще-то, нельзя, просто в силу наличия общих модифицируемых данных.
Вот в силу наличия этих данных императив и сливает за счет ожидания.
PD>А если ты хочешь сказать, что можно от них избавиться, перейдя к иммутабельным данным, то это применимо очень и очень не всегда. Для дерева ты это сделаешь, проиграв в быстродействии, ладно. А для файла на диске ? Его-то не сдублируешь и копию не сделаешь.
Разве нельзя сделать копию файла?
Дык причем тут файл-то, если речь идет о распараллеливании? Обычно когда распараллеливают, имеют цель выполнить быстрее счет, а не записать быстрее в файл. Обращение к диску это не CPU-емкие операции.
S>Линк не олицетворяет собой весь функциональный код и имеет оверхед даже над ним. Вы сравниваете производительность линка и цикла, в то время как мы говорили (может быть только я) о разнице между вставкой в иммутабельную структуру и в мутабельную. Там будет разница порядка нескольких процентов.
Надо будет сравнить на дереве в десяток тысяч элементов
PD>>Что значит сам себя ? Ждет один поток сигнала от другого. И без ожидания написать многопоточный код , вообще-то, нельзя, просто в силу наличия общих модифицируемых данных. S>Вот в силу наличия этих данных императив и сливает за счет ожидания.
Я чего-то не понял. Кто мне мешает в императиве иметь неизменяемые данные и не ждать ? Просто это редкий случай.
PD>>А если ты хочешь сказать, что можно от них избавиться, перейдя к иммутабельным данным, то это применимо очень и очень не всегда. Для дерева ты это сделаешь, проиграв в быстродействии, ладно. А для файла на диске ? Его-то не сдублируешь и копию не сделаешь. S>Разве нельзя сделать копию файла?
А нельзя, допустим. Вот у меня модифицируется разными потоками файл размером в 1 Гб. Что, копию на каждое изменение байта будем делать ?
S>Дык причем тут файл-то, если речь идет о распараллеливании? Обычно когда распараллеливают, имеют цель выполнить быстрее счет, а не записать быстрее в файл. Обращение к диску это не CPU-емкие операции.
Ну тут ты меня просто удивил. Почитай иные форумы, там сплошь и рядом задача распараллеливания с записью в файл. Разные потоки , например, независимо ведут операции, а писать надо в один и тот же файл. А операции счета я и так могу вести независимо и ничего не ждать, если они не работают с общими данными.
