Комментарии 14
>> компилятор героически взялся за выполнение данной операции
Компилятор грустит, когда компилятором называют что попало...
Именно компилятор python начинает выполнение данного процесса, понятно что под капотом за это берётся железо (CPU и RAM), но началось же всё с него)
Интерпретатор?
Да, ошибся. Спасибо ?
Скользкий момент. Сначала идёт компиляция в байткод, всегда. А уж потом он интерпретируется. Т е. ещё без машинного кода, но уже и без разбора текстовых языковых конструкций, в отличие от традиционных интерпретаторов (напр. bash).
Хм, дорисовка недостающих значений может быть не совсем точной
Попробуйте из исходных данных убрать некоторые промежуточные значения, и посчитайте их методом интерполяции. Интересно посмотреть на погрешности. И можно ли учитывать эти погрешности при более точном интерполировании
Если периодически (через 15 или 20 значентий) встречаются пропуски, а ты восстанавливаешь временные данные с помощью интерполяции, то больших погрешностей не будет. А если их гораздо больше, то конечно лучше в принципе базу адекватнее собрать ?
В каком плане адекватнее?
Возможно взятый целиком массив вычисляется точнее, чем по частям https://ru.wikipedia.org/wiki/Интерполяционный_многочлен_Лагранжа. Хоть и ценой пожирания памяти.
Я имел ввиду, что изначательно более качественный датасет даст больше достоверных данных без всяких ухищрений
И так же можно оптимально под максимум своей оперативки подобрать размер обрабатываемых кусков массива, что согласен даст большую точность
А дальше конечно наращивать вычислительные мощности нужно
Это зависит от изначальной функции, которой подчиняются данные, от того, есть ли там шумы.
Методов интерполяции много, поэтому вопрос "адекватнее" в некотором смысле философский. Если брать интерполяционный многочлен высокой степени, там будут ненаблюдаемые на реальных данных пики. Это нам на курсе выч. мата рассказывали. Поэтому отрезок бьют на части и берут полином низкой степени.
Причём нежелательные пики начинаются уже с кубической сплайновой интерполяции. В той же википедии (а лучше в статьях) можно прочесть про "монотонную эрмитову интерполяцию". Она убирает пики за счёт того, что вторая производная в местах сшивок.
Я недавно этим занимался - у клиентов был какой-то старый ни на что непохожий интерполяционный код на VBA (комментарии? git? - три ха-ха). И мы выясняли с коллегой, что же именно это за метод. Сошлись на том, что родственный Fritsch-Carlson/Fritsch-Butland.
Спасибо большое за информацию. Пороюсь в данны вопросах ?
Я как-то после рытья пришёл к выводу "а фиг его знает, что правильно". То есть, без чёткой модели данных совершенно непонятно, чем одна интерполяция лучше или хуже другой.
Вот этот несчастный пик/отскок в кубической интерполяции (представьте как будет выглядеть интерполяция sign) - он вроде неприятен, а ведь может быть и вполне разумен (в графике переходных процессов RC контура он есть!).
С монотонными методами (когда между точками данных не может быть пиков/впадин) совсем непонятно: там условие - это попадание параметров в некоторую четырёхугольную область.
Посмотрите, пожалуйста, может быть у вас статья будет, которая "откроет нам глаза" :-). С удовольствием посмотрел бы!
55 млн.значений и система встала колом ? Тогда как ты играх число треугольников в кадре и нет сопоставимое количество, и все они ещё трансформируются, отрисовываются и т.д. 60 раз в секунду и более
Разделяй и властвуй или как спасти оперативку