Russian Qt Forum
Ноябрь 25, 2024, 11:38 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Адаптивный Монте-Карло для размерности D > 1  (Прочитано 24087 раз)
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« : Ноябрь 04, 2021, 20:09 »

Приветствую, коллеги!

Недавно столкнулся с неизбежной проблемой считать многомерные интегралы, причём от очень "противных" функций.
Т.е. таких, которые имеют острые пики в некоторых областях региона интегрирования, а в остальном пространстве они практически нули и не дают вклад в сам интеграл.

К сожалению, всё самое интересное, что мы бы хотели узнать, лежит за пределами аналитических или приближённых методов, только лишь приближённо удаётся указать ту область, где подынтегральная функция будет давать наибольший вклад в сам интеграл.

И всё было бы ничего, сейчас, взять, например, boost или GSL -там туева хуча реализаций очень хороших численных схем интегрирования.. Но..
Но когда дело доходит до размерности большей 2, то всё становится (в контексте моей проблемы) немного печально.. А посчитать нужно.

Ну не долго думая, взяли мы направление на методы Монте-Карло интегрирования. Это очень простой метод и идеально параллелиться.
(кстатии есть как в упомянутом boost'е, так и в GSL (отдельный респект математикам из GSL - многое от туда подчерпнул)).

Единственная проблема - точность. Ошибка (+- err) асимптотически ведёт себя как 1/sqrt(N), где N - это число вызовов подынтегральной функции.
Т.е., чтоб точность на порядок повысить, нужно на два порядка увеличить число вызовов функции.. Ну такое себе.. И особенно остро это встаёт, когда характерный масштаб области интегрирования много много больше той ширины на которой существенно изменяется сама функция - мы её можем просто не увидеть (в смысле её изменение).

У меня были курсы по численному моделированию на которых я, в частности, рассказывал студентам об этой проблеме и как её можно более-менее обойти в Монте-Карло, а именно, подобрать функцию распределения (из каких-то знаний о характере подынтегральной функции) генерации случайных точек, в которых подынтегральная функция бы высчитовылась. Тогда большая часть выпадаемых точек приходилась бы на ту область, где функция наиболее сильно меняется..
Но здесь очередное но.. (но пока ещё не дно Улыбающийся)

Всё это хорошо если выполняются условия: 1. Вы умеете генерировать точки в соответсвии с заданным расспределением вероятности (я напомню, что нам интересен случай D >= 2) и, второе 2. Мы знаем о функции всё, что нам даёт хотя бы теоретическую возможность такое распределение сконструировать.. (а это, вообще говоря, отдельная нехилая проблема)

Таким образом, всаёт естественный вопрос: А, собственно, как? И можно ли?) И если кто-то сталкивался с подобными задачами, буду благодарен обсудить возможные идеи, а также обсудить свои.. Улыбающийся

Ладно, заканчиваю.
Всех с днём единства)    
Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #1 : Ноябрь 05, 2021, 12:12 »

Много занимался (и занимаюсь) расчетами пере-отражений света. Поскольку никакой конкретной постановки в стартовом посте нет, постараюсь кратко изложить свою

Вот есть 3D точка (x, y, z) и надо посчитать как она освещена окружающей сценой (вторичное освещение). Из точки выбрасывается заданное кол-во лучей, в точках их пересечения со сценой считается цвет, рез-т осредняется. Чистый монте-карлик. По сути это все. Но за этой "простой" постановкой масса сложнейших задач, о каждой написаны тысячи статей, но лишь немногие имеют проверенные решения. Обозначу некоторые, а Вы выберете что желаете обсуждать, иначе тема слишком обширна

1) Какие точки выбирать для расчета? Может все имеющиеся (в моем случае все видимые напрямую в сцене), но может и нет. Обычно/часто есть "моря", т.е. большие но неинтересные области где ровным счетом ничего не происходит, и было бы замечательно просчитать 5% точек и интерполировать остальные

