А она может и не решиться. Шумы измерений не позволят. можно решить ту же задачу с помощью МНК.
Да, я это и имел ввиду, систему уравнений составить с применением МНК.
Единственно, точек будет много и решать такую систему довольно затратно.
На 100K уравнений за разумное время (минуты) решается. А у вас очень сильно разреженная система будет, так что ещё быстрее.
Фильтр же позволяет делать корректировку прямо во время движения объекта.
Это его достоинство и он же недостаток. Когда мы решаем задачу как систему уравнений, то мы видим все измерения сразу, а фильтр только по очереди и в одну сторону. Поэтому, на мой взгляд, решая систему мы получим более точное решение.
Use of the C++ standard library and libc synchronization primitives in coroutines is forbidden.
Я правильно понимаю, что это распространяется на любой код, вызываемый в обработчиках? Например, есть библиотека чтения данных, у неё есть общий кэш, защищённый мьютексом, получается, я не могу её использовать? И так надо проводить анализ всех зависимостей? А если mutex не из std и libc, а из pthreads или openmp, то можно?
Применим ли данный фреймворк не только в рамках IO-bound программы, а при смешанной нагрузке? Что-то прочли, многопоточно посчитали, отправили результат далее.
Библиотека pybind11 это как пример, можно и без неё вызов python кода из c++ сделать, напрямую используя python.lib, просто, более муторно.
З.Ы. Даже самому интереснее, насколько это быстрее IPC. З.З.Ы. Не знаю requirements.txt для проекта у вас, но очень вероятно, что в нём есть что-то зависящее от pybind11, т.к. этот способ связывания python <-> c++ очень распространён сейчас.
Поэтому с учётом расстояния до облаков и времени распространения «светового эха» учёные определили расстояние до объекта, составившее 9 тысяч световых лет. Это гораздо меньше предыдущих найденных значений.
Можете посмотреть как я сделал GitHub Actions в своём проекте. Но сборочный скрипт и установку зависимостей придётся делать для каждого проекта свою. В том же файле и другие анализаторы есть. Также, рекомендую эту статью от разработчиков PVS.
Если разработчики, интересующих вас проектов, не пользуются статическими анализаторами на постоянной основе, то скорее всего ошибки будут, и самый главный вопрос, что вы с ними будете делать.
Было бы полезнее в примерах использовать OpenCL-CLHPP, написание хостового кода упрощается на порядок. И голова меньше болит про незакрытые ресурсы, и ошибки прилетают в виде аккуратных исключений.
Да, я это и имел ввиду, систему уравнений составить с применением МНК.
На 100K уравнений за разумное время (минуты) решается. А у вас очень сильно разреженная система будет, так что ещё быстрее.
Это его достоинство и он же недостаток. Когда мы решаем задачу как систему уравнений, то мы видим все измерения сразу, а фильтр только по очереди и в одну сторону. Поэтому, на мой взгляд, решая систему мы получим более точное решение.
А зачем фильтр Калмана? Можно же просто составить систему уравнений и решить её...
Какая-то странная арифметика. Сборка только в рабочее время идёт?
У вас интересное замечание там.
Я правильно понимаю, что это распространяется на любой код, вызываемый в обработчиках? Например, есть библиотека чтения данных, у неё есть общий кэш, защищённый мьютексом, получается, я не могу её использовать? И так надо проводить анализ всех зависимостей? А если mutex не из std и libc, а из pthreads или openmp, то можно?
Пытался найти тут пример под мой случай, там все, похоже, более простые.
Применим ли данный фреймворк не только в рамках IO-bound программы, а при смешанной нагрузке? Что-то прочли, многопоточно посчитали, отправили результат далее.
Память на линиях задержки
Интересная статья. Но ваш алгоритм на выходе может выдать результат с самопересечением для контуров с "петельками" радиусом менее отступа.
Вообще, эта тема хорошо представлена по ключевым словам "Offset curve".
Библиотека pybind11 это как пример, можно и без неё вызов python кода из c++ сделать, напрямую используя python.lib, просто, более муторно.
З.Ы. Даже самому интереснее, насколько это быстрее IPC.
З.З.Ы. Не знаю requirements.txt для проекта у вас, но очень вероятно, что в нём есть что-то зависящее от pybind11, т.к. этот способ связывания python <-> c++ очень распространён сейчас.
А почему бы не вызывать питоновский код напрямую из c++, например, через pybind11? Вообще никакого IPC не будет.
А может быть она к нам летит?
Изменился, просто, надо сюда заходить https://next.gptl.ru/
Так вы сравнивали с игровыми видеокартами. Для двойной точности у NVidia смотрите ускорители серии Tesla.
А как спасти тех, кто остался?
Очень сильные сомнения в верности этого утверждения.
Возможно, вам пригодится circular mean.
Можете посмотреть как я сделал GitHub Actions в своём проекте. Но сборочный скрипт и установку зависимостей придётся делать для каждого проекта свою. В том же файле и другие анализаторы есть. Также, рекомендую эту статью от разработчиков PVS.
Если разработчики, интересующих вас проектов, не пользуются статическими анализаторами на постоянной основе, то скорее всего ошибки будут, и самый главный вопрос, что вы с ними будете делать.
Создайте в этих проектах в пуллреквесте задачу в github-actions в которой запускается PVS, а ключик к PVS вам дадут. Он для opensource бесплатен.
Думаю, вам будет полезна книга Введение в контурный анализ; приложение к обработке изображений и сигналов.
Было бы полезнее в примерах использовать OpenCL-CLHPP, написание хостового кода упрощается на порядок. И голова меньше болит про незакрытые ресурсы, и ошибки прилетают в виде аккуратных исключений.