gnuplot pontosság

Segédprogramok

Levenberg-Marquardt algoritmussal függvényt kéne illesztenem adatpontokra. A Gnuplot fit parancsa pont ezt csinálja, csak nekem A FIT_LIMIT paramétert 10^-500-ra kéne állítani, Viszont csak 10^-309-ig lehet. (10^-320 körül még elfogadja, de akkor már elkerekíti.) Nem tudja valaki, megoldható-e valahogy a 10^-500-as érték? Egyáltalán mekkora tartományban számol a gnuplot (a leírásban nem találtam erre utalást, de lehet, hogy csak én voltam vaksi)? Esetleg tud valaki olyan ingyenes programot Linuxra, ami képes erre? Fizetőset (aranyárban) és ráadásul win-re én is tudok, az t nem kell írni (Sigmaplot).

  • 1682 megtekintés

( vol4 | 2007. 03. 30., p – 22:06 )

Bocs, de áruld már el (baromira érdekelne), hogy mihez kell a 10^-500 pontosság!
----------
Were antimatter present, its detection would be quite simple and straightforward. The most rudimentary detector suffices: simply place it down and wait. If the detector disappears, antimatter has been discovered - get out fast!

Nem pontosan fogalmaztam. A FIT_LIMIT nem egészen pontosság, hanem hogy az illeszkedés jóságát leíró chi-square (khi-négyzet) statisztika milyen méretű változására álljon le az iteráció (amíg ezt meghaladja a javulás, csinálja). A feleségem kormeghatározással foglalkozik, és a standard beállításokkal ellátott célprogram nem adott eredményt neki, így megpróbáltuk kézzel illeszteni, Egy cikkben írták a 10^-500 FIT_LIMITET (bár ott másnak hívták, mert ők Sigmaplot-ot használtak). Én is megdöbbentem rajta, de mint kiderült, amikor egy, a cikkben elvégzett illesztést próbáltam reprodukálni a gnuplot-tal, baromi nagy jelentősége van a kérdésées 8 paraméteres, 4 exponenciális függvény összegéből adódó függvény illesztésénél. Egyébként szinte biztos voltam benne, hogy (mint ahogy én is) mindenki elképed a nagyságrenden.

a cikkben elvégzett illesztést próbáltam reprodukálni a gnuplot-tal
a gnuplot neha tud furcsa dolgokat produkalni. a legnagyobb hibaja az, hogy a linearis illlesztest is a nemlin. modszerre (levenberg-marquadt) vezeti vissza, holott azt egzaktul ki lehetne szamolni. az lm modszernel pedig szinten kepes elszallni, ha az ember nem figyel oda... meglepodtem en is, sokszor...

A.

( rpsoft v | 2007. 03. 30., p – 22:45 )

Hát, első tippre az a 10^-309 az valamilyen lebegőpontos számtípusban (talán double) a legkisebb kezelhető mennyiség. Egy (talán) lehetséges megoldás a gnuplotot megpacsálni (patch-elni), hogy minden double helyett long double-t használjon.
Vagy egy direkt fittelőprogramot letölteni, pl. a netlib.org-ról. A Numerical Recipes-ben is biztos van valami, nem hinném, hogy nehéz módosítani valami más számtípushoz (esetleg egy tetszőleges pontosságú lib-hez, valami ügyes wrapper-classal, talán van is valami a függelékben).
Egyébként ez a pontosság-igény elég meghökkentően hangzik. Mihez kell (ha nem hadititok :-) )?

A tömböket tényleg [1]-től számozza a C-verzió (bár, azért vannak egész jól használható vektor- és mátrixlefoglaló rutinjaik), de ennek ellenére használható, ha a) tudomásulveszed, hogy amit NR-hez írsz, mással nem fog együttműködni
b)nem okoz gondot neked ugrálni a kétféle konvenció között.

De egyébként is mindenkit rábeszélnék inkább a C++-változat használatára: sokkal kevesebb lehetőség van elszúrni a programot a mátrix, vektor, stb. objektumoknak köszönhetően (a mátrix meg tudja mondani a méreteit).
Ráadásul a C++-változatban [0]-tól számoznak.

( apal v | 2007. 03. 31., szo – 00:10 )

Valoszinuleg sima double-okkal szamol a gnuplot, innen a 10^{-309}.

Esetleg tud valaki olyan ingyenes programot Linuxra, ami képes erre?
van egy sajat fejlesztesu" biszbasz, lasd itt. Alapesetben ez is sima'n double-okkal szamol, de (szerintem) megpeccselheto" egyszeru"en hogy double helyett long double-lal szamoljon. Azzal ma'r 10^{-6000} koruli ertekek is elerheto"ek (a sizeof(long double)=96 bit az a'tvere's asszem az csak 80bit, de a 80 nem oszthato 32-vel, ezert kiterjesztik 96-ra). x86_64-en pedig asszem ma'r valodi 128bites.

