Утверждён стандарт C++20

Многие задачи пишутся индусами через анус, потому не только параллелятся плохо, но вообще плохо работают и постоянно падают.

распараллель сортировку для произвольных объектов, всякие gcc, LLVM, Intel и Microsoft не могут добиться хорошей параллельности для этой задачи…

немного пишут, есть даже успешные, в чем проблема?

если там ансиси, да даже если гну это обычное дело 10к капля в море для С.

распараллель сортировку для произвольных объектов, всякие gcc, LLVM, Intel и Microsoft не могут добиться хорошей параллельности для этой задачи

Я уверен, что ты заблуждаешься. Поскольку ты не приводишь конкретики, то я могу лишь предположить, что ты заблуждаешься в том, что обращаешь внимание на плохо параллелизуемые алгоритмы сортировки. Например, мало кто знает, что самая эффективная сортировка на ЦП общего назначения в пределах кэша — это сортировка пузырьком. А одна из лучших параллельных сортировок:

https://en.wikipedia.org/wiki/Bitonic_sorter

Именно с тех пор, как они позволили выполнять на себе произвольную логику, они перестали быть «Application Specific», и стали «General Purpose».

сейчас эти понятия размылись, ASIC-ми называют и SoC с CPU, но GPU даже переводится как графический процессор, так что мимо - это однознвчно ASIC

FPGA всегда уделывают процессоры по производительности и эффективности на узких задачах

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

ASIC-ми называют и SoC с CPU, но GPU даже переводится как графический процессор, так что мимо - это однознвчно ASIC

Фигасе ты квадратно-гнездовой. Очевидно, что ты можешь взять какой-нибудь OpenSPARC/MIPS/Power, добавить в него минимальную жесткую логику, и получить ASIC. И получится специализированная логика, налепленная на логику общего назначения. Просто потому, что проектировать и изготовливать чипы стало так достаточно просто, и уже на на бюджетах в единицы миллионов долларов к этому прибегают. Произошло это как по причине повышения производительности компов, на которых проектировка происходит, так и по причине повышения плотности компонентов при той же цене производства — даже у китайцев есть свое производство 65 нм.

Сейчас, вон, интель сует в каждый процессор видеокарту — и типа как его тогда судить по твоей классификации? Ну типа я же могу вообще совсем не пользоваться его видеокартой, да?

SoC с процессором содержит в себе специализированные функции, но только частично. Потому я и пишу, что тензорные ядра — это специализированная часть кристалла. Сами поточные мультипроцессоры a.k.a. шейдеры — вполне себе общего назначения. Да, на GPU есть еще некоторые узлы, которые тоже являются специализированными, но при использовании для вычислений общего назначения они просто не задействуются.

FPGA и процессоры общего назначения глупо сравнивать - речь шла об ASIC

Ой, ты прав, я неправильно прочитал твое сообщение. Да, ASIC более эффективный, безусловно. Но дорогой в изготовлении и помимо своего применения ты его никуда не всунешь. В случае FPGA ты стоимость разработки чипа можешь распределить по большому числу потребителей — в этом и заключается вся идеология микросхем. По этой причине есть конторы, которые делают разные ASIC-и из одного комплекта готовых масок, просто изготавливая еще пару масок с соединениями, что получается сильно дешевле изготовления ASIC-а с нуля. По энерогоэффективности и производительности получается что-то среднее между ASIC и FPGA.

FPGA в массовых изделиях не применяют - это невыгодно по всем параметрам, специальные процессоры дешевле, быстрей, проще в интеграции и программировании и потребляют на порядок меньше

В массовых изделиях очень часто применяют процессоры общего назначения, с минимальными модификациями или вообще без онных. Тот же ARM доайфоновый вполне себе позволяет производить производить ввод-вывод без каких-либо модификаций чипа. И вот на этом фоне FPGA смотрися вполне себе неплохо, поскольку позволяет совать один и тот же чип в разные устройства. Часто ограничивающим фактором становится то, что производитель хочет защитить свою логику от копирования — в том числе поэтому даже весьма банальную аналоговую логику пытаются совать в ASIC.