2) Считать адаптивно. Минимальное число лучей 200. Давайте выбросим сначала напр 13 и посмотрим: если все они принесли один и тот же цвет - ну значит принимаем его и остальные не считаем (это соответствует областям 100% и 0% света). Так-то оно так, но всегда есть риск "пропустить". Один профессор (умер, хороший был мужик) высказал интересную мысль типа: если одна точка "пропустила", то соседние не пропустят. К сожалению, ни одной практической реализации этой задумки мне найти не удалось

Адаптивность можно понимать/трактовать и по-другому. Напр для соседних лучей разница в цвете оказалась достаточно велика - ну значит пытаемся "уточнить" это место добрасывая туда еще лучей. То же самое на уровне точек (пункт 1)

3) И самое страшное: эта хрень рекурсивна. Это я так сказал "считаем цвет в точках пересечения", на деле расчет цвета требует той же освещенности. Ну это так, для общего развития, такие задачи могут повредить std::голову

Что из этого (или что-то еще) Вы хотите обсуждать ?
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #2 : Ноябрь 05, 2021, 12:53 »

Цитировать
оскольку никакой конкретной постановки в стартовом посте нет, ...
Ну как и в большинстве Ваших) Ладно..

Цитировать
Вот есть 3D точка (x, y, z) и надо посчитать как она освещена окружающей сценой (вторичное освещение). Из точки выбрасывается заданное кол-во лучей, в точках их пересечения со сценой считается цвет, рез-т осредняется. Чистый монте-карлик.
Да, это хардкорный Монте-Карло. Т.е. как я понял из предыдущих обсуждений, мы виртуально испускаем "фотон" из интересующей нас точки и смотрим куда он воткнётся.. Я частично соглашусь - проблема похожа на мою, поскольку в пустую пулять по разным направлениям фотонами - дело бесперспективное.. Хорошо бы знать функцию распределения вероятности в каких направлениях пулять больше, а в каких не стоит вообще..

И здесь, под адаптивным Монте-Карло я подразумеваю то, что в самом процессе рассчёта, он сам конструирует эту самую функцию распределения..
И у нас есть критерий, за который мы можем зацепиться, чтоб такое поведение более-менее воссоздать.

Цитировать
1) Какие точки выбирать для расчета? Может все имеющиеся (в моем случае все видимые напрямую в сцене), но может и нет. Обычно/часто есть "моря", т.е. большие но неинтересные области где ровным счетом ничего не происходит, и было бы замечательно просчитать 5% точек и интерполировать остальные
А как Вы эти "моря" увидите заранее? Есть информация о них, или о них мы можем в принципе узнать проводя гипотетически бесконечное пуляние фотонами из заданной точки? Вот у меня такая информация более-менее известна. Т.е. я знаю где желательно больше точек ваыкидовать, а где нет..


Цитировать
2) Считать адаптивно. Минимальное число лучей 200. Давайте выбросим сначала напр 13 и посмотрим: если все они принесли один и тот же цвет - ну значит принимаем его и остальные не считаем (это соответствует областям 100% и 0% света). Так-то оно так, но всегда есть риск "пропустить". Один профессор (умер, хороший был мужик) высказал интересную мысль типа: если одна точка "пропустила", то соседние не пропустят. К сожалению, ни одной практической реализации этой задумки мне найти не удалось
Ну слушайте: когда Вы говорите слово "адаптивно", это подразумевает некую коррекцию на следующем шаге. Где у Вас намёк на то, что по известной информации от предыдущих результатах Вы корректируете параметры для следующего "пуляния"?

 
 

« Последнее редактирование: Ноябрь 05, 2021, 13:22 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #3 : Ноябрь 05, 2021, 14:02 »

Ну слушайте: когда Вы говорите слово "адаптивно", это подразумевает некую коррекцию на следующем шаге. Где у Вас намёк на то, что по известной информации от предыдущих результатах Вы корректируете параметры для следующего "пуляния"?
Грубо говоря "разница в цвете", о чем вверху сказано дважды. Если соседи (вычисленные значения) отличаются более чем на заданную величину - считать еще. Это можно делать как на уровне точек, так и на уровне лучей одной точки.