szoval ha meg tudod peccselni a progit, akkor hajra, ha nem, es ra'e'r 1-2 napig, akkor megcsinalhatom (ugy mint forditasi opcio + kezzel makefile beletu'r, ./configure egyelo"re luxus). egyebkent tenyleg frucsa, vagyis nem ertem hogy pontosan mit szeretnel 10^{-500}-as pontossaggal "jellemezni". Az soha nem fog menni, hogy a fittelt parameterek relativ hibaja 10^{-15}-ne'l (long double: 10^{-19} vagy 10^{-30}) jobb legyen.

A.

Aha én is írtam egy kics rutint, arra hogy 128-bites számot szétkava 2-részre (2 long double) ben tároljon 1 számot, a b..b.. pont jó erre az enyém is hasonló de mi a csudának kel ekkora pontosság a gnuplotban? csináld meg c-vel a számolást én a gnuplotot csk rajzra használom.

Sajnos nem egyszerű, nem is lineáris, még paramétereiben sem lineáris az illesztés (azaz nem lehet trükkösen lineáris esetre visszavezetni). Lineáris esetben akár papíron is meg tudom csinálni, nagyobb számoknál meg bármilyen programmal, ami meg tud oldani lin. egyenletrendszert. Elvileg vmi statisztikus féle lennék.

Köszi a választ!

"egyebkent tenyleg frucsa, vagyis nem ertem hogy pontosan mit szeretnel 10^{-500}-as pontossaggal "jellemezni". Az soha nem fog menni, hogy a fittelt parameterek relativ hibaja 10^{-15}-ne'l (long double: 10^{-19} vagy 10^{-30}) jobb legyen."
Az első post-ra adott válaszomban írtam, hogy mire mondtam a pontosságot (maradnom kellett volna a FIT_LIMIT kizárólagos használatánál). A paraméterek relatív hibája konkrét esetben egész nagy is lehet.

Megkérdezhetem, hogy a "saját fejlesztésű biszbasz" a nemlineáris illesztést milyen módszerrel/algoritmussal végzi? Nekem speciel korábbi eredmények reprodukálása miatt muszáj a Levenberg-Marquard algoritmus. Bár az meg ott van végül is a Numerical Recipes-ben, majd heggesztek egy kicsit.

nemlineáris illesztést milyen módszerrel/algoritmussal végzi?
ez is L-M-et hasznal, de elvileg az osszes parametere (\lambda, \lambda_m, iteraciok szama e's a kezdeti ertekek) beallithato kezzel. so"t, a kezdeti ertekeket be is kell allitani... kulonben nagyon el tud sza'llni.

A.

http://www.ics.forth.gr/~lourakis/levmar/
gnu scientific library (Minimization Algorithms using Derivatives)
a LAPACK FORTRANt hasznal, de van c interface-e (sot c++ interface-e) is
http://www.idiom.com/~zilla/Computer/Javanumeric/index.html
.
.
.
http://octave.sourceforge.net/doc/f/leasqr.html
k.

ajánlom még esetleg a BFGS-t
néha bizony jobban muzsikál, mint a L-M

de én is valami kapitális félreértést érzek itt 10^-500 az nagyon túllövés a célon
olyat még soha nem láttam, ahol a chsq relatív változására 10^-10 -nél kisebb aránynak lett volna értelme

Az itt található cikkben a 12 oldal alsó felén szerepel a kérdéses érték. Nincs okom kételkedni a szerzők hozzáértésében, kb. 30 éve aktív művelői a területnek, egyikük az elméleti alapok egyik kidolgozója (nem a függvényillesztésé, hanem az optikai kormeghatározásé). Kicsit előtte ott a kérdéses függvényalak is. Egyébként amennyire a gnuplot-os eredmények alapján következtetni tudok rá, nem túllövés a 10^-500, csak baromi lassan konvergál a L-M algoritmus jelen esetben. 10^-5 esetében borzalmasan mellényúl, és ez még 10^-300 körül is csak elkezd javulni.

akkor más módszert javaslok pl BFGS

juteszembe! ugye analitikus deriváltakkal dolgozol??? semmiképp se próbálj meg numerikusan közelítettekkel!

+még
http://plato.asu.edu/sub/nonlsq.html

+szerk:
belepislantottam a cikkbe. Én is hasonló dolgokkal foglalkoztam, de nem ennyire alulhatározottakkal. Nem tudom, hogy ennek a feladatnak ilyen lapos chsq függvény mellet van-e egyáltalán értelme - vagy lehet, hogy kimerítő kereséssel jobban jársz, mint általános nonlin illesztővel.

No, nekem az egészhez csak annyi közöm van, hogy a feleségem kutatóként optikai kormeghatározással foglalkozik, és a standard software, amit használnak, sok mintájára nem adott eredményt. Elkezdett utánajárni a dolognak és akkor találta ezt a cikket. Én meg úgy jövök a képbe, hogy van némi közöm a statisztikához, ez meg végül is egy nemlineáris regresszió. Sigmaplot (amire a cikk hivatkozik) itthon nincs, és nem is lesz (a munkahelyén, mint közben kiderül van, sőt még upgrade-elik is frissre mert másnak is kell, mint kiderült), úgyhogy szétnéztem mi tudja a cikkben emlegetett módon a nemlineáris legkisebb négyzetek módszerét. Jé, a gnuplot pont így dolgozik. Nosza, probléma megoldva. Aztán mégsem.
Kérdésedre, hogy analitikus deriváltakkal dolgozom-e, az a válaszom, hogy nem tudom, amennyiben a gnuplot igen, akkor igen, ellenkező esetben nem. De egyenlőre ennyire ástam bele magam a területbe, s bár érdekel, de azért közben a saját melómmal is kell foglalkoznom. Már így is sokat segítettetek, van honnan elindulnom.
Az L-M algoritmus meg csak azért kéne (legalább is kezdetben), mert szeretném kontrollálni, pontosan a cikben bemutatott eredményekre jutok-e, tudom-e azokat reprodukálni. Így is a falra mászok, hogy sok kutató a számítási módszerek leírásánál olyan cikkekre hivatkozik, amik szontén csak másik cikkekre hivatkoznak, és konkrétan ebben a cikkben láttam először leírva, mivel számolnak. Pedig a feleségemnek a diplomamunkája megírása óta rágom a fülét, hogy járjon utána, mert érdekel. Mostanra futott bele (pedig eltelt közben pár év).

ahh most néztem meg, mi is pontosan a gnuplot tool, amivel dolgozol
hát izé
asszem ez kevés lesz hozzá

- én előkapnám a Numerical Recipes mrqmin LM minimalizáló algoritmusát
- kiszedném a deriváltakat pl Matematikából vagy Derive-ból
- összeütnék egy kis móricka programot ami képes beadott adatfájlt illeszteni
- aztán sokat, sokat tesztelgetném, haladnék a triviálistól a bonyolultabb görbe illesztési problémák felé

így együtt kitapasztalnám a viselkedését az eszköznek és a problémának, és előbb vagy utóbb szépen szakértő lennék a témában

programozási gyakorlattal 1-2 hónap
anélkül 1 év

Nagyjából ez a terv, amit vázoltál, kiegészítve azzal, hogy a deriváltak azért nem túl rondák (ebben a konkrét esetben), papíron is megy akár, vagy mondjuk akkor már legyen maxima, az van Linux-on is. A móricka programnál meg is áll a dolog egyenlőre, mert a feleségemnek kifejezetten ilyen alakú görbék kellenek. Esetleg saját érdeklődésre bővítgetem majd, de szvsz majd úgy, hogy a deriváltakat kézzel kell megadni paraméterként a függvénnyel együtt. Az hogy a gnuplot kevés, az már sejthető volt a kérdés felvetésekor is, inkább az okokra, meg tanácsokra voltam kiváncsi.

( godri | 2007. 03. 31., szo – 22:13 )

Hali,

ezekhez a statisztikai dolgokhoz nem értek, de van egy gretl (http://gretl.sourceforge.net) nevü program, ami az általad említett algoritmust is kezeli.

sajnos nics vele különösebb tapasztalatom, gőzöm sincs, hogy milyen pontos, jó-e Neked egyáltalán (biztosan jobban értesz nálam a témához). Esetleg egy pillantást megér.

A gretl alapvetően ökonometriai számításokra van, olyannyira, hogy a Ramanathan: Introduction Econometrics könyvhöz CD-n mellékelik (korábbi kiadásoknál zárt forrású programot kellett venni a példaszámításokhoz, úgyhogy nagy piros pont a szerzőnek). Elvileg erre is jó lenne, azonban gyakorlatilag nem. Kevésbé idétlen alakú függvényekre van az felkészülve. Főleg ilyen feltételekkel, mint 10^-500 FIT_LIMIT. De köszi.