Оптимизация 'Игры Conway жизни'
Не знаю, почему @Janos удалил свой ответ, но это правильно: в вашем фрейме данных Train нет столбца с именем pre. Когда вы передаете формулу и кадр данных в функцию установки модели, имена в формуле должны ссылаться на столбцы в фрейме данных. В вашем Train есть столбцы, называемые residual.sugar, total.sulfur, alcohol и quality. Вам нужно изменить формулу или фрейм данных, чтобы они были согласованы друг с другом.
И просто для уточнения: Pre - это объект, содержащий формулу. Эта формула содержит ссылку на переменную pre. Это последнее должно быть согласовано с кадром данных.
8 ответов
Я собираюсь заключить свой ответ в кавычки из другого вопроса, потому что главы, которые я упоминаю, имеют некоторые очень интересные и подстроенные решения. Некоторые детали реализации находятся в c и/или блоке, да, но по большей части алгоритмы могут работать на любом языке:
Главы 17 и 18 из Michael Abrash Черный список Программиста 3D графики является одним из самых интересных чтений, которые я когда-либо имел. Это - урок в размышлении вне поля. Целая книга является замечательной действительно, но заключительные оптимизированные решения Игры Жизни являются невероятными битами программирования.
Существуют некоторые сверхбыстрые реализации, которые (из памяти) представляют ячейки 8 или больше смежных квадратов как комбинации двоичных разрядов и использование, что как индекс в большой массив предрасчетных значений для определения в единственной машинной команде, если ячейка жива или мертва.
Проверка здесь:
http://dotat.at/prog/life/life.html
Также XLife:
Необходимо изучить Hashlife, окончательная оптимизация. Это использует дерево квадрантов подход это упомянутый skinp.
Как упомянуто в Черном списке Arbash, один из самых простых и прямых способов получить огромное ускорение состоит в том, чтобы сохранить список изменения.
Вместо того, чтобы выполнить итерации через всю сетку ячейки каждый раз, сохраните копию всех ячеек, которые Вы изменяете.
Это сузит работу, которую необходимо сделать на каждом повторении.
Две идеи:
(1) Много конфигураций являются главным образом вакуумом. Сохраните связанный список (не обязательно в порядке, который занял бы больше времени) живых ячеек, и во время обновления, только обновите вокруг живых ячеек (это подобно Вашему неопределенному предложению, OysterD:)
(2) Сохраняют дополнительный массив, который хранит # живых ячеек в каждой строке 3 положений (лево-центральное право). Теперь при вычислении нового мертвого/живого значения ячейки Вам нужны только 4 операции чтения (вершина/нижние ряды, и положения центральной стороны), и 4 операции записи (обновите 3 затронутых сводных значения строки и мертвое/живое значение новой ячейки). Это - небольшое улучшение от 8 чтений и 1 записи, принимающие записи не медленнее, чем чтения. Я предполагаю, что Вы могли бы быть в состоянии быть более умными с такими конфигурациями и достигнуть еще лучшего улучшения вдоль этих строк.
Точно не знайте, как это может быть сделано, но я помню, что некоторые мои друзья должны были представить сетку этой игры с Деревом квадрантов для присвоения. Я - предположение, это очень хорошо для оптимизации пространства сетки, так как Вы в основном только представляете занятые ячейки. Я не знаю о скорости выполнения все же.
Это - двумерный автомат, таким образом, можно, вероятно, искать методы оптимизации. Ваше понятие, кажется, о сжатии количества ячеек, которые необходимо проверить на каждом шаге. Так как только когда-либо необходимо проверять ячейки, которые заняты или смежны с занятой ячейкой, возможно, Вы могли сохранить буфер всех таких ячеек, обновив ее на каждом шаге, поскольку Вы обрабатываете каждую ячейку.
, Если Ваше поле первоначально пусто, это будет намного быстрее. Вероятно, можно найти некоторую точку равновесия, в которой поддержание буфера является более дорогостоящим, чем обработка всех ячеек.
Существуют табличные решения для этого, которые разрешают несколько ячеек в каждом поиске по таблице. Запрос Google должен дать Вам некоторые примеры.