Очевидно, что при достаточно большом n разница в производительности сортировки будет больше в сколько угодно раз, и чем больше n, тем больше разница. Поэтому заявление о "примерно в 100 раз быстрее" является профанацией. Имеет смысл быть аккуратнее с формулировками.
Отображение построенного ландшафта в виде крупных вокселей резко ухудшает восприятие. Кажется, карту ландшафта достаточно просто запихнуть в меш, и насладиться гладкой поверхностью.
Видимо, автор для простоты воспользовался какой-то модификацией движка Minecraft?
А в чём вы видите применимость? Как дополнение для потенциальных прочих моделей или больше из исследовательского интереса?
До Вашей серии статей я был знаком только с простейшими модификациями исходного варианта клеточных автоматов Джона Хортона Конвея. Поэтому у меня нет примеров практического применения КА, но я подумал, может быть они есть у вас, и вы о них расскажете )
Наверное, муравьиный алгоритм поиска в пространстве эффективно реализуется напрямую, без использования клеточных автоматов, а поведение клеточных автоматов напомнило его.
В любом случае, спасибо за интересную серию статей, это удивительный мир математических абстракций!
Японцы считают, что нет. Кажется, такой стул и такой метод сидения на нём - это часть японской традиционной культуры. Впрочем, надо проверять. Я не изучал эту тему специальным образом.
> "Компилятор должен сам делать всё правильно, а не заставлять людей выполнять вручную преобразования, которые могут быть и ошибочными, или, хуже того, втихомолку генерировать неверный код."
Например, компилятор Delphi делает это настолько педантично, что иногда приходится сильно поприседать, чтобы исключить генерацию в коде этих специальных преобразований, когда заранее известно, что коллизий при несовпадении типов не будет. Приходится аккуратно и точно использовать типы данных, чтобы код не содержал лишнего.
Удивительно, Delphi хорош именно этим. Он настолько скрупулёзно проверяет соответствие диапазонов типов как во время компиляции, так и в runtime, что иногда приходится очень тщательно выбирать типы для данных, чтобы исключить генерацию в целевом коде "лишние" преобразование типов и проверки.
Вы правы, производительность вещественных операций в современных процессорах указаны в статье очень приблизительно. На практике, ознакомиться с производительностью разных команд можно в справочном руководстве от Agner Fog :
Очевидно, что при достаточно большом n разница в производительности сортировки будет больше в сколько угодно раз, и чем больше n, тем больше разница. Поэтому заявление о "примерно в 100 раз быстрее" является профанацией. Имеет смысл быть аккуратнее с формулировками.
Отображение построенного ландшафта в виде крупных вокселей резко ухудшает восприятие. Кажется, карту ландшафта достаточно просто запихнуть в меш, и насладиться гладкой поверхностью.
Видимо, автор для простоты воспользовался какой-то модификацией движка Minecraft?
До Вашей серии статей я был знаком только с простейшими модификациями исходного варианта клеточных автоматов Джона Хортона Конвея. Поэтому у меня нет примеров практического применения КА, но я подумал, может быть они есть у вас, и вы о них расскажете )
Наверное, муравьиный алгоритм поиска в пространстве эффективно реализуется напрямую, без использования клеточных автоматов, а поведение клеточных автоматов напомнило его.
В любом случае, спасибо за интересную серию статей, это удивительный мир математических абстракций!
Расскажите, пожалуйста, есть ли практические применения у приведенных КА (клеточных автоматов)?
Первая аналогия, которая приходит на ум - это муравьиный алгоритм поиска пути. Есть ли какие-то исследования клеточных автоматов в этом направлении?
О, спасибо за инфу! Я так и предполагал, что японцы это выдумали не с проста.
Японцы считают, что нет. Кажется, такой стул и такой метод сидения на нём - это часть японской традиционной культуры. Впрочем, надо проверять. Я не изучал эту тему специальным образом.
Существует ортопедический "японский стул" с упором для коленей. Я не пробовал, но выглядит перспективно. Есть варианты и для работы за компьютером.
В этом есть какой-то бонус. или это такая шутка?
( Сам не пользуюсь телегой и никогда не пользовался )
> "Компилятор должен сам делать всё правильно, а не заставлять людей выполнять вручную преобразования, которые могут быть и ошибочными, или, хуже того, втихомолку генерировать неверный код."
Например, компилятор Delphi делает это настолько педантично, что иногда приходится сильно поприседать, чтобы исключить генерацию в коде этих специальных преобразований, когда заранее известно, что коллизий при несовпадении типов не будет. Приходится аккуратно и точно использовать типы данных, чтобы код не содержал лишнего.
Удивительно, Delphi хорош именно этим. Он настолько скрупулёзно проверяет соответствие диапазонов типов как во время компиляции, так и в runtime, что иногда приходится очень тщательно выбирать типы для данных, чтобы исключить генерацию в целевом коде "лишние" преобразование типов и проверки.
Вы правы, производительность вещественных операций в современных процессорах указаны в статье очень приблизительно. На практике, ознакомиться с производительностью разных команд можно в справочном руководстве от Agner Fog :
https://www.agner.org/optimize/instruction_tables.pdf
Так, например, для ядра Coffe Lake время выполнения команд вещественной арифметики составляет
Сложение, вычитание 4 такта
Умножение 4 такта
Деление 11 тактов
Вычисление квадратного корня 12 тактов
Минимум, максимум двух чисел, внезапно 4 такта
Есть даже аппаратно реализованное скалярное произведение векторов, 13 тактов.
И это довольно значительно отличается от значений. приведенных автором в статье.
Судя по первой сравнительной таблице, оптимальным среди приведенных программ сжатия в данном примере является lz4 1.9.3, а не zstd.