Многие задачи пишутся индусами через анус, потому не только параллелятся плохо, но вообще плохо работают и постоянно падают.

Индусы тут вообще не причем. Есть класс задач, которые решаются рекуррентными алгоритмами. Эти алгоритмы в принципе работают последовательно. Вы не можете начать итерацию номер n+1 пока не завершена итерация n. Все что можно распараллелить это собственно текущую итерацию, если есть что. Несколько итераций одновременно запустить нельзя. Точка.

Последовательное выполнение команд — это путь вникуда, и сам x86 это доказал, перейдя на суперскалярное выполнение.

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

TL;DR Есть класс задач, широко встречающийся на практике, где важна производительность на ядро. В этих задачах arm, к моему сожалению, по прежнему сливается amd64. И хотя во многих случаях arm-а уже хватает, тем не менее полноценной заменой amd64 он не является.

Индусы тут вообще не причем. Есть класс задач, которые решаются рекуррентными алгоритмами. Эти алгоритмы в принципе работают последовательно. Вы не можете начать итерацию номер n+1 пока не завершена итерация n. Все что можно распараллелить это собственно текущую итерацию, если есть что. Несколько итераций одновременно запустить нельзя. Точка

Назови мне этот алгоритм. «Есть, есть» — где есть, я не вижу таких задач. Выше чел говорил, что сортировку не умеют делать параллельно — почему-то оказалось, что прекрасно умеют. Не путай «я не умею» с «нельзя так сделать».

Ничего не умеют.

На 64 ядерном процессоре ускорение будет лишь в ~8 раз.

Именно про это я и писал. Линейного ускорения у сортировок нет. Мог бы погуглить результаты ускорения.

Есть отдельные алгоритмы которые параллелятся лучше, но там нужны специальные типы данных (aka RadixSort для unsigned int)

Назови мне этот алгоритм. «Есть, есть» — где есть, я не вижу таких задач.

Какой горячий! Ну так ты погугли, я же термин тебе привел. Не путай «я не знаю» с «этого не существует».

На всякий случай на пальцах расскажу тебе про фильтр Калмана. У него есть две этапа выполнения - экстраполяции и обновления. На каждом этапе используются данные от предыдущего. Если у тебя есть 100 отсчетов, то ты должен проинициализировать фильтр и затем последовательно выполнить экстраполяцию для 0-го отсчета, затем обновление для 0-го отсчета (где ты будешь использовать результаты экстраполяции из предыдущего этапа), затем ты снова делаешь экстраполяцию на 1-ом отсчете (используя данные из этапа обновления на 0-ом отсчете) и затем делаешь обновление на 1-ом отсчете и т.д. до 99-го отсчета. И все это ПОСЛЕДОВАТЕЛЬНО, потому что фильтр формирует текущую оценку на основе предыдущей.

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

На 64 ядерном процессоре ускорение будет лишь в ~8 раз.
Именно про это я и писал. Линейного ускорения у сортировок нет. Мог бы погуглить результаты ускорения

Во-первых, это нелинейный рост производительности с числом потоков является следствием архитектуры современных нищекомпов. Хотя бы тупо потому, что системная шина одна, и даже если ты в фоне запустишь «stress -m», то у тебя результат будет хуже, чем с незагруженной шиной.

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

На всякий случай на пальцах расскажу тебе про фильтр Калмана

Фильтр Калмана применяется тогда, когда у тебя есть только текущее значение и ты не можешь торопить события. Обычно это значит обработку информации в реальном времени — ускорять нечего и некуда. Обработка независимых значений фильтрами Калмана прекрасно параллелизуется. Если же у тебя есть готовый большой массив входных значений с произвольным доступом, из которых тебе нужно убрать шум, то тебе не нужен фильтр Калмана.

