Комментарии 8
Сильно удивлён используемым видом уравнения регрессии для степенной функции (формула 12). Нет, вот какой смысл аппроксимировать функцию, которая имеет точку, подозрительно напоминающую (0, 1), используя аналитическую функцию, которая ни при каких обстоятельствах через эту точку не проходит? зато гарантированно проходящую через точку (0, 0), которой в показанной зависимости и не пахнет... Что мешает ввести постоянный член? можно даже принудительно - единицу, это уже должно значительно улучшить результат.
Что же до "гиперболической функции" (формула 21), то тут я вообще не понял, что в этой формуле было найдено гиперболического. Ну и опять же, пройти в районе точки (0, 1) функции показанного вида явно не светит.
Добрый день! Рассмотренная в статье зависимость (количество Интернет-пользователей от времени) – это всего лишь один из возможных примеров. Предложенный вариант решения носит универсальный характер, то есть подходит под любой пример. По этой причине рассматриваются все варианты аппроксимации, даже если они заведомо плохо описывают конкретный пример (есть вероятность, что другой пример опишет как раз та аппроксимация, которая не дала хорошего согласия в нашем случае). Вариант степенной регрессии записан в виде y=ax^b. Надо понимать, что мало записать функцию произвольного вида, следующим шагом необходимо решить уравнения методом МНК, а это накладывает существенные ограничения. Не каждая система уравнений может быть решена аналитически. Как раз это и мешало добавить дополнительное слагаемое - с в уравнение (добавить можно, но решить нельзя). Для улучшения аппроксимации можно переопределить систему координат, и об этом говорится в статье. График функции 21 - y=b/x – это гипербола.
К слову, вынужден напомнить.
Вы используете замену переменных. При этом получаете аппроксимацию по МНК для именно заменённых данных - но при этом, скорее всего, найденное значение вовсе не будет МНК-минимумом для исходных данных без замены. И чем "кривее" замена, тем больше "вес" отклонений на одной стороне по сравнению с другой, и тем больше разница между оптимумом, полученным с заменой, и полученным без неё.
Если вспомнить, что в PostgreSQL в качестве процедурного языка можно использовать R или Python, а параметры могут быть массивами, то можно воспользоваться уже готовыми пакетами этих языков, вместо изобретения велосипедов на SQL. Причем если простые аппроксимации закодировать на SQL хотя бы реально, то более сложные периодические модели - уже не очень. Да даже просто читать код вычислений на R или Python легче, чем на SQL.
Добрый день! Верно, задача аппроксимации может быть решена с использованием сторонних библиотек. R или Python как раз те языки, где есть библиотеки, предоставляющие такие решения. Если вас больше устраивает такой вариант, конечно, им можно пользоваться, тем более, что вам ближе R или Python, чем SQL. Но стоит остановиться на ряде недостатков такого подхода:
1) SQL-решение может быть (возможно, с небольшими доработками) перенесено практически на любой тип базы (Oracle, MS SQL, SAP и т.д.). Возможно ли его так же легко перенести со сторонними библиотеками? Скорее – нет;
2) Производительность – не самая сильная сторона R или Python. Сможет ли ваше решение работать с такой же производительностью, как SQL-запрос? Здесь могут быть сомнения;
3) Установка дополнительных библиотек – не всегда простая задача. Если вам доводилось работать в крупных организациях, то на согласование и установку библиотек уйдут месяцы;
4) По поводу того, что нельзя/сложно апроксимировать периодическую функцию: ряд Фурье считается SQL-ем практически так же, как и другим языком;
5) Какой код легче читать – здесь, как нам кажется, дело вкуса и привычки.
1) На MS SQL тоже самое доступно через sp_execute_external_script() или через CLR. Hana и Oracle я знаю поверхностно, но сомневаюсь, что они лишены подобных интерфейсов.
2) Что касается производительности, то тут Вы лукавите. Математические пакеты и в R, и в Python, пишут на C/C++ и сами языки выступают лишь связкой между вызовами. Да и не сказал бы, чтобы производительность plpgsql была выше, чем у plr или plpythonu.
3) Мне доводилось внедрять в очень крупных организациях. Именно поэтому я поставил на первое место R, так как для Python есть только небезопасный plpythonu. Для R же все намного проще согласуется.
4) Я имел в виду намного более сложные аппроксимации. Например, восстановление пропусков фильтром Калмана по сезонной модели ARIMA.
5) SQL не предоставляет удобных способов присвоения переменной значения и использование значений этой переменной в одном и том же запросе. Костыли в виде функций или CTE и читаются хуже, и на производительность влияют не лучшим образом. Отсюда и громоздкие повторяющиеся выражения. Все же математические выкладки лучше вписываются в императивное представление, чем в декларативное.
Полином второго порядка практически редко используется в области разработки измерительных приборов и датчиков, где требуется мало мальки точность выше 0.1. %. Использовать sql для решения систем линейных уравнений в количестве больше 8 - это слишком громоздко и не имеет смысла. В моей статье на хабре я описал разработанную нами систему, где мы рассчитываем 25 коэффициентов по методу наименьших квадратов при линеаризации передаточное характеристики датчика. Sql там я использую только для создания и транспонирования матриц для расчёта коэффициентов на клиенте Labview. Там уже есть готовый компонент под такие расчёты, причём десятком методов. Мы выбрали метод Гивенса, которому скармливаются матрицы из sql и который даёт точность при обратном расчёте 10 в минус 10 степени, что вполне достаточно для технологического запаса для прибора класса 0.04%. Более высокую точность расчёта даёт использование matcad, но это уже сложнее использовать с sql. Я придерживаюсь принципа достаточности и это работает.
Использовать sql для решения систем линейных уравнений в количестве больше 8 - это слишком громоздко
А на PostgreSQL в функции, написанной на R - вообще без проблем. Естественно, тут надо понимать, какие расчеты оправданы на процессорных ядрах SQL сервера, а какие лучше поручить специализированным на вычислениях кластерам. Однозначного ответа тут нет.
Сравнительный анализ методов аппроксимации на основе SQL-запросов