Что у Вас плохо - не определены "точки". Вот человек создал сцену - прицепил стандартные чайник и пол (плоскость). Отрендерил картинку. Теперь он хочет чтобы чайник отсвечивал на пол и наоборот. Для всех точек на картинке. Ну или "в общем" - вот комната, в ней светит лампочка или свет проникает сквозь окно. Но не все места освещены напрямую. Однако и в этих местах все хорошо видно, "темноты" нигде нет. На заре компутерной графики это решалось абы-как (доливался амбиент, ставились лампочки подсветки и.т.п.). Но сейчас др времена - вынь да положь "физически корректный" расчет (пусть и далеко не быстрый).

В своем изложении Вы опускаете такую "стартовую позицию", и все сразу "повисает в воздухе". Откуда берутся Ваши 3D точки (на худой конец 2D)? Они "все заранее известны" или есть объем в котором они заключены или как? Какой-то начальный просчет с (псевдо) равномерным шагом видимо неизбежен, можно начать и с этой позиции.

Ну как и в большинстве Ваших)
Ах как болезненно критикующий реагирует на (справедливую) критику  Улыбающийся
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #4 : Ноябрь 05, 2021, 14:48 »

Цитировать
Ах как болезненно критикующий реагирует на (справедливую) критику  Улыбающийся
Ах, ну где же Вы "болезненное" увидели? Улыбающийся Да, и "справедливую" лучше в кавычки)

Цитировать
Что у Вас плохо - не определены "точки". Вот человек создал сцену - прицепил стандартные чайник и пол (плоскость). Отрендерил картинку. Теперь он хочет чтобы чайник отсвечивал на пол и наоборот. Для всех точек на картинке. Ну или "в общем" - вот комната, в ней светит лампочка или свет проникает сквозь окно. Но не все места освещены напрямую. Однако и в этих местах все хорошо видно, "темноты" нигде нет. На заре компутерной графики это решалось абы-как (доливался амбиент, ставились лампочки подсветки и.т.п.). Но сейчас др времена - вынь да положь "физически корректный" расчет (пусть и далеко не быстрый).
Ну что я могу сказать.. Мой наивный подход заключался бы в следующем: Пуляем рандомно туеву хучу фотонов от источника света. Фиксируем максимальное число переотражений и тем самым определяем координаты точки, куда фотон попал в итоге. Вычисляем его "цвет".. Потом по известным точкам и их "цвету" воссоздаём полное изображение) См. недавнюю тему о восстановлении изображения.. Улыбающийся

Цитировать
В своем изложении Вы опускаете такую "стартовую позицию", и все сразу "повисает в воздухе". Откуда берутся Ваши 3D точки (на худой конец 2D)? Они "все заранее известны" или есть объем в котором они заключены или как? Какой-то начальный просчет с (псевдо) равномерным шагом видимо неизбежен, можно начать и с этой позиции.
Ну почему же.. У меня есть гипер куб- это область интегрирования.. Например для 1D - [x1, x2], для 2D - [x1, x2], [y1, y2]  и т.д..
Точки рандомно генерируются под капотом Монте-Карло внутри этого гипер кубика.
Проблема в том, что в каких то областях этого гипер кубика пулять бессмыслено, поскольку там всё с функцией гладко..

Цитировать
Какой-то начальный просчет с (псевдо) равномерным шагом видимо неизбежен, можно начать и с этой позиции.
Ну тут надо думать.. Я вот так с ходу радикально ничего бы не стал утверждать) 21 век на дворе, мало ли)

« Последнее редактирование: Ноябрь 05, 2021, 14:55 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #5 : Ноябрь 05, 2021, 14:58 »

