Два года назад сделал коррекцию, обычный LASIK, и получил нефиговый глэр-эффект по ночам. Позже выяснил, что это из-за старого оборудования в клинике, которое обрабатывает область роговицы не более 0,5мм в диаметре, а в темноте мои зрачки становятся шире обработанной области. Возможно ли (теоретически – разумеется, точный ответ даст только врач) сделать докоррекцию с устранением глэр-эффекта?
Отличные советы, правда. Для людей, привыкших работать в команде — сами собой разумеющиеся, а тем более — в компаниях с отлаженными процессами разработки. Но есть инженеры-социофобы, вроде меня, которым проще воткнуть бананы в уши и в отрыве от реальности решить задачу в одну рожу, чем разделить на части и делегировать коллегам. И, не зацикливаясь на успешном результате, перейти к следующей.
Пробовали внедрять. Первое впечатление — восторг, конечно, но почти сразу начались проблемы, из-за которых пришлось полностью отказаться.
В первую очередь — «виртуализованные» таким образом приложения невозможно нормально обновлять. Для обновления версии ПО или дефолтной конфигурации приходится заново перепаковывать приложение. Во вторую — ассоциации файлов с виртуализованными приложениями работали из рук вон плохо. Ну и в довершение, в виртуализованном Офисе не работали некоторые плагины и индексированный поиск (о чем, впрочем, предупреждала официальная документация по виртуализации).
Проблема не столько в байтах, сколько в реалтайме. При внезапной перезагрузке по питанию тратится некоторое время на бутлоадер ардуины, иногда это может быть критично.
Да, в случае с построением формулы в фитнес-функцию пришлось бы встраивать непростую проверку синтаксиса, а ООП избавляет от такой необходимости на корню.
Интересный документ. Технически — используется достаточно очевидная в наше время объектная модель с хэшмапами символов, однако в качестве хромосомы все равно выступает, по сути, битовая строка. Забавно читать: девять лет назад считалось космическими технологиями, а сегодня сделать по другому и в голову-то не приходит :)
Вот только с математической точки зрения мне трудно понять, как апроксимируются математические выражения. Ведь при изменении любого оператора или параметра результат выполнения функции будет меняться на всем пространстве аргументов, так? К примеру, если в популяции появится хромосома с абсолютно правильным набором операторов, но с неправильными параметрами, она с большой вероятностью будет отброшена, разве нет?
А где же, собственно, умный дом? Проигрывание видео с сетевой хранилки на телике и планшете — это здорово, но как же автоматическое управление светом, кондиционером, вентиляцией, отоплением, количеством сока в холодильнике?
А вот это уже нетривиальный вопрос, но правильный :) Формулами не блесну, ибо я не математик (и, строго говоря, даже не программист по профессии), но скажу, что моя задача, в принципе, сводится к этой, с некоторыми дополнительными условиями.
Можно спросить, как более сведущего человека? Я правильно понимаю, что задачи из пространства NP можно решить алгоритмически, а NP-сложные и, в частности, NP-полные задачи можно решить исключительно аппроксимацией (будь то ГП, graph rewriting или что-то еще)?
Но, простите, это заложено в определении NP-задачи — решаемость за полиномиальное время. Предполагать решение NP-задачу сколько-нибудь «быстро» — это абсурд. Тем более, NP-полную задачу.
Совершенно согласен про операторы. Причем важно не только их правильно реализовать, но и правильно применять в алгоритме эволюции. Про геном не соглашусь. Разумеется, битовая строка — это смешно в век ООП. Как и невозможность/нетривиальность представления какого-либо типа данных. Весь мир уже описан в XML так или иначе.
Признаюсь, я новичок в этом деле, статью непосредственно про ГП я не осилю, но если у меня получится решить мою задачу — обязательно об этом напишу.
Не соглашусь. Чтобы написать правильную фитнес-функцию, нужно только лишь внимательно подумать и составить формализованный перечень требований к конечному решению задачи. Сверка решения с этими требованиями — задача, как правило, линейная и решаемая. Создание генома — в общем-то, тоже вопрос сформулированности ТЗ.
Генетическое программирование призвано решать недетерминированные задачи, для которых невозможно линейным образом сгенерировать хоть какое-либо решение. IRL их всегда было и будет много. Один из классов таких задач — NP-полные задачи. Я сейчас как раз занимаюсь решением одной из них. Весьма, скажу, увлекательное занятие!
Кстати, хозяйке на заметку, довольно неплохая библиотека для работы с сабжем (java): jgap.sourceforge.net/
Если RRAM действительно окажется такой же быстрой, как DRAM и такой же дешевой, как HDD, это может поменять целиком архитектуру ПК — с такой памятью не будет смысла как-то разделять ОЗУ и устройства хранения данных.
Было бы здорово, если бы можно было выбирать — подключать блоки друг к другу по радиоканалу или проводом/коннектором/через макетку. Это частично решило бы проблему с зарядкой такой россыпи блоков.
Вообще идея нравится. Это проще, чем Ардуино, может привлечь больше людей, как подготовка к более сложной разработке.
Попробуйте объяснить человеку в возрасте 55 лет, владеющего квартирой площадью 200 м2 и двумя автомобилями, купленными без кредитов, и работа которого не связана с компьютерами, что без андроид-смартфона с фуллхд-экраном взамен нокиа 8800 он — нищеброд.
Не подумайте, я не против технического прогресса, просто для простейшмх бытовых задач этих машинок действительно хватает, и это не теоретические предположения, а исключительная реальность.
В первую очередь — «виртуализованные» таким образом приложения невозможно нормально обновлять. Для обновления версии ПО или дефолтной конфигурации приходится заново перепаковывать приложение. Во вторую — ассоциации файлов с виртуализованными приложениями работали из рук вон плохо. Ну и в довершение, в виртуализованном Офисе не работали некоторые плагины и индексированный поиск (о чем, впрочем, предупреждала официальная документация по виртуализации).
Интересный документ. Технически — используется достаточно очевидная в наше время объектная модель с хэшмапами символов, однако в качестве хромосомы все равно выступает, по сути, битовая строка. Забавно читать: девять лет назад считалось космическими технологиями, а сегодня сделать по другому и в голову-то не приходит :)
Вот только с математической точки зрения мне трудно понять, как апроксимируются математические выражения. Ведь при изменении любого оператора или параметра результат выполнения функции будет меняться на всем пространстве аргументов, так? К примеру, если в популяции появится хромосома с абсолютно правильным набором операторов, но с неправильными параметрами, она с большой вероятностью будет отброшена, разве нет?
Совершенно согласен про операторы. Причем важно не только их правильно реализовать, но и правильно применять в алгоритме эволюции. Про геном не соглашусь. Разумеется, битовая строка — это смешно в век ООП. Как и невозможность/нетривиальность представления какого-либо типа данных. Весь мир уже описан в XML так или иначе.
Признаюсь, я новичок в этом деле, статью непосредственно про ГП я не осилю, но если у меня получится решить мою задачу — обязательно об этом напишу.
Генетическое программирование призвано решать недетерминированные задачи, для которых невозможно линейным образом сгенерировать хоть какое-либо решение. IRL их всегда было и будет много. Один из классов таких задач — NP-полные задачи. Я сейчас как раз занимаюсь решением одной из них. Весьма, скажу, увлекательное занятие!
Кстати, хозяйке на заметку, довольно неплохая библиотека для работы с сабжем (java):
jgap.sourceforge.net/
Вообще идея нравится. Это проще, чем Ардуино, может привлечь больше людей, как подготовка к более сложной разработке.