Comments 88
Круто, намного интереснее читать чем обзор очередного фреймворка для создания формочек.
Я работаю над WebRTC — фреймворком для аудио-видео конференций (или звонков? проще говоря — real time communication).
Создается впечатление, что фреймворк над которым вы работаете называется WebRTC. Но ведь это же API. Может, чтобы избежать путаницы, назвать как-то по другому?
Нет, это еще и фреймворк. Вы его не только в браузере можете использовать но и встроить в ваше приложение. На нем работают аудио/видео звонки в многих мессенджерах, например. А API назвается PeerConnection.
Если второе, то коллега, по-видимому, имел в виду, что вместо тире в данном случае нужно использовать дефис: «Я работаю надо WebRTC-фреймворком» (т.е. над отдельным фреймворком, использующем WebRTC), а не «Я работаю над WebRTC <. WebRTC это >— фреймворком для аудио-видео конференций».
Простите, вы член IETF, и то, что вы разрабатываете, станет частью стандарта?
Лично я — нет, но коллеги по команде — да.
Про второе: тут путаница из-за того что web api называется "webrtc" и фреймворк называется точно также. Исторически был сначала этот проект, потом гугл стал его встраивать в браузеры и стандартизовывать к нему АПИ.
а не «Я работаю над WebRTC <. WebRTC это >— фреймворком
Хабр съел часть комментария, я так подозреваю?
Лучше рывки при переключении и чёрные полоски вокруг, чем незначительное искажение соотношения сторон. Нужно принять закон о защите соотношения сторон.
Выглядит как типичная задача ТАУ.
причем решенная неверно
В большей части современных игр просто делают настройки графики и стараются не делать сфер на миллион треугольников. На этом все старания и заканчиваются.
Я правильно вас понял, что пока игру делают, никто не бегает по локациям и не смотрит где тормозит?
но у тех, кто бегает — тестовые настройки (а то и вообще — однотонные текстуры), потому бегать уже надо а красивости еще не завезли,
у тех у кого должны быть все текстуры и модельки — те их усиленно пилят, чтобы успеть к релизу,
а ЛПР (лица, принимающие решения) — бегать некогда, они максимум смотрят на рендеры: «красиво» или «некрасиво»…
(семь нянек, классика )
Если максимально упрощенно, то ваше решение более-менее правильное. Как минимум не будет шататься туда-сюда, но (скорее всего) будут проблемы со скоростью адаптации и/или оптимальности подбора условного качества.
Если не упрощенно то см "Критерии устойчивости" в wiki-статье (на всякий — там могут быть ошибки, сам не вычитывал).
Хм, может какой-нибудь ПИД-регулятор?
И оттуда же можно позаимствовать рецепт для избавления от мельтешения: гистерезис.
Ну давайте в логику: Обратное утверждение "Математика не нужна программистам" опровергается тем, что я программист и мне нужна математика. А если серьезно, то заголовки должны быть громкими.
Вот почему математика является предметной областью веб API (приведенная задача происходит задолго до, собственно, сжатия видео и к кодекам имеет весьма отдаленное отношение)? Из-за того, что речь идет о разрешении картинок?
Далее… Задача требует преимущественно математического решения, а значит, если бы мы говорили об идеальном мире и идеальной компании, в которой вы работаете, экспертизу в математике предоставил бы отдельный человек
Вот я программист, мне пришло задание — сделать так чтобы, когда в апи подаются всякие числа, у пользователя видео не дергалось при скачке сетевой скорости а энкодер не падал из-за нечетности разрешения. Тут нет никакой математики. По задаче не видно, что она математическая, никаких терминов из предметной области заумных тут нет. На первый взгляд это задание выглядит также, как "сделать так, чтобы у пользователя кнопка при проматывании страницы не дергалась".
Но без математики я бы тупо обрезал по одному пикселю у сжатого в заданное количество раз кадра (чтобы энкодер не падал) и сказал, что без дерганья никак. Ну, потому, что фиг его знает, как вообще к заданию подступиться.
И если, допустим, весь ваш проект или существенная его часть постоянно сопряжены с математикой, как в приведенной задаче, то это, очевидно, задача работодателя нанимать разработчиков,
Ну, вот проект — поддержка некоторого апи для аудио-видео конференций. При чем я видео кодеками самими не занимаюсь (для этого есть отдельная команда). Грубо говоря, моя работа — брать данные от клиента, переводить их в конфиги к библиотеке с энкодерами и скармливать туда видео фреймы.
Вот вам очевидно, что для этого проекта нужно нанимать специальных математиков? И если еще можно как-то предположить, что раз там ключевое слово "видео" рядом, то всякая обработка сигналов, преобразования Фурье там, свертки, вот это вот все, могли бы пригодится, то каким боком тут теория чисел вылезла?
Это уже когда задача возникла и найдено решение, можно утверждать, что да — в этом проекте математика нужна.
Подчеркну еще раз — у проекта нет какой-то особой "математичности". Математика вылезает в неожиданных местах.
Но это далеко не «математика нужна программистам».
Давайте договоримся, что в заголовке пропущено слово "некоторым" ради авторского стиля и акцента на основной идее?
«Математика нужна программистам, решающим задачу выбора разрешений в WebRTC»
Это тоже слишком громкий и категоричный заголовок. Правильнее было бы «Математика нужна некоторым программистам, решающим задачу выбора разрешений в WebRTC, некоторым программистам, решающим другие задачи, некоторым людям, не являющимися программистами, и некоторым существам, отличным от людей»
В общем и целом прогир из математики должен знать только одно. Всё что есть — это множество. И есть ещё функция отображения множества в другое множество. На этом математика для прогира и оканчивается.
А вот функцию отображения должен предоставить математик. И это вовсе не прихоть. Математик иногда прям таки на несколько «порядков» круче может заваять эту функцию отображения.
Джентельмены, чюдес не бывает. Либо вы годный прогир, либо математик. Быть годным враз пока ни у кого не получалось. Хирург должен резать, продавец продавать, прогир прогать, математик — матемачить.
П.С.: уважаемые прогиры, то что вы там пытаетесь из себя математически извергнуть — это детский лепет для математика, и падавляюще часто — для математика же громкий смех, по причине того, что это всё — древние математические бояны, давным давно придуманные, давным давно успешно устаревшие и никому уже не нужные. И то что на вас навешивают некие проблемы, где вы никак не являетесь профессионалами своего дела — ну это уже ваши проблемы, господа. :)) Если вы на это ведётесь, то сами и виноваты, уж извините…
У вас в команде есть выделенный математик? Вот пришла программисту задача — сделать так, чтобы всем энкодерам приходили кадры с четным разрешением и пользователям "было хорошо". Как понять, что эту задачу надо сначала дать математику?
А собственно почему так категорически нельзя быть годным «прогиром» и математиком одновременно?Почему категорически нельзя? Можно. Однако же вероятность этого весьма мала. Если вы стремитесь к малым вероятностям, то вы как минимум «фантазёр». :) И да, т.к. вероятности сего малы, то ни вы ни кто бы то ни было из ближнего и среднего окружения «прогирами и математиками» враз не являются.
Идём далее, предположим что вам повезло, и вы или кто-то из вашего окружения «попал» в эту маленькую вероятность и стал таки математическим программистом. Так и это невозможно. Математик — это прежде всего учёный. Публикующийся. Вот скажите мне, у вас будет время прогать и писать статьи одновременно? А если вы не пишите статьи, то какой же вы к чорту математик? :)
Понимание предметной области — это ничто. Много кто из нас понимает всякое, но быть действительно специалистом сразу многих областях — ни у кого не получается. Чюдес не бывает. И в таком случае вместо мат.прогира вы получите что-то одно и только одно. Либо действительно получите мат.прогира, но сильно остановившегося в развитии.
И да, у меня есть математики. И их много. И я ищу ещё. Это же просто. Идите по универам и скупайте их за еду. Они будут рады. Вы даже не представляете сколько людей действительно занимаются математикой, но не знают где себя применить, хотя бы как-то…
И не ждите чюдес. Математик — это другой взгляд на вашу деятельность, не более. Однако же иногда этот взгляд со стороны действительно приводит к колоссальным решениям.
По поводу фреймворка — ну тут всё очевидно. Расколупайте фреймворк, найдите низкоуровневую часть. В высокоуровневой части прогиры разберутся, это абстракции. А в низкоуровневой не разберутся никогда, это же математика. :) Итого. Распотрошите фреймворк, поймите как он работает, найдите низкоуровневую часть, поймите через математика как она работает, и вставьте нужные вам две строчки. Да да, чюдес не бывает. Всё остальное — это палнейшая фигня, что бы вы не предлагали.
Если вы делаете иначе [а вы делаете иначе] — то это же костыль. Который однозначно снижает производительность. Либо нарушает логику работы фреймворка. Либо что-то ещё. Либо всё враз. :)) И не стоит употреблять фраз типа «а вот мне сказали сделать, или заказали» и хоть убейся но оно должно работать так как заказали. Послушайте, вы не являетесь средством от всех болезней, и не стоит поддаваться чьим то прихотям. И многое вы не можете. А в таком случае не решайте эту задачу. Это не ваша задача. Не стоит уподобляться животному, и искать путей решения чего бы это не стоило.
Математик — это прежде всего учёный.Есть ученые-математики, есть прикладные математики, больше инженера чем ученые. Очевидно, что разработка математической модели — это прикладная задача, которая требует инженерного подхода, а не научное исследование. Поэтому довольно странно думать, что с ней лучше справится человек, у которого есть научные публикации.
На научные публикации рецензентов пол-планеты. Весьма странно думать, что очередной какой нибудь sha лучше сделает математик-инженер [новый термин изобретённый на хабре, крайне редко встречающийся], чем действительно публикующийся профильный математик, которого контр-статьями абстучали тысячи таких же со всего мира.
А я бы по-другому задачу решал. Я бы задал crop area по краям картинки, в которых могут быть пикселы, а могут и не быть (они не выводятся при выводе изображения). Входящий кадр от камеры подрезается по требованиям кодеков, при декодировании ещё раз подрезается (чтобы показать область, которую сумеют все кодеки).
А как сделать так, чтобы эта область, которую видят все кодеки, была одна и та же?
Ведь, если коэффициенты сжатия неудачные, то эта область будет с дробным количеством пикселей. И при округлении вверх или вниз будут те самые заметные рывки.
На входе у нас разрешение 667x401, допустим.
Набор требований:
codec1: кратно 2
codec2: кратно 4
codec3: соотношение сторон — целое число.
codec1, codec2 => x:667->664, y: 401->400.
codec3 => y: 400->332 (альтернативно: x: 400, y:400).
Итого, наш кроп вырезает из картинки 667x401 картинку 664x332.
Считаем границы кропа: x: [2-666] y:[34;366]
Дальше мы либо уже это готовое изображение всем кодекам отдаём, либо отдаём каждому кодеку его картинку (минимальное изменение), а crop делаем на получателе.
Итог — каждый кодек получает картинку, которую хочет, а картинка у получателя привязана к оригинальному пикселу и не двигается. Примерно такой алгоритм используют стабилизаторы видео — какие-то точки не двигаются, хотя границы картинки могут дёргаться.
codec3: соотношение сторон — целое число.
Это странное требование, которое я нигде не упоминал. Если codec3 кодирует полное изображение, то можно просить просто, чтобы разрешение было целым (т.е. нет никаких ограничений). Судя по вашему примеру, codec1 кодирует уполовиненное разрешение, а codec2 — четверть.
Ваш кроп по сути и есть то самое "запросить у источника разрешение делящееся на 4". Тогда codec1 делит разрешение в 2 раза, codec2 в 4 раза, codec3 — просто кодирует.
Проблемы встают во весь рост, если соотношение размеров кадров у разных кодеков не такое тривиальное. Например, уже указанные в примере {1, 1.7, 2.3}.
т.е. посчитать рамку выходного изображения, а на кодеки «посредине» либо ничего не делать (если соотношение уже замечательное) либо добавлять пикселов с той стороны, где это надо?
UPD: заодно и копирование кадров упрощается — можно заранее буфер выделить, закрасить только фон и рендерить из одного в другой в одну и ту же область памяти (там только пул таких кадров нужно сделать, но я думаю это у вас уже есть).
С паддингом кадров та же проблема — до какого размера паддить, что бы после сжатия в 1, 1.7 и 2.3 раз пиксели не съезжали относительно друг друга? Потом, а каким цветом дополнять? В браузерах фон белый, у мобильных клиентов видео занимает весь экран и лучше черный фон. А еще паддить дороже, чем обрезать: Надо обязательно копировать куда-то кадр, когда как обрезание — это сдвиг каких-то указателей и изменение переменной — размера.
Вы говорите, что можно копировать кадр в выделенную область памяти, а что если кадр в GPU буффере? Тогда надо реализовывать этот паддинг в куче разных вариантах и все-равно лишнее копирование будет.
Дополнять пикселы — это только для работы кодека, во время показа — рендерить так, чтобы этой «добавки» не было видно (из самого-рассамого простейшего — сделать размер видимой части контрола-контейнера равной видимой части изображения).
Копировать нужно только то, что является изображением в принципе многие кодеки умеют рендерить кадр где кроме
1) начала буфера кадра FRAME_START и
2и3) строк ROWS_N со столбцами COLS_N,
4) есть еще длина строки ROW_LENGTH (или ROW_PADDING так что ROW_LENGTH = COLS_N + ROW_PADDING, либо указание на выравнивания степени 2 — «до ближайшего числа сверху делящегося на 4 или 8» ит.д.)
5) и длина буфера кадра FRAME_LENGTH (которая кстати может как и добавлять пустые строки, так и «обрезать» паддинг последней строки.
У меня был однажды случай что я копировал кадр как массив байт COLS_N*ROWS_LENGTH — т.е. без учета FRAME_LENGTH, а драйвер камеры выделял последовательный участок памяти под буферы для 20 кадров — так что такое копирование первых 19 кадров работало нормально, а 20го — выдавало segfault из-за выхода за границы памяти :DDD ).
Есть конечно еще разные старинные места, где 4 и 5 нет, но их можно добавить гораздо меньшей кровью чем обработка изображений.
Смысл этого паддинга не в том, чтобы что-то копировать, а наоборот — чтобы из одного кодека можно было взять например в буфер в памяти кадр 432 на 432 пиксел (пусть это будет RGBA) с паддингом 192 байта, а в другой кодек из этого же буфера передать кадр 480 х 480 пиксел с паддингом 0 байт.
Что вы хотите. Сейчас полно программистов, которые ничего не слышали даже о теории алгоритмов. И ни на что кроме формошлепства они негодны.
Например, для стандартных коэффициентов {1.0, 2.0, 4.0}
Но что делать, если заданы коэффициенты {1, 1.7, 2.3}?
Не очень понятно зачем вообще их вообще как-то нужно менять. Есть стандартные коэффициенты в выбранной библиотеке и кодеке, по этим коэффициентам получается резать видео лучше всего, наиболее эффективно, с меньшей затратой ресурсов, на аппаратном уровне даже. А клиенты уже выбирают наиболее подходящий им поток, который задается именно стримером потока.
Что-то упускаю?
Ну, может в вашем приложении вы видите говорящего человека на весь экран, а сбоку присобачены аватарки остальных участников, которые в 10 раз меньше — тогда вам могут понадобиться коэффициенты {1, 10}. А еще, вдруг у вас смартфон, который снимает в 320x240 и посылает по 3g. Делить его в 2 и в 4 раза слишком пиксельно. Кроме того, некоторые аппаратные кодеки тупо не поддерживают такое низкое разрешение. Поэтому вам могут понадобится коэффициенты {1, 1.5}.
Раз какая-то гибкость в API нужна, то есть и коэффициенты. Никаких причин прибить стандартные {1, 2, 4} гвоздями к документации нет. А дальше уже, черт его знает, что кому в голову взбредет.
Но ведь никто не говорит, что математика не нужна в драйверах и кодеках.
Эта задача вообще не о кодеках. Она о масштабировании изображений. И до драйверов тут как до луны. Этот код из недр реализации API — тупо переводит пользовательские данные в формат, понятный следующему уровню абстракции.
Клиенты могут настроить WebRTC кодировать входящий поток сразу в нескольких разрешениях. Например, это может быть полезно в видео конференциях: каждый клиент посылает на сервер несколько потоков с разным разрешением и битрейтом, а сервер пересылает всем остальным только тот поток, который помещается в пропускную способность до клиента.
Толстые клиенты (особенно записывающий) и тонкий сервер?
Это же ошибка в архитектуре системы.
Обычно пишущий посылает наилучшее возможное качество на сервер, сервер преобразует во что надо, в т.ч одним нужно mpeg, вторые могут показать VP9, третьи и AV1 тянут. И сервер можно убыстрить аппаратными ускорителями хоть на ПЛИС.
В вашем случае
1. Пишущий клиент будет неэффективно использовать ПСП, передавая много копий некачественного потока.
2. Снижается показатель использования установленной мощности.
Когда-то давно так и делали. И пользоваться системами конференц-связи было невозможно. Были дикие задержки. Когда кто-то представил систему с симулкастом — это была революция.
Перекодировать на лету не так просто:
1) Что делать, если у вас сотни тысяч активных клиентов? Сколько и каких серверов вам надо для декодирования сотен тысяч HD потоков? Это очень дорого, даже с ПЛИС, даже новейшими технологиями. Мне неизвестен ни один большой сервис видео конференций, который бы так делал.
2) Перекодирование увеличивает задержку. Особенно этим страдают аппаратные ускорители декодирования. У них большая пропускная способность, но задержки ужасны.
Симулкаст — не идеальное решение, но альтернативы тоже не без недостатков.
Не супер идея для групповой видеосвязи. Для каждого из N участников серверу придётся готовить N-1 потоков, в худшем случае в разных разрешениях и форматах. Горячо. А клиентское железо, в т.ч. такое, которое умеет аппаратно кодировать, будет простаивать.
Мне видится более рациональным идея снимать и гнать на сервер действительно максимально качественный поток, другим участникам раздавать его же — а ресайзить уже на получателе. Хоть в шестиугольное окно.
С третьей стороны, так получателя не переключить на более низкое качество в случае просадки сети, тоже не супер.
Мне видится более рациональным идея снимать и гнать на сервер действительно максимально качественный поток, другим участникам раздавать его же — а ресайзить уже на получателе. Хоть в шестиугольное окно.
Тут главная проблема не формат и разрешение, а битрейт потока. У клиентов разные входящие пропускные способности. И этот HD поток просто физически может не влезть.
А если посылать такой поток, который подходит всем, то из-за одного пользователя на мобильном интернете будут страдать все участники конференции.
Потом, тут еще другие спецэффекты вылезают — практически никогда клиент не сможет получать много HD потоков из-за пропускной способности. Поэтому HD поток — только один, а все остальные в маленьких окнах и передаются в меньшем разрешении и с меньшим битрейтом.
я уже показывал habr.com/ru/post/436966/#comment_19641126 свою поделку.
пришлось вспоминать курс тригонометрии, и прочих сопутствующих наук из школы.
ещё раньше пришлось поднимать знания уже из института, когда потребовалось управлять ТЭНами использую ПИД-алгоритм… интегралы, дифференциалы…
Одного потока с самым высоким качеством будет недостаточно?
Читайте дальше:
а сервер пересылает всем остальным только тот поток, который помещается в пропускную способность до клиента.
Иначе, что делать, когда у вас в конференции 3 человека с 10мб/c соединениями и один несчастный с 300кб/c? Все смотрят на большие красивые пиксели в 300кб/с? Потом, а если у вас в конференции 11 человек — каждый будет получать 10 HD потоков? Это слишком жирно, что для сети, что для процессора получающего.
Варианты с перекодированием на сервере обсуждаются в этой ветке, если интересно.
Я уже 20 лет в embedded разработке. Занимался и мелкими микроконтроллерами и системами с Linux внутри. Успел поработать и с мультимедиа и с электромобилями и датацентрами. Математика выше школьной никогда не нужна была. Собственно так же как и алгоритмы сложнее сортировок. Но у меня на интервью это все ниразу и не спрашивали.
A/(S_i' d) \in N
к выражению
S_i' = A / (N d) > 1
нет никакой математики…
В практических задачах — вот если понадобится мне последовательность простых чисел (например, для хэш-таблицы) — я просто нагуглю её, отфильтрую нужные числа и положу в табличку. Пусть там будет целых 10, или даже 1000 чисел! Оно будет компактно и просто работать. Хотя да, можно было бы написать мини-тулзу, которая всё посчитает (наверное, банальным сделанным на коленке решетом Эратосфена по битовой маске). Основная мысль простая — будучи однажды посчитанным, там больше ничего не поменяется. Так зачем тратить на это рантайм?
И такое встречается достаточно часто. Начинаешь мудрить с математикой для неких абстрактных X и Y, выводишь формулы, кодишь алгоритм… А на практике оказывается что реальных значений того и другого, всего, скажем, по 10 вариантов. И внезапно получается, что вместо математики с формулами достаточно закодить табличку 10х10 + элементарный аксессор к ней. И это зачастую мало того, что реально занимает меньше места (сколько байт программного кода нагенерит компилятор по сравнению с местом, занимаемым готовой табличкой), так и ещё и работает быстрее (если табличка легко влезает в кэш), и код из двух строчек гораздо понятнее, чем какие-то формулы.
Остаётся только референсный "математический" код положить рядом в комментарии (на случай, если табличку надо будет поменять/дополнить) и… собственно всё!
Код все же лучше таблички. Но бывает, когда это "Гуд энаф" чтобы решить поставленную задачу.
Да вот не всегда. Обычно исходит из конкретных целей.
Например, escape для json.
Если хочется краткости — strchr по строчке из спец. символов. Этакий хакерский "однострочник". Но — читаемость — нулевая; скорость тоже так себе.
Если нужно для наглядности — switch на пять спец. символов + дефолтный кейс. Всё стройно, прямо, понятно. Воспринимается одним взглядом, скорость тоже стабильна.
Если нужно для скорости — lookup-table на 128 символов. Выглядит не так наглядно (поэтому перед табличкой можно комментарием вариант со свичем приложить), зато время работы за счёт умещения всей таблички в кэш-линии становится практически неизмеримым.
И вот дальше уже цели. Если мне нужно прочитать/записать конфиг в жсоне однажды при старте/завершении сервиса — свитч. А если сам сервис гоняет туда-сюда жсоны гигабитными потоками — табличка. А если надо демку, типа полноценный сервис, исходники которого помещаются на бумажке размером с кредитку — strchr.
С примером жсона — я просто возьму либу санитайзер, на крайняк сниппет из интернета, и вставлю его прям со ссылкой на то откуда я его взял. Так что от задачи сильно зависит. Такие типовые вещи решаются элементарно, или библиотекой или просто гуглом. Задача как у автора — уже сложнее, и либы может не оказаться. Тогда подобные рассуждения очень полезны.
При этом такой метод спокойно можно использовать как "черный ящик". Не нужно быть математиком чтобы вызвать такую функцию, а менять её вряд ли будет необходимость. В отличие от таблички.
Много раз встречал восьмибитные системы с расчетами плавающей запятой без float, только спец таблицы, например перевод в двоичный вид и сдвиг влево до ухода запятой, после сокращения по простой и неочевидной математике. Если программист умеет в матан, то он молодец, но за мою жизнь было очень мало проектов, где он требуется, ну либо (как выше написали) пишешь сетевую функцию на табличных данных и отдаешь на аутсорс математику на вывод формулы.
Да и основной кодек 264 имеет свои ограничения, плюс если брать мобилку, то часто есть 4 хардварных потока на декодинг и 1 поток на кодинг видео, остальное будет нагружать процессор. Да и джиттеры и задержки в 2-5 секунд никто не отменял при любом подходе. Пока только одноклассники описывали как переписать TCP стек (или сделать эмуляцию), чтобы решить вопрос с размером фрейма TCP и слипанием пакетов. Но автор с этим не столкнется, так как генерит довольно большой поток данных.
Ну это уже странные люди пишут странные аглоритмы.
Мои знакомые которые пишут пишут исключительно переносимый код. size_t/int32_t, и прочие бест практисы которые способствуют возможности бездумного переписывания на любую мыслимую платформу.
Знаете, откуда взялся метод наименьших квадратов и какие задачи он решает?
А он позволяет отделить полезный сигнал или систематический результат измерений от помех или ошибок измерений. НО…
1. Отклонения в сигнале или измерениях должны быть именно случайными ошибками/помехами.
2. Они должны быть вызваны большим числом неучтенных факторов и иметь, вследствие этого, нормальный закон распределения.
Т.е. решают такую задачу: Подбирают такие параметры процесса, при котором отклонения имеют нормальный закон распределения. После чего говорят: «Смотрите! Отклонения распределены нормально. Следовательно, они — случайные ошибки измерений или случайные помехи. А параметры описывают реальный, лишенный ошибок процесс!»
В данном же случае отклонение соотношений сторон (AR — Aspect Ratio) от заданного не является ни ошибкой, ни случайной величиной, имеющей нормальный закон распределения. Поэтому, заставлять их вести себя так — это сову не на глобус даже, а на сферического коня в вакууме натягивать. И метод наименьших квадратов здесь совершенно неоправдан.
А раз так, так следует искать другие критерии оптимизации. Например, минимизация максимального отклонения AR. Или минимизация суммы абсолютных значений их отклонений.
Но это не метод наименьших квадратов. Это минимизация метрики L2. Можно спорить, какая метрика лучше — L2 или L_infinity. Квадраты лучше минимизации суммы абсолютных значений тем, что чувствительнее к отдельным большим значениям. Брать просто максимум всех значений тоже можно, но тогда невозможно отличить 2 решения, где максимум одинаковый, но в одном больше нулей.
Но это не метод наименьших квадратов.
Значит, я не так понял это:
При условии:
\sum_{i=1}^n\left(S_i -S'_i\right)^2 \rightarrow min
Прошу прощения — в комментах TeX не работает.
Брать просто максимум всех значений тоже можно, но тогда невозможно отличить 2 решения, где максимум одинаковый, но в одном больше нулей.
А такое возможно? Тогда исключаем найденный минимизированный максимум и повторяем оптимизацию для оставшегося набора.
Ранее написал 3 статьи на близкую тему: Зачем студентам теория графов и Графы большие и маленькие: интеллектуальное решение проблемы выбора представления и Сложно ли сделать из мухи слона?.
Математика нужна программистам, или задача, которую мне пришлось решать