На самом деле проблема насущная. Я когда-то делал расчеты полета большого количества частиц на джаве. И так и не смог найти, где происходит порча чисел. Если бы был checked arithmetics, то проблем бы не было бы.
Неужели до сих пор в С/С++ нет опции checked arithmetics.
Насколько знаю, такие же проблемы в java. В математических расчетах это создает проблемы, когда число переполняется, а исключение не выкидывается.
В с# попроще — там есть опция на проект или служебное слово, после которого происходит проверка арифметических операций. Подобная опция есть delphi.
По моему она хороша для бизнес приложений, где нужна стабильность и переносимость.
А вот например GPU прикрутить или заблокировать кусок кода в физической памяти, чтобы он в swap никогда не уходил — это неспецифичные для джавы темы. Но эти неспефичные темы как раз и ограничивают её развитие.
но в таких задачках иногда не учитывают случай, когда прибор работал с ошибкой, но тем не менее выдал правильный результат. Если это учесть, то будет еще одна ветка в байесовском графе и финальные числа немного изменятся
Методов много, и даже можно свои придумывать. В данном случае на входе подаются так называемые априорные распределения. То это доопытные, но в тоже время хорошо проверенные функции. Насколько они удачно покрывают возможные экспериментальные процессы, настолько можно получать достоверные приближения. Плюс физики стремятся изолировать явления, чтобы они были простыми и хорошо описывались. В физике важна повторяемость и проверяемость. В конечном счете мерилом удачности модели является сам человек и насколько они считает полезными те или иные знания.
Пришел к выводу, что надо писать некий контейнер, в который помещаешь маленькие хотелки, которые выдают свои маленькие действия. Контейнер проверят, чтобы действия хотелок не противоречили друг другу.
Большая выборка включена в априорные распределения, которые подаются на вход Байеса. Но мы можем еще и выбирать между несколькими распределениями, делая их более или менее вероятными. Достаточно получить один белый шар, чтобы заключить, что белые шары имеются в большой выборке.
Не спорю, моделестроение — это тонкий процесс. Кто-то боится 5 свободных параметров включить. А кто-то и 200 миллионов включает. Например, глубокие нейронные сети содержат очень много параметров и каким-то образом выдают правильный результат несмотря на то, что эти параметры плавают.
Моделей много. Можно даже собрать супермодель, которая всех объединяет. Приписать каждой модели коэффициент её участия и оптимизировать эти коэффициенты точно так же, как я в статье оптимизирую theta
Для нейронок потребовалось много вычислительных ресурсов.
Я как-то писал нейронку, которая играет в крестики-нолики. В 3х3 учится за несколько минут против алгоритма. Но как только добавляешь размерность 5х5, то время становится очень большим из-за степенных и факториальных зависимостей. Даже ждать не стал, когда она найдет очевидную и выигрышную стратегию.
Да, все зависит от того, насколько модель покрывает реальные случаи. А в случае с динозаврами, — как это узнать, покрывает ли она или нет? Нужны дополнительные данные.
Но у Байеса есть один плюс — масштабируемость. Вы можете построить несколько моделей и связать их. Они будут уточнять друг друга из разных источников.
В принципе модель — это модель, а не реальность. По аналогии: карта — это не местность. Нельзя сделать карту идентичную местности. Местность изменяется со временем и содержит мелкие детали. И так же нельзя сделать точную модель, на которую можно положиться во всех случаях. Можно только попытаться сделать что-то, что будет полезно для определенных случаев.
А я не спорю. Нужно знать априорные, чтобы считать апостериорные. Плюс есть ход мысли от фиксированных данных к вероятности причин, а не стандартный ход от фиксированной модели к вероятным данным.
Если известны априорные вероятности, то можно считать апостериорные по одному случаю. В таких вопросах, как причина возникновения вселенной — неизвестны априорные. А вот в вопросах вынимания шариков — априорные известны и можно проводить оптимизацию параметров модели.
Где-то была задачка про больного, которого проверяют на приборе и обнаруживают редкую болезнь. Прибор может иногда врать и болезнь довольно редкая. Надо было посчитать вероятность реальной болезни. Получались забавные числа, — что не надо паниковать, а надо заново проверяться. Там был расчет пр Байесу с повторной проверкой на том же приборе и на другом приборе.
У меня не было цели осветить всю мат статистику. Просто напомнил, что есть метод, который дает считать статистику с одного примера. И дает обратный ход мысли — от заданных данных к вероятности причин.
Насколько знаю, такие же проблемы в java. В математических расчетах это создает проблемы, когда число переполняется, а исключение не выкидывается.
В с# попроще — там есть опция на проект или служебное слово, после которого происходит проверка арифметических операций. Подобная опция есть delphi.
По моему она хороша для бизнес приложений, где нужна стабильность и переносимость.
А вот например GPU прикрутить или заблокировать кусок кода в физической памяти, чтобы он в swap никогда не уходил — это неспецифичные для джавы темы. Но эти неспефичные темы как раз и ограничивают её развитие.
но в таких задачках иногда не учитывают случай, когда прибор работал с ошибкой, но тем не менее выдал правильный результат. Если это учесть, то будет еще одна ветка в байесовском графе и финальные числа немного изменятся
www.c-cpp.ru/content/longjmp
habr.com/ru/post/342302
Пришел к выводу, что надо писать некий контейнер, в который помещаешь маленькие хотелки, которые выдают свои маленькие действия. Контейнер проверят, чтобы действия хотелок не противоречили друг другу.
Я как-то писал нейронку, которая играет в крестики-нолики. В 3х3 учится за несколько минут против алгоритма. Но как только добавляешь размерность 5х5, то время становится очень большим из-за степенных и факториальных зависимостей. Даже ждать не стал, когда она найдет очевидную и выигрышную стратегию.
Но у Байеса есть один плюс — масштабируемость. Вы можете построить несколько моделей и связать их. Они будут уточнять друг друга из разных источников.
В принципе модель — это модель, а не реальность. По аналогии: карта — это не местность. Нельзя сделать карту идентичную местности. Местность изменяется со временем и содержит мелкие детали. И так же нельзя сделать точную модель, на которую можно положиться во всех случаях. Можно только попытаться сделать что-то, что будет полезно для определенных случаев.