За эти годы "Deep Blue" развивалась хотя бы аппаратно. Количество Mnps увеличилось втрое.
"Alpha Zero" же застыла на том же уровне. И это объяснимо: после достижения предела обучения продолжать обучать ИНС - только портить.
Надо просто создавать новую версию, но не просто на самообучении, а создать несколько вариантов и устроить между ними состязательный генетический отбор.
Ну, во-первых, речь идет, в первую очередь о том, является ли переборный алгоритм ИИ?
Во-вторых, у каждого подхода есть свои слабые стороны и ограничения. Для переборных алгоритмов их производительность (и сила) ограничены мощностью "железа", т.к. алгоритмические "улучшайзинги" уже исчерпаны. Может быть, возможен еще прорыв, но как-то мало в это верится.
Для ИИ на основе ИНС с подкреплением слабые стороны тоже известны. Прежде всего, это сваливание в локальный оптимум и переобучение. Эти два фактора мешают найти глобальный оптимум (что и произошло). Некоторый выход может быть основан на комбинированных методах, например, внедрением генетического алгоритма. Но это сильно увеличивает время обучения и, самое главное, работает только в простейших случаях, вроде "порхающих птичек" и "прыгающих динозавриков". Если ИНС становится действительно сложной, такой подход может превысить все разумные временные границы.
Возьмём обычный калькулятор. Он может выполнять арифметические операции, т. е. занимается "решением проблем" для человека. Продвинутые инженерные калькуляторы уже лет 40 назад могли решать уравнения, находить оптимумы функций и т.д. Т.е., пусть и не напрямую, но участвовали в "принятии решений".
Но при этом калькулятор не обладал собственным интеллектом. Он действовал строго в рамках программ и кодов, созданных человеческим естественным интеллектом. Ничего самостоятельно он открыть или изобрести не мог.
Так и "Deep Blue" следовал алгоритмам, созданным не самостоятельно, а человеческим интеллектом. Разумеется, со всеми корявостями и ошибками.
В этом и была его слабость - его возможности были ограничены возможностями его создателей. Пусть он считает в миллионы раз быстрее и побеждает самых сильных кожаных шахматистов играючи. Все равно за рамки перебора с альфа-бета отсечениями он выйти не может. Как не может самостоятельно изменить оценочную функцию позиции. Что заложили в него разработчики - то в нём и заложено. Таким образом, это не ИИ, а просто продолжение ЧЕИ (человеческого естественного интеллекта).
В "Deep Blue" искусственного интеллекта было не больше, чем в калькуляторе. Т.е. не было совсем.
В его основе был переборный алгоритм с альфа-бета отсечениями и оценкой позиций. Т.е. ровно то, что и в шахматных программах 60-х годов. Только создателям этого шахматного суперкомпьютера удалось достичь большей глубины перебора за отведенное время.
Первым ИИ в шахматах, действительно, можно считать "Alpha Zero", использующем ИНС на основе обучения с подкреплением.
Отличие "Alpha Zero" от "Deep Blue" не количественное, а качественное. Она уступает в тысячу раз по количеству рассматриваемых позиций, но при этом более качественно отсеивает из них бесперспективные.
Этому "Alpha Zero" никто не учил - она сама выработала для себя систему оценок позиций в результате многократной игры сама с собой. Поэтому её и можно считать ИИ. А "Deep Blue" - нет.
Делать цепочку из коммутаторов, тем более с включением неуправляемых, - не comme ill faut, как-то.
Мне ТП HPE доходчиво объясняла, что идеальная (с их точки зрения) топология сети состоит из центрального коммутатора HPE (к которому не присоединены оконечные пользователи) и прочих коммутаторов HPE (к которым присоединены пользователи, но не присоединены цепочкой другие коммутаторы). При настроенном SPT возможно соединения этих прочих между собой, но это плохо (т.е. никак) уживается с port-VLAN.
К сожалению, следовать их мудрым советам не получается. HPE-коммутаторы оказались не самыми надежными. И при пристройке новых помещений приходится присоединять их через цепочку коммутаторов.
Искать в таких условиях конфликт IP или внезапно появившееся новое устройство - тот еще квест.
Мой коллега написал собственную программу мониторинга (10-Strike и прочие его не впечатлили), которая позволяла делать это гораздо проще и оперативнее. Буквально за пару кликов показывает всё, включая порты коммутаторов, к которым подключены проблемные устройства.
К сожалению, система оповещения о разных инцидентах была у него реализована через telegram-бот/ А теперь у него просто руки опустились и желание допиливать программу куда-то исчезло. Да и толку-то в ней без системы оповещений?
Причина в том, что изогнуты только тайлы возвышенностей. А низинные тайлы плоские. Если изогнуть и их, приподнимая края на подходе к холмам, то они будут естественно образовывать подошвы холмов и таких щелей не будет.
Да, теперь понятно. Ни один из рукавов, по-отдельности, не запрещает появление прямого участка. А на самом деле он может соединить эти рукава "встречь".
Ну и точно так же возможно соединение встречь двух рек.
Так что, без указания направления течения не обойтись. Но это увеличит число тайлов с реками. Так вместо одного тайла с Т-образным слиянием/разделением рек (4 тайла с учетом поворотов) появятся 4 тайла с разными направлениями течения. А с учетом поворотов и отражений - 24.
На карте с расположенными объектами строится сеть Штейнера. Вернее, её подобие. Потому что настоящая сеть Штейнера строится на непрерывной поверхности с Евклидовой метрикой, а нам придется работать на дискретной гексагональной метрике. Да еще в условиях переменной стоимости прокладки дорог.
Первое обстоятельство, само по себе, не сильно усложняет проблему нахождения перекрёстков. Просто найти тайл, включающий точку Торричелли (если такая есть) и уточнить его симплекс-методом.
Но вот второе обстоятельство, в условиях сложного ландшафта, делает эту задачу нетривиальной:
Найденный тайл может содержать реку. Построить Т-образный мост на картинке можно, но на практике это лишено всякого смысла.
Найденный тайл может находиться в заливе или озере. Тогда никакой симплекс-метод не улучшит суммарную стоимость прокладки дорог. Да и где виданы дорожные развязки над водой?
Найденный тайл может находиться в окружении такого сложного ландшафта, что симплекс-метод, в лучшем случае, поможет слегка улучшить стоимость прокладки дорог (локальный минимум), но не найдет наилучшего способа (глобальный минимум).
Навскидку, пример для последнего случая:
Точка Торричелли находится в лесу внутри подковообразного хребта. Симплекс-метод определяет, что выбор тайла у основания подковы позволит укоротить два пути по лесу за счет удлинения одного пути по лесу. Но оптимальный способ прокладки дорог может заключаться в огибании хребта с внешней стороны подковы. Потому что там нет лесов вообще - одни равнины. Да и через горы прорубаться не надо. Пути получатся длиннее, но дешевле.
Можно было бы просто для всех тайлов внутри треугольника городов рассчитать суммарную стоимость дорог до этих трёх городов. Но дело в том, что ландшафт может быть таким сложным, что перекрёсток выгоднее расположить вообще за пределами треугольника городов. А это значит, что на него окажут влияние другие дороги и перекрёстки.
Но это еще не учитывает, что стоимость самих дорог может зависить не только от ландшафта, но и от качества. Например, к руинам дороги можно не прокладывать специально. Либо протоптать тропинку, стоимость которой околонулевая, а скорость передвижения - низкая (но выше, чем по бездорожью).
Если начинать генерацию реки с истока (якорный тайл), то закольцовки не будет. Собственно, направление, даже если его явно не задавать, уже будет реализовано при этом.
Разделяться на рукава река может. Только, ненадолго. Вот это уже сложнее реализовать. И в устье реки, обычно, разбиваются на множество рукавов.
А еще есть старицы - тупиковые застойные участки на месте бывшего русла.
Для реки это может быть исток или затока. Или залив моря.
У дороги это может быть участок, непосредственно примыкающий к поселению или каким-либо руинам. Не рисовать же на самих тайлах построек различные способы подведения дорог. Тем более, что деревья и постройки не помещаются тайлами, а помещаются поверх них следующим слоем. Т.е. на этом огрызке дороги может сверху располагаться куча щебня, бывшая храмом местного божка.
Города, руины, дороги, сложные ландшафты. Влияние ландшафта на характеристики юнитов.
И очень похожие на сгенерированные WFC карты. Хотя, быть такого не может. Игрушка старая - ей более 30 лет. А WFC получил распространение несколько лет назад.
Вероятность на то и вероятность, что вероятно всё, даже самое невероятное :)
Как используя процедурную тайловую генерацию объединить три города дорогами по схеме "звезда"?
Тут, скорее, надо с другой стороны танцевать:
Сначала сгенерить крупнокалиберную географию - моря, реки, хребты, отроги.
Затем сгенерить карты высот на основе удаления от гор-морей (и учитывать, что реки должны течь с уменьшением высоты или по равнине). Зашумить карты высот хоть Перлином, хоть еще как. Лишь бы рядом с реками не находились более низкие участки.
Потом сгенерить ландшафты и биомы на свободных клетках с учетом высот и удалений от гор/рек/морей. Т.е. это та же самая тайловая генерация, но высота будет играть роль регулятора вероятности.
Потом поставить города недалеко от рек и морей. Шахты у гор и в болотах, капища в лесах и холмах, руины везде.
Соединить города дорогами. Но не напрямую, в через систему перекрестков между ними (почти по Торричелли - выбирается некая точка между тремя городами и соединяется с городами, потом ищется вариант подешевле). Стоимость дорог учитывает ландшафт (на равнине дёшево, в лесах, холмах и болотах дорого, в горах крайне дорого). Это делается уже не тайловой генерацией, а поверх готового поля. Самые дорогие дороги можно исключить, но так, чтобы на нарушить связности.
Тема генерации тайловых карт не раскрыта в плане приближения к реальным ландшафтам:
Как обеспечить, что горы не будут группироваться в сплошные массивы, а будут образовывать хребты и отроги?
Как обеспечить, что реки будут стекать с гор и возвышенностей (водоразделов), а не пересекать их?
Как обеспечить, что реки будут сливаться, а не разделяться? Но возможно образование рукавов и стариц.
Как обеспечить, что реки будут впадать в моря (можно и в озера, но при этом должны и вытекать из них), а не прерываться или заканчиваться в чистом поле?
Как обеспечить, что дороги будут соединять города/посёлки/святилища/шахты и т.д., а не обрываться и не закольцовываться?
Как обеспечить более-менее оптимальную схему дорог с учетом проходимости ландшафта?
За эти годы "Deep Blue" развивалась хотя бы аппаратно. Количество Mnps увеличилось втрое.
"Alpha Zero" же застыла на том же уровне. И это объяснимо: после достижения предела обучения продолжать обучать ИНС - только портить.
Надо просто создавать новую версию, но не просто на самообучении, а создать несколько вариантов и устроить между ними состязательный генетический отбор.
Ну, во-первых, речь идет, в первую очередь о том, является ли переборный алгоритм ИИ?
Во-вторых, у каждого подхода есть свои слабые стороны и ограничения. Для переборных алгоритмов их производительность (и сила) ограничены мощностью "железа", т.к. алгоритмические "улучшайзинги" уже исчерпаны. Может быть, возможен еще прорыв, но как-то мало в это верится.
Для ИИ на основе ИНС с подкреплением слабые стороны тоже известны. Прежде всего, это сваливание в локальный оптимум и переобучение. Эти два фактора мешают найти глобальный оптимум (что и произошло). Некоторый выход может быть основан на комбинированных методах, например, внедрением генетического алгоритма. Но это сильно увеличивает время обучения и, самое главное, работает только в простейших случаях, вроде "порхающих птичек" и "прыгающих динозавриков". Если ИНС становится действительно сложной, такой подход может превысить все разумные временные границы.
Да, это определение сильно устарело ...
Возьмём обычный калькулятор. Он может выполнять арифметические операции, т. е. занимается "решением проблем" для человека. Продвинутые инженерные калькуляторы уже лет 40 назад могли решать уравнения, находить оптимумы функций и т.д. Т.е., пусть и не напрямую, но участвовали в "принятии решений".
Но при этом калькулятор не обладал собственным интеллектом. Он действовал строго в рамках программ и кодов, созданных человеческим естественным интеллектом. Ничего самостоятельно он открыть или изобрести не мог.
Так и "Deep Blue" следовал алгоритмам, созданным не самостоятельно, а человеческим интеллектом. Разумеется, со всеми корявостями и ошибками.
В этом и была его слабость - его возможности были ограничены возможностями его создателей. Пусть он считает в миллионы раз быстрее и побеждает самых сильных кожаных шахматистов играючи. Все равно за рамки перебора с альфа-бета отсечениями он выйти не может. Как не может самостоятельно изменить оценочную функцию позиции. Что заложили в него разработчики - то в нём и заложено. Таким образом, это не ИИ, а просто продолжение ЧЕИ (человеческого естественного интеллекта).
В "Deep Blue" искусственного интеллекта было не больше, чем в калькуляторе. Т.е. не было совсем.
В его основе был переборный алгоритм с альфа-бета отсечениями и оценкой позиций. Т.е. ровно то, что и в шахматных программах 60-х годов. Только создателям этого шахматного суперкомпьютера удалось достичь большей глубины перебора за отведенное время.
Первым ИИ в шахматах, действительно, можно считать "Alpha Zero", использующем ИНС на основе обучения с подкреплением.
Отличие "Alpha Zero" от "Deep Blue" не количественное, а качественное. Она уступает в тысячу раз по количеству рассматриваемых позиций, но при этом более качественно отсеивает из них бесперспективные.
Этому "Alpha Zero" никто не учил - она сама выработала для себя систему оценок позиций в результате многократной игры сама с собой. Поэтому её и можно считать ИИ. А "Deep Blue" - нет.
Делать цепочку из коммутаторов, тем более с включением неуправляемых, - не comme ill faut, как-то.
Мне ТП HPE доходчиво объясняла, что идеальная (с их точки зрения) топология сети состоит из центрального коммутатора HPE (к которому не присоединены оконечные пользователи) и прочих коммутаторов HPE (к которым присоединены пользователи, но не присоединены цепочкой другие коммутаторы). При настроенном SPT возможно соединения этих прочих между собой, но это плохо (т.е. никак) уживается с port-VLAN.
К сожалению, следовать их мудрым советам не получается. HPE-коммутаторы оказались не самыми надежными. И при пристройке новых помещений приходится присоединять их через цепочку коммутаторов.
Искать в таких условиях конфликт IP или внезапно появившееся новое устройство - тот еще квест.
Мой коллега написал собственную программу мониторинга (10-Strike и прочие его не впечатлили), которая позволяла делать это гораздо проще и оперативнее. Буквально за пару кликов показывает всё, включая порты коммутаторов, к которым подключены проблемные устройства.
К сожалению, система оповещения о разных инцидентах была у него реализована через telegram-бот/ А теперь у него просто руки опустились и желание допиливать программу куда-то исчезло. Да и толку-то в ней без системы оповещений?
Причина в том, что изогнуты только тайлы возвышенностей. А низинные тайлы плоские. Если изогнуть и их, приподнимая края на подходе к холмам, то они будут естественно образовывать подошвы холмов и таких щелей не будет.
Увы, как говорил Крош из Смешариков: "Я больше по теории".
Наверное, самая большая трудность построения сети Штейнера, что это NP-полная задача.
Существуют приблизительные методы (тоже не очень простые), но все они для Евклидовой метрики. И без учета переменного ландшафта.
Ну, это не будет называться рекой. Это будет заливом, фьордом или бухтой.
Да, теперь понятно. Ни один из рукавов, по-отдельности, не запрещает появление прямого участка. А на самом деле он может соединить эти рукава "встречь".
Ну и точно так же возможно соединение встречь двух рек.
Так что, без указания направления течения не обойтись. Но это увеличит число тайлов с реками. Так вместо одного тайла с Т-образным слиянием/разделением рек (4 тайла с учетом поворотов) появятся 4 тайла с разными направлениями течения. А с учетом поворотов и отражений - 24.
Я тут немного освежил память по поводу п.5:
На карте с расположенными объектами строится сеть Штейнера. Вернее, её подобие. Потому что настоящая сеть Штейнера строится на непрерывной поверхности с Евклидовой метрикой, а нам придется работать на дискретной гексагональной метрике. Да еще в условиях переменной стоимости прокладки дорог.
Первое обстоятельство, само по себе, не сильно усложняет проблему нахождения перекрёстков. Просто найти тайл, включающий точку Торричелли (если такая есть) и уточнить его симплекс-методом.
Но вот второе обстоятельство, в условиях сложного ландшафта, делает эту задачу нетривиальной:
Найденный тайл может содержать реку. Построить Т-образный мост на картинке можно, но на практике это лишено всякого смысла.
Найденный тайл может находиться в заливе или озере. Тогда никакой симплекс-метод не улучшит суммарную стоимость прокладки дорог. Да и где виданы дорожные развязки над водой?
Найденный тайл может находиться в окружении такого сложного ландшафта, что симплекс-метод, в лучшем случае, поможет слегка улучшить стоимость прокладки дорог (локальный минимум), но не найдет наилучшего способа (глобальный минимум).
Навскидку, пример для последнего случая:
Точка Торричелли находится в лесу внутри подковообразного хребта. Симплекс-метод определяет, что выбор тайла у основания подковы позволит укоротить два пути по лесу за счет удлинения одного пути по лесу. Но оптимальный способ прокладки дорог может заключаться в огибании хребта с внешней стороны подковы. Потому что там нет лесов вообще - одни равнины. Да и через горы прорубаться не надо. Пути получатся длиннее, но дешевле.
Можно было бы просто для всех тайлов внутри треугольника городов рассчитать суммарную стоимость дорог до этих трёх городов. Но дело в том, что ландшафт может быть таким сложным, что перекрёсток выгоднее расположить вообще за пределами треугольника городов. А это значит, что на него окажут влияние другие дороги и перекрёстки.
Но это еще не учитывает, что стоимость самих дорог может зависить не только от ландшафта, но и от качества. Например, к руинам дороги можно не прокладывать специально. Либо протоптать тропинку, стоимость которой околонулевая, а скорость передвижения - низкая (но выше, чем по бездорожью).
Если начинать генерацию реки с истока (якорный тайл), то закольцовки не будет. Собственно, направление, даже если его явно не задавать, уже будет реализовано при этом.
Разделяться на рукава река может. Только, ненадолго. Вот это уже сложнее реализовать. И в устье реки, обычно, разбиваются на множество рукавов.
А еще есть старицы - тупиковые застойные участки на месте бывшего русла.
Да, направление - первое, что приходит на ум. Но вряд ли его одного будет достаточно.
Ну так это тайлы из предлагаемой реализации.
Для реки это может быть исток или затока. Или залив моря.
У дороги это может быть участок, непосредственно примыкающий к поселению или каким-либо руинам. Не рисовать же на самих тайлах построек различные способы подведения дорог. Тем более, что деревья и постройки не помещаются тайлами, а помещаются поверх них следующим слоем. Т.е. на этом огрызке дороги может сверху располагаться куча щебня, бывшая храмом местного божка.
Эх ... Даже в WarLords-2 захотелось поиграть :)
Города, руины, дороги, сложные ландшафты. Влияние ландшафта на характеристики юнитов.
И очень похожие на сгенерированные WFC карты. Хотя, быть такого не может. Игрушка старая - ей более 30 лет. А WFC получил распространение несколько лет назад.
Аналогичный случай. Кубик крутится, шарик вертится. А демка не открывается.
Еще как!
https://i.pinimg.com/originals/4c/14/ae/4c14aed15ad731fe5549063cabe3b6a0.jpg
Поясните, пожалуйста.
Вероятность на то и вероятность, что вероятно всё, даже самое невероятное :)
Как используя процедурную тайловую генерацию объединить три города дорогами по схеме "звезда"?
Тут, скорее, надо с другой стороны танцевать:
Сначала сгенерить крупнокалиберную географию - моря, реки, хребты, отроги.
Затем сгенерить карты высот на основе удаления от гор-морей (и учитывать, что реки должны течь с уменьшением высоты или по равнине). Зашумить карты высот хоть Перлином, хоть еще как. Лишь бы рядом с реками не находились более низкие участки.
Потом сгенерить ландшафты и биомы на свободных клетках с учетом высот и удалений от гор/рек/морей. Т.е. это та же самая тайловая генерация, но высота будет играть роль регулятора вероятности.
Потом поставить города недалеко от рек и морей. Шахты у гор и в болотах, капища в лесах и холмах, руины везде.
Соединить города дорогами. Но не напрямую, в через систему перекрестков между ними (почти по Торричелли - выбирается некая точка между тремя городами и соединяется с городами, потом ищется вариант подешевле). Стоимость дорог учитывает ландшафт (на равнине дёшево, в лесах, холмах и болотах дорого, в горах крайне дорого). Это делается уже не тайловой генерацией, а поверх готового поля. Самые дорогие дороги можно исключить, но так, чтобы на нарушить связности.
Вот как-то так.
У меня тоже ссылка не работает. Пишет, что устройство или браузер не соответствует требованиям.
Пробовал на разных браузерах. Но на работе у меня Win8.1ю Дома попробую на Win10.
Если у кого получилось зайти в демку - напишите, что требуется.
Я уже писал выше, что река не может "заканчиваться" иначе, чем впадением в море.
Так же как и дороги не могут прерываться, кроме как на объектах, которые они соединяют.
Петли дорог и рек на равнинах - тоже могут возникнуть в некоторых случаях.
Тема генерации тайловых карт не раскрыта в плане приближения к реальным ландшафтам:
Как обеспечить, что горы не будут группироваться в сплошные массивы, а будут образовывать хребты и отроги?
Как обеспечить, что реки будут стекать с гор и возвышенностей (водоразделов), а не пересекать их?
Как обеспечить, что реки будут сливаться, а не разделяться? Но возможно образование рукавов и стариц.
Как обеспечить, что реки будут впадать в моря (можно и в озера, но при этом должны и вытекать из них), а не прерываться или заканчиваться в чистом поле?
Как обеспечить, что дороги будут соединять города/посёлки/святилища/шахты и т.д., а не обрываться и не закольцовываться?
Как обеспечить более-менее оптимальную схему дорог с учетом проходимости ландшафта?
И т.д.