Цитировать
Грубо говоря "разница в цвете", о чем вверху сказано дважды. Если соседи (вычисленные значения) отличаются более чем на заданную величину - считать еще. Это можно делать как на уровне точек, так и на уровне лучей одной точки.
Ну это не очень решение.. Вот предположим, Вы пуляете N фотонов в заданном маленьком телесном угле.. Вам прилетает в ответ N значений (пускай для простоты скаляров) f1, f2,... fN. Вот Вы их знаете: какой математический критерий Вы изберёте, чтоб прекратить далее пулять в этом телесном угле, или продолжить? Разница в "цвете"? Серьёзно?
Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #6 : Ноябрь 05, 2021, 15:30 »

Пуляем рандомно туеву хучу фотонов от источника света.
Это давно реализовано, но увы, устарело  (техника середины 90-x) и сдано в архив

Ну почему же.. У меня есть гипер куб- это область интегрирования.. Например для 1D - [x1, x2], для 2D - [x1, x2], [y1, y2]  и т.д..
А она "непрерывна"? Т.е. можно ли спокойно брать/заниматься любой точкой внутри куба? Заметим что напр в моей задаче это не так (точка должна существовать в сцене)

Точки рандомно генерируются под капотом Монте-Карло внутри этого гипер кубика.
Тут однозначно нужен псевдо (или квази) рандом. Предполагаем что есть "латиска" (3D сетка с достаточно малым шагом, хранить ее не надо).- Проходим 3 циклами по точкам латиски. Смотрим находится ли данная точка внутри радиусов уже имеющихся. Только если нет - добавляем эту точку в octree.

Проблема в том, что в каких то областях этого гипер кубика пулять бессмыслено, поскольку там всё с функцией гладко..
Инструмент - радиус захвата. Если есть доп инфа - она учитывается в радиусе. Т.е. он больше для "спокойных" областей и наоборот.

Это первый проход. Потом начинается "стягивание", напр разница между соседями значительна - уменьшаем их радиусы. В рез-те образуются новые "непокрытые" точки, считаем их, и.т.д

Ну это не очень решение.. Вот предположим, Вы пуляете N фотонов в заданном маленьком телесном угле.. Вам прилетает в ответ N значений (пускай для простоты скаляров) f1, f2,... fN. Вот Вы их знаете: какой математический критерий Вы изберёте, чтоб прекратить далее пулять в этом телесном угле, или продолжить? Разница в "цвете"? Серьёзно?
Да, серьезно. Напр
Цитировать
fabs(f1 - f2) > threshold
И "случайно" никто не пуляет, конечно нужно организовать адаптивную сетку и.т.п.

Ах, ну где же Вы "болезненное" увидели? Улыбающийся Да, и "справедливую" лучше в кавычки)
Не нравится - могу и помолчать  Улыбающийся
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #7 : Ноябрь 05, 2021, 16:41 »

Цитировать
Это давно реализовано, но увы, устарело  (техника середины 90-x) и сдано в архив
И что, в середине 90-х народ знал как изображения восстанавливать? Нейросети там и т.д.?

Цитировать
А она "непрерывна"? Т.е. можно ли спокойно брать/заниматься любой точкой внутри куба? Заметим что напр в моей задаче это не так (точка должна существовать в сцене)
Да, можно. Внутри куба можно дёрнуть любую точку и посчитать значение функции в ней.

Цитировать
Заметим что напр в моей задаче это не так (точка должна существовать в сцене)
Не понял, а вчём противоречие? У меня тоже всё существует)

Цитировать
Тут однозначно нужен псевдо (или квази) рандом.
Да, в Монтк-Карло он есть - это, собстенно суть метода: кидаем рандомные точки, вычисляем в них значения функции и усредняем. см. теорему о среднем..

Цитировать
Предполагаем что есть "латиска" (3D сетка с достаточно малым шагом, хранить ее не надо).- Проходим 3 циклами по точкам латиски. Смотрим находится ли данная точка внутри радиусов уже имеющихся. Только если нет - добавляем эту точку в octree.
Ой, ну это уже как-то сложно.. И врят ли мы выйграем на этом.. Не знаю, могу ошибаться..

Цитировать
Инструмент - радиус захвата. Если есть доп инфа - она учитывается в радиусе. Т.е. он больше для "спокойных" областей и наоборот.