Да, да, расскажи мне сказки на ночь.

Обычно это значит обработку информации в реальном времени — ускорять нечего и некуда.

С каких это пор обработка в реальном масштабе времени означает что ускорять нечего и некуда? А мужики то не знали!

Обработка независимых значений фильтрами Калмана прекрасно параллелизуется.

Независимые они на то и независимые, чтобы их обработка не зависела друг от друга. Да вот только не всегда они независимы, а еще бывает что не всегда ясно, какие значения зависимы, а какие - нет. И определение этого - та же самая рекуррентная задача. И локализация данных может значительно меняться вплоть до того что кластеризация невозможна из-за равномерного распределения данных.

Я понимаю, что ты не сталкивался с такими задачами, но утверждать, что таких задач не может быть уж точно не нужно. И производительность ядра в этих задачах рулит.

Обычно это значит обработку информации в реальном времени — ускорять нечего и некуда.

Ого! А мужики-то и не знали, что шаг измерения и предсказания ничего не стоит.

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

Перефразируя, «если тебе не нужен фильтр Калмана, то тебе не нужен фильтр Калмана». Спасибо, капитан очевидность.

По данным TIOBE С++ набирает популярность как никогда, во всяком случае, со времен 2003г., когда его рейтинг просел до второй десятки. CEO TIOBE связывает сегодняшний рост популярности с выходом С++20 и особенно с появлением фичи модулей, которые призваны заменить уродливые конструкции для препроцессора.

https://www.tiobe.com/tiobe-index/

Печаль, F# пропал из топ-50, хотя в том году был на ~40 месте…

Например, мало кто знает, что самая эффективная сортировка на ЦП общего назначения в пределах кэша — это сортировка пузырьком

На этом форуме все знают, что ты балаболка необразованная, но для тех, кто не знает, расскажу.

Insertion sort имеет примерно такую же кеш-локальность и является значительно более быстрым алгоритмом. Insertion sort практически, то есть, на практике, уничтожает пузырек полностью.

Как ты оценишь производительность и эффективость ядер arm и х86, если любая/каждая ОС писалась именно под х86 архитектуру. И ПО соответвенно. ARM через костыли в этих ОС и соответсвенно ПО .

Чтобы говорить о производительности и эффективности нужно написать ОС с учетом особенностей данной архитектуры и уже сверху писать ПО. Будет или нет совместимость с х86 - это пофигу абсолютно.

Вот только тогда можно будет адекватно сравнить производительность ядер!

С каких это пор обработка в реальном масштабе времени означает что ускорять нечего и некуда? А мужики то не знали!

Ну давай, придумай мне в ответку на ночь истории о том, где это нужно миллиард раз в секунду корректировать выходной сигнал по входному сигналу, да еще и с обработочкой по Калману. Все механические, видео-, аудиосигналы кончаются где-то на сотнях килогерц. Что ты собрался фильтровать на десятках мегагерц? А ниже уже возникают дешевые как грязь и крайне энергоэффективные FET чипы, работающие на частоте в десятки мегагерц и потребляющие единицы милливатт в пике ярости. Я повторю свой вопрос:

где есть, я не вижу таких задач

Ты снова придумываешь абстрактную задачу, которая не имеет отношения к реальности, но теоретически не параллелится, а значит доказывает твою позицию. Правда, не опровергает мою.

Да вот только не всегда они независимы, а еще бывает что не всегда ясно, какие значения зависимы, а какие - нет. И определение этого - та же самая рекуррентная задача

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

Ого! А мужики-то и не знали, что шаг измерения и предсказания ничего не стоит

Вот опять тот же вопрос: какой шаг? Микросекунда? Наносекунда? Там часто всё упирается в скорость датчика и исполнительного устройства.

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

Перефразируя, «если тебе не нужен фильтр Калмана, то тебе не нужен фильтр Калмана». Спасибо, капитан очевидность

