Поддерживаю. Лучше какой-нибудь платный, проверенный..
А ещё лучше и роутер, который поддерживает vpn..

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

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

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

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

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

Вот пример оценок по времени и 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;
}
 

Разница, думаю, очевидна..

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

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;
}
 

Ну распараллелить это дело довольно легко, но всё равно довольно топорно и медленно получается..
Решит ли эту проблему окто-дерево? Ну не знаю, надо раскуривать эту тему.. Мне вот так сходу не очевидно..
Буду пробывать..

Хорошо, спасибо. Покурю в сторону octee. Хотя не уверен, что в данном случае это уместно.. Но в любом случае это полезно)

Ну-ну-ну.. Вся прелесть Монте-Карло алгоритмов как раз именно в рандомности.. Да, за это мы платим точностью. Но идея в том, чтобы скрестить наивный Монте с чем то, что подсказывало бы ему пулять ли в данном маленьком регион точки или нет..

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

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

Да, можно. Внутри куба можно дёрнуть любую точку и посчитать значение функции в ней.

Не понял, а вчём противоречие? У меня тоже всё существует)

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

Ой, ну это уже как-то сложно.. И врят ли мы выйграем на этом.. Не знаю, могу ошибаться..

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

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

А как организовать адаптивную сетку? Какой механизм?

Да ладно уж, молвите) У нас свобода слова) (Хотя у нас, в нашей путинской Россиии..)

П.С.
Свободу Алексею Навальному, Слава Украине, Жыве Беларусь!)
Россия обязательно будет свободной..

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

Ах, ну где же Вы "болезненное" увидели? Да, и "справедливую" лучше в кавычки)

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

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

Ну тут надо думать.. Я вот так с ходу радикально ничего бы не стал утверждать) 21 век на дворе, мало ли)

Ну как и в большинстве Ваших) Ладно..

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

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

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


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

 
 

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

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

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

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

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

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

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

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

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

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

Ой, ну это такое) Вы не представляете как мы на.. преподов, когда я учился в универе) Мы паспорта подделывали, чтоб наш друг смог в КАИ погступить) Билеты на концерты Киша, Ариии, Чижа.. и всегда пргоходили) Могоу Вам кучу историй рассказать) Были времена, когда у нас в мгозгоах было калёным коаксиальным кабелем выгравено: взломать систему)

Ну и шлите на.. такого препода..

Почему это сразу вялый? Я думаю, Вы знаете решение этой проблдемы..

Тут на канале ТехноШамана ролик вышел https://www.youtube.com/watch?v=U5yVw4uQNDo о непрерывном преобразовании одной картинки в другую) Вот будет время опробую это на Vande) Думаю, это даже круче будет его реализации на tensorflow 

Да.. Или как вариант:

C++ (Qt)
class Example {
public:
    static std::string BASE_DATA_DIR() {return "../data/"; };
    static std::string ORIG_DATA_DIR() {  return  BASE_DATA_DIR() + "images"; };
};