Это первый проход. Потом начинается "стягивание", напр разница между соседями значительна - уменьшаем их радиусы. В рез-те образуются новые "непокрытые" точки, считаем их, и.т.д
Какие то сложные конструкции и термины пошли.. Ну такая стратегия подразумевает запоминания о предыдущих точках? Или заранее определённой сетке? Дело в том, что когда я генерю случайные точки, понятие сетки (grid) теряет смысл..  

Цитировать
Инструмент - радиус захвата. Если есть доп инфа - она учитывается в радиусе. Т.е. он больше для "спокойных" областей и наоборот.
...
Да, серьезно. Напр
А если, предположим, "цвет" может принимать как отрицательные, так и положительные значения?
Критерий того, что всё хорошо и гладко, когда у Вас на руках имеется N значений прилетевших Вам значений f1, f2, .. fN - это дисперсия.
Т.е. sigma^2 = 1/N * sum (fi - mean)^2  Дисперсия мала - значит всё ok, большая - нужно дальше пулять..
Точнее не сама дисперсия а вот такая величина sigma/sqrt(N)

Цитировать
И "случайно" никто не пуляет, конечно нужно организовать адаптивную сетку и.т.п.
А как организовать адаптивную сетку? Какой механизм?

Цитировать
Не нравится - могу и помолчать  Улыбающийся
Да ладно уж, молвите) У нас свобода слова) (Хотя у нас, в нашей путинской Россиии..)

П.С.
Свободу Алексею Навальному, Слава Украине, Жыве Беларусь!)
Россия обязательно будет свободной..
« Последнее редактирование: Ноябрь 05, 2021, 17:34 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #8 : Ноябрь 06, 2021, 08:22 »

Опускаю часть ответов чтобы не "растекаться"
Какие то сложные конструкции и термины пошли.. Ну такая стратегия подразумевает запоминания о предыдущих точках? Или заранее определённой сетке? Дело в том, что когда я генерю случайные точки, понятие сетки (grid) теряет смысл..  
Если Вы хотите "адаптивно", то хранить просчитанные точки - обязон. Стандартная техника octree (вариант multi). Оно также позволяет находить ближайших, но с учетом их радиусов, это мощнее чем kd-tree, хотя и ресурсов тратится намного больше. Регулярная сетка плоха своей "корреляцией", грубо говоря кто-то может вклиниться между рядами/столбцами. Да и "сгущать" ее довольно геморно. Другая крайность - чистый рандом, дескать
Цитировать
Монте-Карло - ну просто пуляем случайные точки
Это совсем не так, просто случайными ничего не добиться. Да, случайную не обманешь как регулярную, но она очень слаба "на восстановление", заполнить "пустоты" не удается даже при громадном числе точек. Octree предоставляет удобное решение/баланс. Даже если перебирать исходные точки с постоянным шагом и радиусом - все равно получится достаточно "живописная" картина отобранных (для расчета) точек. Вот правда "разпоточивание" этого шага нетривиально.

Хотя у нас...
Будьте добры, удалите ту хрень что Вы дальше написали. Не лезьте в говно что называется политикой. Этот форум (слава богу) для этого не предназначен
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #9 : Ноябрь 06, 2021, 11:15 »

Цитировать
Если Вы хотите "адаптивно", то хранить просчитанные точки - обязон. Стандартная техника octree (вариант multi). Оно также позволяет находить ближайших, но с учетом их радиусов, это мощнее чем kd-tree, хотя и ресурсов тратится намного больше. Регулярная сетка плоха своей "корреляцией", грубо говоря кто-то может вклиниться между рядами/столбцами. Да и "сгущать" ее довольно геморно. Другая крайность - чистый рандом, дескать
Хорошо, спасибо. Покурю в сторону octee. Хотя не уверен, что в данном случае это уместно.. Но в любом случае это полезно)