Мне кажется, что не не в курсе, зачем нужен фильтр Калмана. Я писал эту фразу именно для случая, что кто-то попытается натянуть сову на глобус. Фильтр Калмана — это метод решения проблемы отсутствия доступа к будущим значениям. Если доступ к будущим значениям есть, то ты решаешь проблему. которой у тебя нет.

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

Зачем ты показываешь свое ярое невежество? При чем здесь гигагерцы, механические, видео-, аудиосигналы, которые якобы кончаются на сотнях килогерц? Зачем все это? Тебе четко на пальцах я объяснил, что фильтр Калмана является рекурсивным фильтром, текущее значение которого определяется текущим отчетом и состоянием фильтра на предыдущей итерации. Пока ты не рассчитаешь состояние фильтра на шаге i, ты никогда не сможешь определить состояние этого же фильтра на шаге i+1. Все остальные твои слова это просто шелуха.

Ты снова придумываешь абстрактную задачу, которая не имеет отношения к реальности, но теоретически не параллелится, а значит доказывает твою позицию. Правда, не опровергает мою.

Фильтр Калмана используется очень широко на практике. Окстись.

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

Insertion sort имеет примерно такую же кеш-локальность и является значительно более быстрым алгоритмом. Insertion sort практически, то есть, на практике, уничтожает пузырек полностью

Да, ты правильно заметил. Почему-то чел, который делал бенчи, назвал сортировку вставками сортировкой пузырьком.

Сейчас, вон, интель сует в каждый процессор видеокарту — и типа как его тогда судить по твоей классификации?

как и раньше это процессор общего назначения

Сами поточные мультипроцессоры a.k.a. шейдеры — вполне себе общего назначения

запусти на них ОС общего назначения чтобы производительность была сравнимой с интелами тогда и говори что-то про лбщее назначение.

И вот на этом фоне FPGA смотрися вполне себе неплохо

херня это. Нет FPGA в пека/мобильниках и не будет - будут и есть CPU,GPU,VPU, NPU и так далее. FPGA хороши в теории, на практике они целесообразны только для очень узкого круга задач, когда свой ASIC дорого а готового на рынке нет - несерийное производство и всякая стартапщина.

Как ты оценишь производительность и эффективость ядер arm и х86, если любая/каждая ОС писалась именно под х86 архитектуру. И ПО соответвенно. ARM через костыли в этих ОС и соответсвенно ПО

И что, по-твоему линь за все это время не заточили под ARM? Не считая того, что какой-то числодробилке глубоко безразлична ОС-ь, поскольку работает она в основном только с самим процессором.

Там часто всё упирается в скорость датчика и исполнительного устройства.

А иногда не упирается. В общем случае у тебя функция, значение которой получается нетривиальным способом (нейросети и прочий матан).

При чем здесь гигагерцы, механические, видео-, аудиосигналы, которые якобы кончаются на сотнях килогерц? Зачем все это?... Пока ты не рассчитаешь состояние фильтра на шаге i, ты никогда не сможешь определить состояние этого же фильтра на шаге i+1.

Не могу. Зачем мне это делать? Я тебя пытаюсь вернуть в реальный мир, а ты мне снова абстрактных сферических коней в вакууме суешь, что вот, мол, если понадобится... но не понадобится, никогда и никому, кроме тебя. Совсем не обязательно считать до восьмого знака после запятой точное значение именно с предыдущего шага, потому что фильтра Калмана работает с шумом, со случайностью, а случайность — она... случайная. Она просто прыгает туда-сюда мимо твоего восьмого знака. Хочешь бери прошлое состояние, хочешь примерно подсчитывай вероятное прошлое состояние — для практического применения подходят оба варианта.

Фильтр Калмана используется очень широко на практике

... но не тобой. а написание курсовых или диссертаций не является практическим применением.

В общем случае у тебя функция, значение которой получается нетривиальным способом (нейросети и прочий матан)

В каком еще общем случае? Какая функция? Я напоминаю, что это был мой исходный тезис.

