Память может подводить, но у меня стойкое ощущение, что в Freelancer я летал с помощью джостика, да еще и подключался который через LPT или что то схожее тех времен.
На картинке, модуль экрана от компании WaveShare - тот еще образец opensource железа и программного обеспечения.
Личный опыт - купил E-Ink модуль с управляющим ARM контроллером. Поигрался, захотел вывести наш родной и могучий. Итог: схематика - закрыта, прошивка контроллера - закрыта, формат шрифтов - закрыт, по почте отвечали хамски и грубили, потом просто перестали отвечать.
Я очень ждал и восхищался процессором(СнК) от Элвиса 1892ВА018 Шайтан(SCYTHIAN) или же упрощенно «СКИФ». При выходе на массовый рынок это был бы прекрасный одноплатник с DDR4, SDR/GPS/GPRS/LTE и кучей других фишек на огромную статью на Хабр.
Но… TSMC.
Да, к сожалению не осталось их, не могу сказать модели. Нагрузка специфичная -~100ГБ файлов по 64-1024КБ с постоянными правками части их содержания. Сейчас как резерв к OCZ работает Samsung 840 PRO на 256 около 3-4 лет.
Несмотря на всем известную лотерею от OCZ, которую все всегда упоминают, я выиграл джекпот — с 2011-2012 использую в качестве флешки SSD от OCZ на 120GB(sld3-255at3-120g). Пережило уже пару Samsung'ов(тоже с MLC) при схожей нагрузке
Никогда не думал, что это будет кому-то интересно. Сам код показать не смогу по достаточно простой причине - он пишется как ядро ИИ для игры.
Но могу рассказать подробности если вас интересует что то конкретное, или написать небольшую статью(если дойдут руки, но написание текстов даётся мне с трудом, с учётом моей безграмотности).
Эксперименты которые я проводил в основном сводятся к наблюдению над средневековым поселением в сотни, иногда тысячи человек, с проверкой различных теорий, вот некоторые из самых ярких: как будет меняться темп развития общества если детей будет растить спец институт вместо семьи, как можно уменьшить (отменить) инфляцию при государственном регулировании в рамках небольшого общества, какие эффекты даёт базовый гарантированный доход и т.п.
Самым интересным как по мне был годичный проект, где исследовал откуда берется цена на товар.(откуда берется та самая первая цена), где общество медленно и, главное, само переходило от бартера к некоторой форме покупки/продаж с промежуточной ценностью в виде денег.
Лет пять уже как делаю виртуальную лабораторию, где у каждого актера есть желания(потребности, хотелки и т.п), задачи и шаги выполнения. Общий алгоритм на пальцах достаточно простой:
— Задачи имеют некоторый динамический приоритет рассчитываемый от текущих желаний актера
— Если задача изменилась (или началась к исполнению с нуля) она формирует список шагов для ее достижения
— Исполняется шаг из очереди, если очередь пуста — переходим к следующей задаче по приоритету.
— Если другая задача превышает по приоритету текущую выше определенного значения — она отменяет текущую(и ее шаги) и становится актуальной задачей.
— Если шаг невозможно выполнить — обнуляется весь стек шагов. (на самом деле механизм чуть сложнее, но так проще объяснить базовый концепт)
Простой подход позволяет при, примерно, трех десятках задач сформировать неплохое такое общество из десятков тысяч актеров, имитирующих очень похожую на реальность жизнь небольшого общества, где каждый актер выполняет важную роль и демонстрирует индивидуальность, предпочтения и характер.
Лет 5 назад со скуки делал хобби проект с gps. Использовал простейший эвристический фильтр на основе 5-6 правил(обычных if'ов) получалось неплохо так фильтровать качественный маршрут без потери качества - при движении на высокой скорости точки ставились редко, при маневрах же маршрут начинал становится более плотным. Для работы нужно было помнить две предыдущих точки и текущую.
Как по мне -для трех хранимых точек в памяти устройства и десятка строк кода логики - отличный результат.
Издательство ДМК "Генетические алгоритмы на Python" Эйял Вирсански - даёт самый приятный и плавный ввод в эту тему. Саму книгу можно читать и не зная Python, а просто воспринимая его как псевдокод. Но тогда теряется другой плюс книги - автор для примеров использует одну из самых популярных библиотек по ГА в Python DEAP, так что после прочтения можно приступать к решению собственных задач с помощь серьезной библиотеки. Под мои задачи DEAP оказалась немного неудобной(нельзя легко сделать ту же "оценку ступенькой", приходится перегружать несколько классов и по мелочи(уже не помню), так что после пары доработок, я написал себе свои заготовки пустышки с чем и работаю до сих пор.
Самое главное в ГА - это отсутствие рамок. Если в книге в гене перемешивают биты, вы должны понимать что это лишь принцип, перемешивайте слова, ассесблерным инструкции, чаны с металлом, людей в очереди и т.п. ГА это лишь идея подходов, изложенная в конкретных примерах.
ГА(ГП) после восьми лет работы с ними для меня стали скорее философией, чем конкретными подходами. Так что на любой вопрос по ним я не могу дать четкого ответа, только собственное представление и понимание.
Давайте я отвечу примерами в упрощенном представлении задачи в контексте этой статьи - "расписание чанов с расплавом на отливку".
Да, но с особенностями. Все зависит от бюджета, рамок и сложности задачи. Можно каждый раз продолжать непрерывно искать от последнего найденного решения, а можно, к примеру купить стойку БД, куда оффлайн рассчитываем решение проблемы расписания с шагом, чтобы забить эту БД(разбиваем общую ситуацию на элементы, нумеруем их, получаем обобщенный хеш который в дальнейшем используем в качестве ключа), а после ищем всегда по алгоритму - текущая ситуация -> получаем хеш -> получаем из БД приближенное решение -> ищем от него более оптимальное от конкретной ситуации. Именно так можно гарантировать отработку ГА за заданное время(за время обращения к БД мы получим "среднее" НО решение).
От конкретной ситуации. Мне очень полюбился подход "ступенек", где у нас есть множество оценок решения, где мы смотрим на каждую последующую оценку только если предыдущие идентичны. (если хуже - решение отбрасываем, если лучше, соответственно - заменяем). Тогда "жесткие" условия задаются бинарной оценкой 0,1, суммируются и ставятся в самом начале. Неважно какая будет "мягкая" оценка(на второй позиции списка оценок), если ухудшается хоть один "жесткий" параметр - такое решение не пройдет. В контексте упомянутой БД, мы всегда можем рассчитать все решения так, чтобы не было нежелательных действий (к примеру "количество догревов"), ГП будет оптимизировать тогда что-то мягкое - "потери в рублях", "общее время простоя".
Могу предложить один из возможных вариантов - у нас на выходе будет полноценное "решение" - конкретное расписание, а не "решатель" как в случае нейросетей. Следовательно мы создаем верификатор "расписания", который содержит математическую/имитационную модель, сертифицируем ее а после подаем найденные решения ей на вход, конвертируя в удобный для верификатора формат. Она их одобряет и у нас на руках "сертифицированное" решение, а не программа которое их генерирует.
При множестве "правильных" решений(где есть чуть более и менее правильные) и очень широкой области поиска, неплохо подходит ГА, где ген - само расписание, а "актуальными" на данный момент ограничениями оценивается сам ген.
Тогда если рухнет стена и появилась новая связь - вводятся новые ограничения "оценщики" гена, а текущее расписание продолжает оптимизироваться.
Код при этом состоит из четких маленьких сущностей в один два экрана, а ограничения самостоятельны, просты и очевидны.
Радует развитие альтернатив reportlab для более простых задач!
До сих пор вспоминаю с мурашками по позвоночнику, как боролся с «плавающим» размером шрифта в какой-то старой версии reportlab при формировании оглавления. Шрифт уменьшался сам, лишь бы все влезло в одну строчку.
Выглядит потрясающе.
Минус таких печатей(или плюс?) — они отнимают внимание от текста в самом документе. Человек может потратить отведенное время на рассматривание мелочей в печати и пропустить что-то в ипотечном договоре.(это попадает в социальную инженерию ?)
Меня смутили размышления о том, как мы получаем энергию из РИТЭГов, чтобы потратить ее на нагрев станции, почему бы тепло не отводить от них напрямую на нагрев станции, а электричество пустить на светодиодное освещение и прочее? Тогда и РИТЭГов может уже тогда и не такое безумное количество нужно везти.
Убрали ULP сопроцессор? А ведь он позволял неплохо так оптимизировать «среднее» потребление, вынося многое из основного процессора.
Особенно выносить всю работу с кнопками как в обычном так и в режиме глубокого сна, отслеживать по i2c сенсорный экран, ожидая «пробуждающих» жестов, или «на ходу» корректировать интервал опроса датчиков в «солнечных» проектах мониторя заряд ионистора.
Я очень-очень далек от этой сферы, соответственно вопрос к тем кто разбирается — есть датчики детекторы газа к примеру CO2, разве не существует датчиков… пускай CO2 или для любого газа, для более разряженной среды — вакуума. С таким датчиком "облететь" модуль снаружи и по "тепло\холодно" найти где травит воздух?
Игр вспоминается много, но особенными были:
Sea Legends - за старт жанра пиратов
Colonization - за старт цивилизации
EF2000 - за отличную леталку
Creatures - за ИИ
Majesty - за концепт непрямого воздействия
Память может подводить, но у меня стойкое ощущение, что в Freelancer я летал с помощью джостика, да еще и подключался который через LPT или что то схожее тех времен.
На картинке, модуль экрана от компании WaveShare - тот еще образец opensource железа и программного обеспечения.
Личный опыт - купил E-Ink модуль с управляющим ARM контроллером. Поигрался, захотел вывести наш родной и могучий. Итог: схематика - закрыта, прошивка контроллера - закрыта, формат шрифтов - закрыт, по почте отвечали хамски и грубили, потом просто перестали отвечать.
Но… TSMC.
Никогда не думал, что это будет кому-то интересно. Сам код показать не смогу по достаточно простой причине - он пишется как ядро ИИ для игры.
Но могу рассказать подробности если вас интересует что то конкретное, или написать небольшую статью(если дойдут руки, но написание текстов даётся мне с трудом, с учётом моей безграмотности).
Эксперименты которые я проводил в основном сводятся к наблюдению над средневековым поселением в сотни, иногда тысячи человек, с проверкой различных теорий, вот некоторые из самых ярких: как будет меняться темп развития общества если детей будет растить спец институт вместо семьи, как можно уменьшить (отменить) инфляцию при государственном регулировании в рамках небольшого общества, какие эффекты даёт базовый гарантированный доход и т.п.
Самым интересным как по мне был годичный проект, где исследовал откуда берется цена на товар.(откуда берется та самая первая цена), где общество медленно и, главное, само переходило от бартера к некоторой форме покупки/продаж с промежуточной ценностью в виде денег.
— Задачи имеют некоторый динамический приоритет рассчитываемый от текущих желаний актера
— Если задача изменилась (или началась к исполнению с нуля) она формирует список шагов для ее достижения
— Исполняется шаг из очереди, если очередь пуста — переходим к следующей задаче по приоритету.
— Если другая задача превышает по приоритету текущую выше определенного значения — она отменяет текущую(и ее шаги) и становится актуальной задачей.
— Если шаг невозможно выполнить — обнуляется весь стек шагов. (на самом деле механизм чуть сложнее, но так проще объяснить базовый концепт)
Простой подход позволяет при, примерно, трех десятках задач сформировать неплохое такое общество из десятков тысяч актеров, имитирующих очень похожую на реальность жизнь небольшого общества, где каждый актер выполняет важную роль и демонстрирует индивидуальность, предпочтения и характер.
У меня есть схожий проект по оптимизации некоторого ассемблерного кода. Использую метод перебора\ГА.
Закладываем тестами весь требуемый функционал
Пишем(или даже не пишем) код решающий данный функционал
Запускаем ГА который наугад модифицирует код, переставляет команды и прочее
После каждой модификации прогоняются тесты и если они проходят, а код "оптимальнее" - код лидера подменяется найденным решением.
Работает медленно, приходится писать свой интерпретатор и эмулятор устройства, есть некоторые особенности по работе с адресами.
Но хорошо параллелится, процесс поиска легко разносится на вычислительный кластер, а код получается действительно отменный.
Делал как часть исследовательской работы для задач работы, но так и не применил, сменил работу, жду когда пригодится на новой.
После редактирования, отвалилась картинка - исправляюсь
Лет 5 назад со скуки делал хобби проект с gps. Использовал простейший эвристический фильтр на основе 5-6 правил(обычных if'ов) получалось неплохо так фильтровать качественный маршрут без потери качества - при движении на высокой скорости точки ставились редко, при маневрах же маршрут начинал становится более плотным. Для работы нужно было помнить две предыдущих точки и текущую.
Как по мне -для трех хранимых точек в памяти устройства и десятка строк кода логики - отличный результат.
Издательство ДМК "Генетические алгоритмы на Python" Эйял Вирсански - даёт самый приятный и плавный ввод в эту тему. Саму книгу можно читать и не зная Python, а просто воспринимая его как псевдокод. Но тогда теряется другой плюс книги - автор для примеров использует одну из самых популярных библиотек по ГА в Python DEAP, так что после прочтения можно приступать к решению собственных задач с помощь серьезной библиотеки. Под мои задачи DEAP оказалась немного неудобной(нельзя легко сделать ту же "оценку ступенькой", приходится перегружать несколько классов и по мелочи(уже не помню), так что после пары доработок, я написал себе свои заготовки пустышки с чем и работаю до сих пор.
Самое главное в ГА - это отсутствие рамок. Если в книге в гене перемешивают биты, вы должны понимать что это лишь принцип, перемешивайте слова, ассесблерным инструкции, чаны с металлом, людей в очереди и т.п. ГА это лишь идея подходов, изложенная в конкретных примерах.
ГА(ГП) после восьми лет работы с ними для меня стали скорее философией, чем конкретными подходами. Так что на любой вопрос по ним я не могу дать четкого ответа, только собственное представление и понимание.
Давайте я отвечу примерами в упрощенном представлении задачи в контексте этой статьи - "расписание чанов с расплавом на отливку".
Да, но с особенностями. Все зависит от бюджета, рамок и сложности задачи. Можно каждый раз продолжать непрерывно искать от последнего найденного решения, а можно, к примеру купить стойку БД, куда оффлайн рассчитываем решение проблемы расписания с шагом, чтобы забить эту БД(разбиваем общую ситуацию на элементы, нумеруем их, получаем обобщенный хеш который в дальнейшем используем в качестве ключа), а после ищем всегда по алгоритму - текущая ситуация -> получаем хеш -> получаем из БД приближенное решение -> ищем от него более оптимальное от конкретной ситуации. Именно так можно гарантировать отработку ГА за заданное время(за время обращения к БД мы получим "среднее" НО решение).
От конкретной ситуации. Мне очень полюбился подход "ступенек", где у нас есть множество оценок решения, где мы смотрим на каждую последующую оценку только если предыдущие идентичны. (если хуже - решение отбрасываем, если лучше, соответственно - заменяем). Тогда "жесткие" условия задаются бинарной оценкой 0,1, суммируются и ставятся в самом начале. Неважно какая будет "мягкая" оценка(на второй позиции списка оценок), если ухудшается хоть один "жесткий" параметр - такое решение не пройдет. В контексте упомянутой БД, мы всегда можем рассчитать все решения так, чтобы не было нежелательных действий (к примеру "количество догревов"), ГП будет оптимизировать тогда что-то мягкое - "потери в рублях", "общее время простоя".
Могу предложить один из возможных вариантов - у нас на выходе будет полноценное "решение" - конкретное расписание, а не "решатель" как в случае нейросетей. Следовательно мы создаем верификатор "расписания", который содержит математическую/имитационную модель, сертифицируем ее а после подаем найденные решения ей на вход, конвертируя в удобный для верификатора формат. Она их одобряет и у нас на руках "сертифицированное" решение, а не программа которое их генерирует.
При множестве "правильных" решений(где есть чуть более и менее правильные) и очень широкой области поиска, неплохо подходит ГА, где ген - само расписание, а "актуальными" на данный момент ограничениями оценивается сам ген.
Тогда если рухнет стена и появилась новая связь - вводятся новые ограничения "оценщики" гена, а текущее расписание продолжает оптимизироваться.
Код при этом состоит из четких маленьких сущностей в один два экрана, а ограничения самостоятельны, просты и очевидны.
До сих пор вспоминаю с мурашками по позвоночнику, как боролся с «плавающим» размером шрифта в какой-то старой версии reportlab при формировании оглавления. Шрифт уменьшался сам, лишь бы все влезло в одну строчку.
Минус таких печатей(или плюс?) — они отнимают внимание от текста в самом документе. Человек может потратить отведенное время на рассматривание мелочей в печати и пропустить что-то в ипотечном договоре.(это попадает в социальную инженерию ?)
Особенно выносить всю работу с кнопками как в обычном так и в режиме глубокого сна, отслеживать по i2c сенсорный экран, ожидая «пробуждающих» жестов, или «на ходу» корректировать интервал опроса датчиков в «солнечных» проектах мониторя заряд ионистора.
Я очень-очень далек от этой сферы, соответственно вопрос к тем кто разбирается — есть датчики детекторы газа к примеру CO2, разве не существует датчиков… пускай CO2 или для любого газа, для более разряженной среды — вакуума. С таким датчиком "облететь" модуль снаружи и по "тепло\холодно" найти где травит воздух?