Подгонка (фиттирование), правильные ошибки Опции

[metelev_sv]

Вот замерил передвижения одного из столиков на своей установке. Устроено оно так: мотор крутит вал, через червячную передачу движение передаётся на движущуюся поверхность столика. Кроме того на валу сидит датчик, который считает обороты. Ну вот, интересно мне было, какое перемещение приходится на один шаг датчика и насколько оно равномерное. Набил данные и фиттирую их обычной линейной функцией. Фиттирую в программе root, там есть возможность использовать пакеты MINUIT и FUMILI и для контроля то же самое программой gnuplot. Как водится, все три результата разные (IMG:style_emoticons/default/smile.gif) То есть коэффициенты одинаковые получаются (поскольку зависимость линейная, можно было бы проверить по точным формулам линейной регрессии, но мне лень и я думаю, что здесь провраться сложно). А вот ошибки во всех трёх случаях отличаются. Может быть кто-то сразу может сказать, что чем-то пользоваться не следует, или не поленится отфиттировать данные программой, которой пользуется сам и сравнить результат, тоже было бы интересно. Мне представляется, что FUMILI правильную ошибку даёт, а MINUIT и gnuplot ошибку завышают, иногда на несколько порядков. Просто потому, что более точные значения попадают в менее точные в пределах трёх ошибок в случае FUMILI, как и положено. Параметр p0 сильно отличается в двух случаях, просто потому, что точка отсчёта другая была.

Более точные данные (измерено микрометром, 125 точек):  data2.txt ( 1.72 килобайт ) Кол-во скачиваний: 974

Менее точные данные (измерено штангенциркулем, 9 точек):  data.txt ( 176 байт ) Кол-во скачиваний: 875


Фиттировал по формуле f(x)=p0+p1*x

Результаты по более точным данным:
FUMILI p0=-41.5134(+/-0.000162257) p1=0.0156692(+/-4.70252e-8)
gnuplot p0=-41.5134(+/-0.0126) p1=0.0156692(+/-3.653e-6)
MINUIT p0=-41.5134(+/-0.978949) p1=0.0156692(+/-2.83718e-4)

Результаты по менее точным данным:
FUMILI p0=2.72679(+/-0.0318153) p1=0.0156892(+/-1.58496e-5)
gnuplot p0=2.72679(+/-0.1415) p1=0.0156892(+/-7.047e-5)
MINUIT p0=2.72679(+/-0.628942) p1=0.0156892(+/-3.13323e-4)

[ycheff]

У меня с OriginPro 8.0 получилось (для короткого набора данных): y = kx + b
k = 0.01511 (погрешность 0.61) и b = 3.43898 (погрешность 2.45х10^(-4))

Для большого набора: k = 0.01567 (погрешность 0.014) и b = -41.5024 (погрешность 4.1х10^(-6))

[metelev_sv]

У меня с OriginPro 8.0 получилось (для короткого набора данных): y = kx + b
k = 0.01511 (погрешность 0.61) и b = 3.43898 (погрешность 2.45х10^(-4))

Ориджин кажется не дошёл до самого минимума. Он по умолчанию делает сколько-то итераций и у него специальная кнопка есть, сделать ещё 10 итераций, какая-то такая (IMG:style_emoticons/default/smile.gif) И ещё, ориджин не умеет хорошо работать с параметрами, когда границы для них задаёшь. Если какой-либо параметр упирается в границу, то сходимость очень замедляется. Довольно давно правда я с этим экспериментировал.

Когда-то я принялся FUMILI с фортрана на python переводить. У меня до сих пор есть эта версия, нашёл её, попытался с ней поэкспериментировать. Понял в чём ошибка. Старая, фортрановская версия обязательно требует задания ошибок каждого измерения. Если их задавать руками в root посчитанные ошибки отфиттированных параметров становятся совершенно одинаковыми. В частности, если для точных измерений ставить ошибку 0.01 (ну 0.01мм имеется в виду), то ошибка посчитанная и MINUIT и FUMILI параметра p1 становится равна 2.83718e-6 (по точным данным.) То есть, для минуита по умолчанию берутся единичные ошибки (поскольку отличие ровно на два порядка), для фумили непонятно какие.

Что я с того времени запомнил, что FUMILI это программа, которая разрабатывалась и отлаживалась много лет---просто поразило сколько времени было потрачено только на эту одну задачу. Вот здесь вот про неё есть: http://wwwinfo.jinr.ru/programs/jinrlib/d510.htm Сама она в варианте на фортране есть в церновской библиотеке http://wwwasdoc.web.cern.ch/wwwasdoc/cernlib.html

Раз уж я её раскопал (свою версию перевода FUMILI на python), хочу выложить, чтобы не пропадал труд. Может пригодится кому. Описание даже сделал, на английском почему-то (IMG:style_emoticons/default/smile.gif) Честно признаюсь, протестирована она была на одном единственном примере, но на этом примере результаты работы совпадали с результатами работы фортрановской версии и результатами работы минуита (IMG:style_emoticons/default/smile.gif)

 fumili.ZIP ( 66.34 килобайт ) Кол-во скачиваний: 655

[ycheff]

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

[metelev_sv]

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

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

[metelev_sv]

Недавно обнаружил, что старые книги Numerical Receipes выложены правообладателями и доступны для скачивания. Это книги Numerical Receipes in C, Fortran 77 и Fortran 90. Там же лежит книга Abramowitz and Stegun Handbook of Mathematical Functions, National Bureau of Standards, 1964 и Luc Devroye Non-Uniform Random Variate Generation Springer, 1986

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

Готовые процедуры в книге приведены. Правда, предупреждают что алгоритмы это их собственность. Вот как они пояснят, что можно и что нельзя делать с примерами и процедурами из книги:

Copyright does not protect ideas, but only the expression of those ideas in
a particular form. In the case of a computer program, the ideas consist of the
program’s methodology and algorithm, including the necessary sequence of steps
adopted by the programmer. The expression of those ideas is the program source
code (particularly any arbitrary or stylistic choices embodied in it), its derived object
code, and any other derivative works.

Всё это добро лежит здесь: http://www.nr.com/oldverswitcher.html

PS Пока не посчитал ошибки по рецепту из Numerical Receipes для тех примеров, про которые в шапке топика спрашивал, когда-нибудь надеюсь сделать это (IMG:style_emoticons/default/smile.gif)

[Wild Bill]

На правах рекламы! (IMG:style_emoticons/default/rolleyes.gif)

Посетите сайт НИИ ВЦ МГУ, там обширная библиотека программ на Фортране и С++.