Фильтр Калмана — это метод решения проблемы отсутствия доступа к будущим значениям.

Не только. Еще есть задачи, в которых нет прошлых данных, и их надо оценить на основе текущих данных.

У линя костыли в ядре для ARM. Ты будешь замерять производительность костылей для этой архитектуры.

Еще есть задачи, в которых нет прошлых данных, и их надо оценить на основе текущих данных

Я не спорю, я понял эту твою идею, и, в общем-то, я пишу о том же. Я не знаю, чем тебе до сих пор не нравится ответ про «ускорять там нечего».

Задачи из реального мира решались даже компьютерами из 90-х годов. Вопрос лишь в том, сколько люди готовы заплатить за такое решение. Готов ли ты отдать несколько миллионов долларов за систему видеонаблюдения с компьютерным распознаванием людишек? Все основные исследования по машинному обучению родом из 80-х годов. Проблема реализации упиралась только в огромные размеры компьютера из тысяч процессоров и десятки киловатт киловатт потребления энергии. Сейчас десктопы школьников имеют ту же производительность, а видеокарта может считать в десятки раз быстрее десктопного процессора. В итоге пара дорогостоящих видеокарт приоизводит вычисления как целой здание компов на x86. У нас, вон, пропали этажи с телефонными станциями, потому что пару ящиков заменили целый этаж.

У линя костыли в ядре для ARM. Ты будешь замерять производительность костылей для этой архитектуры

Я читал армовые сорцы линя, я не нашел там каких-то проблем.

Проблема в том,что архитектура ядра Линукс изначально ориентировалась под х86, и затачивалась в прследующем. Кроссплатформенность/ поддержку других архитектур приделывали с помощью костылей.

Чтоб использовать все преимущества платформы (любой), нужно писать ОС/ ядро ОС, с учетом особенностей даннной архитектуры, стараясь нивелировать слабые стороны данной архитектуры.

Проблема в том,что архитектура ядра Линукс изначально ориентировалась под х86

психиатру расскажи о своей проблеме

Проблема в том,что архитектура ядра Линукс изначально ориентировалась под х86, и затачивалась в прследующем. Кроссплатформенность/ поддержку других архитектур приделывали с помощью костылей

Это было актуально в нулевых. С 3.7 в линуксе есть штатная общая поддержка ARM-ов, на базе которой ядро допиливается под любой конкретный проц. Отсюда астрономическое число ARM устройств на лине в мире.

С 3.7 в линуксе есть штатная общая поддержка ARM-ов

она есть с незапамятных времен

ядро допиливается под любой конкретный проц

скорей всего ты имеешь ввиду портирование device tree для ARM, на производительность системы это никак не влияет, это способ описать аппаратные ресурсы присутствующие в конкретном процессоре

скорей всего ты имеешь ввиду портирование device tree для ARM, на производительность системы это никак не влияет, это способ описать аппаратные ресурсы присутствующие в конкретном процессоре

Да. Я не знаю даже, что там у чела может влиять на производительность, на самом деле, он лишь делает упор на «линукс не приспособлен к ARM», на что я отвечаю, что в линуксе есть всё для поддержки утюгов с ARM. Причем, сделать это было весьма сложно, учитывая то, какой бардак происходит там как с периферией, так и с набором инструкций — ядро по системному вызову должно определять, находится ли оно в режиме Thumb или фиксированной длины слова.

Что мешает перегрузить *?

А сиська - это просто сахар для асма, да?

Скажите, а в плюсах уже можно делать .map .filter и .reduce на коллекцию?

Скажите, а в плюсах уже можно делать .map .filter и .reduce на коллекцию?

Можно было делать с С++98

map = transform (c++98)

filter = copy_if (c++11)

reduce = accumulate (c++98)