Цитировать
Это совсем не так, просто случайными ничего не добиться. Да, случайную не обманешь как регулярную, но она очень слаба "на восстановление", заполнить "пустоты" не удается даже при громадном числе точек. Octree предоставляет удобное решение/баланс. Даже если перебирать исходные точки с постоянным шагом и радиусом - все равно получится достаточно "живописная" картина отобранных (для расчета) точек. Вот правда "разпоточивание" этого шага нетривиально.
Ну-ну-ну.. Вся прелесть Монте-Карло алгоритмов как раз именно в рандомности.. Да, за это мы платим точностью. Но идея в том, чтобы скрестить наивный Монте с чем то, что подсказывало бы ему пулять ли в данном маленьком регион точки или нет..

Цитировать
Будьте добры, удалите ту хрень что Вы дальше написали. Не лезьте в говно что называется политикой. Этот форум (слава богу) для этого не предназначен
Нет. Когда в моей стране прямо здесь и сейчас происходит какой-то лютый трэш и мракобесие, я, к сожалению, не могу быть аполитичным, поскольку это меня напрямую затрагивает.. Так что извиняйте, не удалю.  
  

« Последнее редактирование: Ноябрь 06, 2021, 11:20 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #10 : Ноябрь 06, 2021, 13:36 »

Ну вот, к примеру, наивный однопоточный  Монте-Карло:

Код
C++ (Qt)
using bounds_t = std::vector<std::pair<double, double>>;
 
using grid_t = std::vector<size_t>;
 
 
class result_t
{
public:
   result_t() = default;
 
   result_t(const double & mean, const double & stddev)
       : m_mean(mean), m_stddev(stddev) {}
 
   double mean() const { return m_mean; }
 
   double stddev() const { return m_stddev; }
 
   double confidence_interval(const double & level = 0.997) const
   {
       using namespace boost::math;
       normal_distribution<double> dist;
       double t = quantile(complement(dist, (1.0-level)/2.0));
       return t*m_stddev;
   }
 
private:
   double m_mean;
   double m_stddev;
};
 
 
template <class F, class Tol>
inline result_t mc_integrate(const F & f, const bounds_t & bounds, const Tol & tol, size_t pps = 100)
{
   static thread_local std::random_device rd;
   static thread_local std::mt19937 gen(rd());
 
   size_t n = 0;
   double mean = 0.0;
   double variance = 0.0;
 
   std::vector<double> x(bounds.size());
 
   double V = 1.0;
   for (const auto & range : bounds)
       V *= (range.second - range.first);
 
   do {
 
       for (size_t i = 0; i < pps; ++i, ++n)
       {
           for (size_t j = 0; j < bounds.size(); ++j)
           {
               x[j] = std::uniform_real_distribution<double>(bounds[j].first, bounds[j].second)(gen);
           }
 
           double d = f(x) - mean;
           mean += d/(n+1);
           variance += d*d*n/(n+1);
       }
 
   } while (!tol(V*sqrt(variance/(n*n)), n));
 
   return result_t(V*mean, V*sqrt(variance/(n*n)));
}
 

Ну такое себе.. Очень топорный метод.
Вот пример рассчёта:
Код
C++ (Qt)
#include <iostream>
#include <cmath>
#include <vector>
 
#include <specmath/monte.h>
 
inline double func(const std::vector<double> & x)
{
   return exp(-x[0]*x[0] - x[1]*x[1] - x[2]*x[2] - x[3]*x[3]);
}
 
int main()
{    
   size_t point_per_step = 1000;
   size_t max_calls = 10000000;
 
   specmath::monte::bounds_t bounds{ {-10.0, 10.0}, {-10.0, 10.0}, {-10.0, 10.0}, {-10.0, 10.0} };
 
   auto res = specmath::monte::mc_integrate(func, bounds,
   [&](const double & err, size_t n)
   {
       return (err < 1.e-2) || (n > max_calls);
 
   }, point_per_step);
 
   // We use the 3 sigma rule (p = 0.997)
   std::cout << res.mean() << " +- " << res.confidence_interval(0.997) << std::endl;
   std::cout << "exact solution = " << M_PI*M_PI << std::endl;
 
   return 0;
}
 
