Где умное использование строгой оценки?
Попробуйте использовать ARRAY_JOIN с ARRAY_AGG:
SELECT
id1,
id2,
ARRAY_JOIN(ARRAY_AGG(actions), ',') actions
FROM yourTable
GROUP BY
id1,
id2;
9 ответов
Главное можно сделать легко на нетерпеливом (строгом) языке а не на ленивом языке:
Предскажите от исходного кода затраты времени и пространства на свои программы
Побочные эффекты разрешения, включая постоянно-разовое обновление изменяемых массивов, которое помогает реализовать некоторые алгоритмы быстро
По-моему, главное преимущество нетерпеливого языка - то, что намного легче заставить Ваш код выполнять способ, которым Вы хотите, и существует очень немного прерываний производительности, в которых небольшое изменение в коде приводит к огромному изменению в производительности.
Однако в целом я предпочитаю писать сложные вещи в Haskell.
Нет; существуют некоторые вещи, которые можно сделать* с отложенными вычислениями (иначе сокращение нормального порядка или лево-наиболее удаленное сокращение), что Вы не можете сделать со строгой оценкой, но не наоборот.
Причина этого состоит в том, что отложенные вычисления являются в некотором роде 'самым общим' способом оценить, который известен как:
Вычислительная Теорема Соответствия: Если некоторый порядок оценки завершит и приведет к конкретному результату, то отложенные вычисления также завершат и приведут к тому же результату.
* (обратите внимание на то, что мы не говорим об эквивалентности Тьюринга здесь),
Как Charlie Martin записал, результат строгой и ленивой программы должен быть эквивалентным. Различие заключается, во времени и пространстве ограничивает и/или выразительность языка. Около эффекта производительности лени для ненужных значений там каждый может на ленивом языке легко представлять новые конструкции языка без дополнительного понятия языка (например, макрос в LISP). Так или иначе лень может бит Вы, Как хвостовая рекурсия Haskell работает? и то же думает, может быть более сложным, чем на строгом языке. (Не был должен haskell компилятор распознавать, что вычисляют +1 является менее дорогим, чем делают преобразователя ( x + 1 )?)
Ну, нет, более или менее по определению. На языке отложенных вычислений необходимо ли по определению получить те же результаты, которые Вы получили бы с энергичным (люди действительно используют "строгий" теперь?) оценка, за исключением задержки оценки, пока не необходимый, последствий устройства хранения данных и всего это. Таким образом, если бы Вы могли бы получить некоторое другое поведение, за исключением которого, это была бы ошибка.
Я программирую в Erlang немного и нахожу отсутствие отложенных вычислений, которые я изучил назад в довольно печальном университете.
Я кратко смотрел на некоторые Euler проблемы проекта, особенно те, которые имеют дело с началами.
С отложенными вычислениями у Вас может быть функция, которая возвращает список всех начал, но они только на самом деле возвращают тех, которых Вы на самом деле хотите. Следовательно действительно легко сказать, "дают мне первые n начала".
Без отложенных вычислений Вы склонны заканчивать с большим количеством ограничения, "дают мне список всех начал между 1 и n".
На строгом языке оценки, таком как C# возможно достигнуть отложенных вычислений путем возврата преобразователя значению (Func) вместо самого значения. Поскольку пример в конструкции Y-Combinator в c# может быть сделан таким образом:
public Func<int, int> Y(Func<Func<int, int>, Func<int, int>> f)
{
return x => f(Y(f))(x);
}
Это объявление было бы более кратким в ленивой среде:
Y f = f (Y f)
Ответ, который был оценен как лучший, страдает, к сожалению, от логической ошибки. Из теоремы, которую цитирует Поргес, не следует, что на ленивом языке можно сделать больше.
Доказательством обратного является то, что все программы на ленивых языках компилируются в эквиваленты на строгих языках (которые компилируются далее для программ на ассемблере) или выполняются интерпретатором, написанным на строгом языке (и да, интерпретатор является программой ассемблера в конечном счете).
Наиболее очевидное использование лени в повседневном языке - это оператор «if», в котором выполняется только одна ветвь условного оператора.
Противоположность чисто нестрогому (ленивому) ) язык был бы чисто строгим языком.
Есть по крайней мере один случай, когда «чисто строгий» полезен, а именно предикация ветвления .
Грубый пересказ связанной статьи:
Давным-давно в мире процессоров инструкции для выполнения загружались, когда проверялось условие перехода. В какой-то момент были добавлены конвейеры инструкций, чтобы сократить время загрузки. Обратной стороной было то, что ЦП не знал, какую ветвь ему нужно загрузить, поэтому по умолчанию загружал одну. Если ветвь пошла другим путем, конвейер остановился бы, пока код для другой ветки был загружен.
Решение состоит в том, чтобы загрузить обе ветви, выполнить обе ветви, а затем результат условного выражения скажет вам, какой результат ветки сохранить, а какой выбросить. Тогда вы не получите срывов конвейера.
Это мой любимый (единственный?) Пример преимущества чисто строгого языка.
На ум приходят программы «Hello, World» или вообще все, что связано с побочными эффектами.
При строгом вычислении оценка выражения может легко иметь побочный эффект, поскольку у вас есть четкое представление о порядке оценки и, следовательно, о порядке побочных эффектов, которые обычно важны для побочных эффектов. Это основное преимущество строгой оценки, а также то, почему она есть в большинстве языков. И почему даже ориентированные на производительность языки, такие как C, часто используют модель передачи по значению.
Оба могут делать то же самое, только с разными уровнями человеческой сложности, вы можете отлично моделировать бесконечные списки на строгом языке, и вы можете моделировать все эффекты побочных эффектов с помощью нестрогих языков.