Короче я понял, люди не могут осилить с++ и из-за этого бесятся. Смотрите, начните с си. В си есть по сути всего три вещи: функция, структура и указатель. Изи, но разберитесь получше. Затем берите с++98, это будет нормальным для начала, затем прыгайте по крупным ревизиям: с++11, с++20. Между ними все равно ничего хорошего нет, заберете, про с++03 сейчас уже все равно никто не вспомнит.

В интернете есть документы типа «разница между с++11 и с++14», чтобы вслепую не тыкаться, там нет ничего страшного. С++ очень логичный язык и он пишется на самом себе. Например ренжи из с++20 реализуются на с++14, а корутины реализуются переписыванием кода компилятором. Т.е. это такие макросы типа хахаха, только встроенные.

Если вы знаете с++98 или с++11, то в с++20 не будет чего-то особенно незнакомого. Иногда бывают действительно новые вещи, лямбды например, но лямбды есть везде, если вы знаете лямбды из другого языка, то и в с++ осилите. Модули - это больше бюрократия. А так все в с++20 реализовано на тех же концепциях которые были в с++98, это все просто причесали и убрали костыли.

Ничего не бойтесь, все получится.

Ничего не бойтесь, все получится.

Хорошо. Я уже не боюсь. No pasaran.

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

а пре-с++98 вообще написан на си, классы - это структуры с сахарком, методы - это ещё сахар для указателей на функции, конструкторы и деструкторы - это методы которые вызываются автоматически. ещё есть шаблоны. и понеслась.

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

Хорошо. Я уже не боюсь. No pasaran.

Вот инструкция как выучить С++ за ∞ дней: https://youtu.be/zUQz4LBBz7M

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

Книги норм. И видео норм, много чего рассказывают чего в книгах нет. И в видео обычно ссылка на годболт.

Вот сейчас проходит cppcon 2020: https://cppcon.org/program2020/

Плохо что ролики в свободном доступе будут через месяц-два, но презентации можно будет почитать через неделю наверное…

Кстати, вот тебе табличка которая поможет в составлении биекции между алгоритмами на популярных языках и С++: https://github.com/codereport/Talks/blob/master/2019-11-MeetingC%2B%2B/Consistently%20Inconsistent.pdf

При чем здесь гигагерцы, механические, видео-, аудиосигналы, которые якобы кончаются на сотнях килогерц? Зачем все это?... Пока ты не рассчитаешь состояние фильтра на шаге i, ты никогда не сможешь определить состояние этого же фильтра на шаге i+1.

Не могу.

Ну что и требовалось доказать. Если у тебя во входном буфере системы n отсчетов из разных источников (а эти отсчеты зависимые, поскольку относятся к одной системе), то ты не можешь запустить их обработку сразу на n ядрах. Ты их будешь обрабатывать на одном ядре последовательно.

Зачем мне это делать?

См. выше

Я тебя пытаюсь вернуть в реальный мир, а ты мне снова абстрактных сферических коней в вакууме суешь, что вот, мол, если понадобится... но не понадобится, никогда и никому, кроме тебя. Совсем не обязательно считать до восьмого знака после запятой точное значение именно с предыдущего шага, потому что фильтра Калмана работает с шумом, со случайностью, а случайность — она... случайная. Она просто прыгает туда-сюда мимо твоего восьмого знака. Хочешь бери прошлое состояние, хочешь примерно подсчитывай вероятное прошлое состояние — для практического применения подходят оба варианта.

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

Фильтр Калмана используется очень широко на практике

... но не тобой. а написание курсовых или диссертаций не является практическим применением.

За неимением аргументов неудачники переходят на личности. Это тоже проходили не раз. По существу-то сказать нечего, так что слив засчитан.

Потому что операция `*` уже занята, насколько я понимаю.

о тут опечатка в коде, то там в тексте ляп.

Оч. знакомая ситуация. Иногда бывает что это очепятка, а иногда понимаешь, что это банальная небрежность. Недавно вот один документ открыл, а там нумерация формул с пропусками и конечно есть ссылки на формулу, которая среди пропущенных.