Ну распараллелить это дело довольно легко, но всё равно довольно топорно и медленно получается..
Решит ли эту проблему окто-дерево? Ну не знаю, надо раскуривать эту тему.. Мне вот так сходу не очевидно..
Буду пробывать..


Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #11 : Ноябрь 22, 2021, 15:44 »

Нет, всё же окто дерево здесь ну никак.. Или я чего-то не понимаю..

Вот пример оценок по времени и confidence interval для адаптивного monte-carlo и наивного:
Код
C++ (Qt)
#include <iostream>
#include <cmath>
#include <vector>
#include <chrono>
 
#include <specmath/monte.h>
 
inline double func(const std::vector<double> & x)
{
   return exp(-x[0]*x[0] - x[1]*x[1] - x[2]*x[2] - x[3]*x[3]);
}
 
int main()
{    
   size_t point_per_step = 1000;
   size_t max_calls = 100000000000;
 
   specmath::monte::bounds_t bounds{ {-10.0, 10.0}, {-10.0, 10.0}, {-10.0, 10.0}, {-10.0, 10.0} };
 
   auto start = std::chrono::high_resolution_clock::now();
 
   auto res = specmath::monte::mc_integrate(func, bounds,
   [&](const double & err, size_t n)
   {
       return (err < 1.e-2) || (n > max_calls);
 
   }, point_per_step);
 
   auto stop = std::chrono::high_resolution_clock::now();
 
   auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(stop-start).count();
 
   std::cout << "duration (ms) = " << duration << std::endl;
 
   // We use the 3 sigma rule (p = 0.997)
   std::cout << res.mean() << " +- " << res.confidence_interval(0.997) << std::endl;
   std::cout << "exact solution = " << M_PI*M_PI << std::endl;
 
   specmath::monte::grid_t grid{ 100, 100, 100, 100 };
 
   specmath::monte::mc_integrator mc(100*100);
 
   start = std::chrono::high_resolution_clock::now();
 
   res = mc.integrate(func, bounds, grid, 1.e-2, 100);
 
   stop = std::chrono::high_resolution_clock::now();
 
   duration = std::chrono::duration_cast<std::chrono::milliseconds>(stop-start).count();
 
   std::cout << "duration (ms) = " << duration << std::endl;
 
   std::cout << res.mean() << " +- " << res.confidence_interval(0.997) << std::endl;
   std::cout << "exact solution = " << M_PI*M_PI << std::endl;
 
 
   return 0;
}
 
Разница, думаю, очевидна..
Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
qtkoder777
Частый гость
***
Offline Offline

Сообщений: 245


Просмотр профиля
« Ответ #12 : Январь 21, 2022, 19:39 »

А если обратиться к ИИ?
Дать ему выборку точно подсчитанных интегралов (считаем их так долго как это надо). Следующие интегралы ИИ подсчитает сам по алгоритму, полученному путём обучения. Я думаю, что GPT-3 справится.
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #13 : Январь 21, 2022, 21:02 »

А если обратиться к ИИ?
Дать ему выборку точно подсчитанных интегралов (считаем их так долго как это надо). Следующие интегралы ИИ подсчитает сам по алгоритму, полученному путём обучения. Я думаю, что GPT-3 справится.

Это задача не из этой области.
Предположим на вход нейронки подаём подынтегральную функцию и пределы интегрирования - на выходе число..
Вопросс, а если пределы будут другие?
А если функция кучу параметров имеет?
А если размерность пространства >> 1?

И, потом, какие обучающие функции брать и с какими пределами? Их бесконечное множество..

Короче, здесь никакой GPT-3 не сработает.. Здесь совершенно другая логика.  

И вообще, у меня, и, наверное, не только у меня на этом форуме, уже складывается стойкое подозрение, что Вы сами и есть GPT-3, судя по вашей гипертрофированной зацикленности на этой реализации ИИ)  

« Последнее редактирование: Январь 21, 2022, 21:06 от m_ax » Записан

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.138 секунд. Запросов: 23.