Hilfe bei gnuplot - Regressionsgerade

[mathe-ist-lang-her (Gast)]

Ich habe eine kleine Messreihe, 2 Werte die von der Zeit abhängig sind.

07.08.21-19:00   -60380   -63703
07.08.21-19:20   835972  3800921
07.08.21-20:00   673433  3715989
07.08.21-20:20   518252  3599637
07.08.21-22:00    33228  3308804
07.08.21-23:00   719595  4111845
08.08.21-10:40   132950  4886900
08.08.21-11:00    49300  4842150
08.08.21-11:40  -198150  4672900
08.08.21-16:20  -713574  4702969
08.08.21-17:40  -116946  5458207
08.08.21-21:00  -157100  5819400
08.08.21-22:40  -703010  5473281
08.08.21-23:20  -939400  5316600
09.08.21-10:00 -1203712  6326313
09.08.21-17:20 -1640250  6782940
09.08.21-23:00 -1416150  7704500
10.08.21-10:00 -1683400  8790200

Die möchte ich mit gnuplot in eine Grafik umwandeln, Darstellung der 
Punkte in der 2. und 3. Spalte sowie je eine Regressionsgerade (lineare 
Regression).

#!/usr/bin/gnuplot

filnam='timer.log'

set yrange [-2000000:12000000]

set xdata time
set timefmt '%d.%m.%y-%H:%M'
set format x '%d.%m.%y-%H:%M'
set xtics 21600 rotate by 60 right

set grid
set terminal svg
set output 'timer.svg'

f(x)= a + b*x
fit f(x) filnam using 1:2 via a,b

g(x)= m + n*x
fit g(x) filnam using 1:3 via m,n

plot filnam using 1:2 title '001' lt 5 lc 2, f(x), \
     filnam using 1:3 title '002' lt 7 lc 7, g(x)

Leider entspicht das Ergebnis timer.svg nur teilweise meinen 
Erwartungen, die Punkte sind ok aber die Rergressionsgeraden dürften 
nicht stimmen.

Was mache ist falsch?

[Nano (Gast)]

Die Reihenfolge kriegst du mit einer entsprechenden Reihenfolge der 
Parameterübergabe an die Plot funktion hin.

Versuch mal:

plot f(x), g(x), filnam using 1:2 title '001' lt 5 lc 2,  \
     filnam using 1:3 title '002' lt 7 lc 7

Und zu f(x)= a + b*x und g(x)= m + n*x würde ich mal vermuten, dass die 
Variablen nicht initialisiert wurden.

[mathe-ist-lang-her (Gast)]

Vielen Dank für deine Antwort, leider ändert sich gar nichts.

#!/usr/bin/gnuplot

filnam='timer.log'

set yrange [-2000000:12000000]

set xdata time
set timefmt '%d.%m.%y-%H:%M'
set format x '%d.%m.%y-%H:%M'
set xtics 21600 rotate by 60 right


set grid
set key left top
set terminal svg
set output 'timer.svg'

a=1*10**5
b=1000
f(x)= a + b*x
fit f(x) filnam using 1:2 via a,b

m=4*10**6
n=1000
g(x)= m + n*x
fit g(x) filnam using 1:3 via m,n

plot f(x), g(x), filnam using 1:2 title '001' lt 5 lc 2, \
     filnam using 1:3 title '002' lt 7 lc 7

Ich habe auch verschiedene andere Initialisierungswerte durchprobiert, 
die Geraden sind immer waagerecht und an der gleichen Position.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Läuft das original Gnuplot Demo-File fit.dem bei dir?

https://github.com/gnuplot/gnuplot/tree/master/demo

Neben fit.dem brauchst du noch ein paar der .dat-Files. Am besten 
einfach alles runter laden oder die Version aus deiner lokalen 
gnuplot-Installation nehmen.

[mathe-ist-lang-her (Gast)]

Hannes J. schrieb:
> Läuft das original Gnuplot Demo-File fit.dem bei dir?

läuft problemlos, die Regressionsgeraden entprechen auch dem, was ich 
erwarte

[Andreas M. (amesser)]

ich glaube nicht, dass gnuplot Datumsachsen fitten kann. Evtl gibts ne 
Funktion, die aus dem Datum einen Sekundenzeitstempel macht, die man 
statt "x" in die Funktionsdefinition einsetzen kann.

[Wolfgang (Gast)]

Andreas M. schrieb:
> ich glaube nicht, dass gnuplot Datumsachsen fitten kann.

Schon gar nicht so ein verf..tes Datum/Zeit-Format, wo man erstmal 
rätseln darf, was das Minuszeichen vor der Uhrzeit zu bedeuten hat ... 
;-)

[Wolfgang (Gast)]

Andreas M. schrieb:
> ich glaube nicht, dass gnuplot Datumsachsen fitten kann. Evtl gibts ne
> Funktion, die aus dem Datum einen Sekundenzeitstempel macht, die man
> statt "x" in die Funktionsdefinition einsetzen kann.

Zumindest versteht GnuPlot das Datum/Zeit-Format richtig. Sonst würden 
die
Abstände der Punkte auf der x-Achse nicht stimmen.

[mathe-ist-lang-her (Gast)]

gnuplot rechnet auf der Zeitachse mit Sekunden seit 1.1.70

Das verf..te Datumsformat hat einen handfesten Grund: nehme ich das 
Leerzeichen statt des - (2021.08.07 19:20 statt 2021.08.07-19:20), dann 
kommt eine falsche Grafik raus, siehe Bild, ich weiss nicht, was gnuplot 
da macht.

[Nano (Gast)]

mathe-ist-lang-her schrieb:
> gnuplot rechnet auf der Zeitachse mit Sekunden seit 1.1.70
>
> Das verf..te Datumsformat hat einen handfesten Grund: nehme ich das
> Leerzeichen statt des - (2021.08.07 19:20 statt 2021.08.07-19:20), dann
> kommt eine falsche Grafik raus, siehe Bild, ich weiss nicht, was gnuplot
> da macht.

Das Leerzeichen dürfte hier das Trennzeichen sein.
Damit dürften deine zwei Werte in der 3. und 4. Spalte liegen.

[Nano (Gast)]

Und wenn den Bindestrich verwendest, dann könnte ich mir vorstellen.
das Gnuplot es folgendermaßen interpretiert, aber das ist nur eine 
Vermutung von mir. Die Doku dürfte genaueren Aufschluss darüber geben, 
wie Zeit und Datumsangaben auszusehen haben:

Aus
07.08.21-19:00

wird
07.08.21 MINUS 19:00

[Wolfgang (Gast)]

mathe-ist-lang-her schrieb:
> Das verf..te Datumsformat hat einen handfesten Grund: nehme ich das
> Leerzeichen statt des - (2021.08.07 19:20 statt 2021.08.07-19:20), dann
> kommt eine falsche Grafik raus, siehe Bild, ich weiss nicht, was gnuplot
> da macht.

Dieses Format (2021.08.07) ist doch nun der größte Kokolores - nichts 
Halbes und nichts Ganzes.
Vielleicht versteht Gnuplot ein Datumsformat nach ISO 8601?
Um Problemen mit dem Trennzeichen aus dem Weg zu gehen, z.B. in der 
Variante
2021-08-07T19:20
https://de.wikipedia.org/wiki/ISO_8601

[mathe-ist-lang-her (Gast)]

ich habe jetzt mal das Stringformat von x in das Sekundenformat seit 
1.1.70 umgewandelt, der gleiche Mist.

#!/usr/bin/gnuplot

filnam='timer.log'

# set yrange [-2000000:12000000]

set xdata time
set timefmt '%Y.%m.%d-%H:%M'
set format x '%Y.%m.%d-%H:%M'
set xtics 21600 rotate by 60 right

set grid
set key left top
set terminal svg
set output 'timer.svg'

a=1*10**6
b=-8*10**-4
f(x)= a + b*strftime('%Y.%m.%d-%H:%M',x)
fit f(x) filnam using 1:2 via a,b

m=4*10**6
n=8*10**-4
g(x)= m + n*strftime('%Y.%m.%d-%H:%M',x)
fit g(x) filnam using 1:3 via m,n

plot f(x) lc 2, \
     g(x) lc 7, \
     filnam using 1:2 title '001' lt 5 lc 2, \
     filnam using 1:3 title '002' lt 7 lc 7

Irgendwie rechnet gnuplot schon richtig, in der Ausgabe im terminal 
erscheinen nämlich plausible Werte für a und b

x@x-ubuntu:~$ ./timer.gp
iter      chisq       delta/lim  lambda   a             b            
   0 1.3104851021e+14   0.00e+00  2.12e+06   -3.000000e+06  -8.000000e-04
   1 1.1015258960e+13  -1.09e+06  2.12e+05   -4.176534e+05  -7.999996e-04
   2 1.0917192587e+13  -8.98e+02  2.12e+04   -3.417244e+05  -7.999996e-04
   3 1.0917192578e+13  -7.77e-05  2.12e+03   -3.417020e+05  -7.999996e-04
iter      chisq       delta/lim  lambda   a             b            

After 3 iterations the fit converged.
final sum of squares of residuals : 1.09172e+13
rel. change during last iteration : -7.76597e-10

degrees of freedom    (FIT_NDF)                        : 15
rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : 853119
variance of residuals (reduced chisquare) = WSSR/ndf   : 7.27813e+11

Final set of parameters            Asymptotic Standard Error
=======================            ==========================
a               = -341702          +/- 8.02e+20     (2.347e+17%)
b               = -0.0008          +/- 3.968e+17    (4.96e+22%)

correlation matrix of the fit parameters:
                a      b      
a               1.000 
b              -1.000  1.000 
iter      chisq       delta/lim  lambda   m             n            
   0 3.6752888539e+13   0.00e+00  3.54e+06    5.000000e+06   8.000000e-04
   1 3.5659280348e+13  -3.07e+03  3.54e+05    5.246487e+06   8.000000e-04
   2 3.5658386878e+13  -2.51e+00  3.54e+04    5.253735e+06   8.000000e-04
   3 3.5658386878e+13  -2.17e-07  3.54e+03    5.253737e+06   8.000000e-04
iter      chisq       delta/lim  lambda   m             n            

After 3 iterations the fit converged.
final sum of squares of residuals : 3.56584e+13
rel. change during last iteration : -2.16617e-12

degrees of freedom    (FIT_NDF)                        : 15
rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : 1.54183e+06
variance of residuals (reduced chisquare) = WSSR/ndf   : 2.37723e+12

Final set of parameters            Asymptotic Standard Error
=======================            ==========================
m               = 5.25374e+06      +/- 1.323e+21    (2.518e+16%)
n               = 0.0008           +/- 6.547e+17    (8.183e+22%)

correlation matrix of the fit parameters:
                m      n      
m               1.000 
n              -1.000  1.000 
x@x-ubuntu:~$

[mathe-ist-lang-her (Gast)]

Das Datumsformat wird von mir vorgegeben, es ist ein String in '', da 
wird nichts subtrahiert. Schaut Euch nochmal den Sourcecode an. 
Ausserdem sind die Messwerte als Punkte an den richtigen Stellen in der 
Grafik, wo es klemmt ist die Gerade.

[mathe-ist-lang-her (Gast)]

So, jetzt hab ich's, das Datum mit mit - getrennt werden, T ('ISO') geht 
nicht und ' ' geht auch nicht.

nochmal die Daten:

2021-08-07-19:20   835972  3800921
2021-08-07-20:00   673433  3715989
2021-08-07-20:20   518252  3599637
2021-08-07-22:00    33228  3308804
2021-08-07-23:00   719595  4111845
2021-08-08-10:40   132950  4886900
2021-08-08-11:00    49300  4842150
2021-08-08-11:40  -198150  4672900
2021-08-08-16:20  -713574  4702969
2021-08-08-17:40  -116946  5458207
2021-08-08-21:00  -157100  5819400
2021-08-08-22:40  -703010  5473281
2021-08-08-23:20  -939400  5316600
2021-08-09-10:00 -1203712  6326313
2021-08-09-17:20 -1640250  6782940
2021-08-09-23:00 -1416150  7704500
2021-08-10-10:00 -1683400  8790200

und das Programm

#!/usr/bin/gnuplot

filnam='timer.log'

# set yrange [-2000000:12000000]

set xdata time
set timefmt '%Y-%m-%d-%H:%M'
set format x '%Y-%m-%d %H:%M'
set xtics 21600 rotate by 60 right

set grid
set key left top
set terminal svg
set output 'timer.svg'

a=-3.0e+06
b=-8.0e-04
f(x)= a + b*x
fit f(x) filnam using 1:2 via a,b

m= 5.0e+06
n= 8.0e-04
g(x)= m + n*x
fit g(x) filnam using 1:3 via m,n

plot  filnam using 1:2 title '001' lt 5 lc 2, f(x) lc 2, \
      filnam using 1:3 title '002' lt 7 lc 7, g(x) lc 7

[mathe-ist-lang-her (Gast)]

Was ich noch herausgefunden haben: a und b müssen mit Werten vorbesetzt 
werden, die nicht um Grössenordnungen daneben liegen.

[Andreas M. (amesser)]

mathe-ist-lang-her schrieb:
> Was ich noch herausgefunden haben: a und b müssen mit Werten vorbesetzt
> werden, die nicht um Grössenordnungen daneben liegen.

Hmm, sollte bei einem linearen Fit eigentlich keine Rolle spielen. 
Eventuell bricht er zu früh ab?

Zu Studiumszeiten habe ich viel mit Gnuplot gearbeitet. Gerade die 
Möglichkeit die Diagramme im Tex-Format zu Erzeugen und dann die zu den 
Formelbereichen des Dokuments passende Tex-Schriftart zu verwenden macht 
was her. Inzwischen benutze ich aber fast nur noch pyplot. Die Diagramme 
sind auch schön anzusehen und man hat die gesamte Mächtigkeit von numpy 
bzw. Python ansich in der Hinterhand.

[Wolfgang (Gast)]

mathe-ist-lang-her schrieb:
> Was ich noch herausgefunden haben: a und b müssen mit Werten vorbesetzt
> werden, die nicht um Grössenordnungen daneben liegen.

Kein Wunder, wenn du da eine iterativ arbeitende Parametersuche drauf 
los lässt. Warum rechnest du die Ausgleichsgrade nicht direkt aus?

Formeln unter 2.5 Berechnungsformeln (S.3)
http://www.carl-engler-schule.de/culm/culm/culm2/th_messdaten/mdv2/auszug_ausgleichsgerade.pdf

[mh (Gast)]

Wolfgang schrieb:
> mathe-ist-lang-her schrieb:
>> Was ich noch herausgefunden haben: a und b müssen mit Werten vorbesetzt
>> werden, die nicht um Grössenordnungen daneben liegen.
>
> Kein Wunder, wenn du da eine iterativ arbeitende Parametersuche drauf
> los lässt. Warum rechnest du die Ausgleichsgrade nicht direkt aus?

Solange man keine Werte wählt, die zu "numerischem Fehlerverhalten" 
(Overflows, Underflows, NaNs, ...) führen sollte der benutzte "nonlinear 
least-squares Marquardt-Levenberg algorithm" für diese lineare Funktione 
mit jedem Startwert zum richtigen Ergebnis kommen.

[Wolfgang (Gast)]

mh schrieb:
> "nonlinear least-squares Marquardt-Levenberg algorithm"

Nochmal: Warum einen iterativen Suchalgorithmus, wenn man Steigung und 
Achsenabschnitt der Ausgleichsgraden direkt ausrechnen kann=?

[mh (Gast)]

Wolfgang schrieb:
> mh schrieb:
>> "nonlinear least-squares Marquardt-Levenberg algorithm"
>
> Nochmal: Warum einen iterativen Suchalgorithmus, wenn man Steigung und
> Achsenabschnitt der Ausgleichsgraden direkt ausrechnen kann=?
Dann habe ich eine Gegenfrage: Warum sollte man keinen iterativen 
Suchalgorithmus nehemen? Mal davon abgesenen, dass ML für ein lineares 
Modell nicht iterieren sollte.

Warum es sinnvoll ist:
-Weil es schon fertig existiert.
-Weil es einfach auf nichtlineare Funktionen mit vielen freien 
Parametern erweiterbar ist.
-Weil es einfach ist Unsicherheiten für abhängige und unabhängige 
Variablen zu beachten.
-Weil es korrekt implementiert ist.

[Wolfgang (Gast)]

mh schrieb:
> Dann habe ich eine Gegenfrage: Warum sollte man keinen iterativen
> Suchalgorithmus nehemen?

Wenn man Rechenzeit im Überfluss hat und mit den Tücken iterativer 
Suchalgorithmen umgehen kann, spricht überhaupt nichts dagegen.

[mh (Gast)]

Wolfgang schrieb:
> mh schrieb:
>> Dann habe ich eine Gegenfrage: Warum sollte man keinen iterativen
>> Suchalgorithmus nehemen?
>
> Wenn man Rechenzeit im Überfluss hat und mit den Tücken iterativer
> Suchalgorithmen umgehen kann, spricht überhaupt nichts dagegen.

Ja, wenn man die extrem rechenaufwendige Matrixmultiplikation nicht 
zahlen möchte, optimiert man für den Spezialfall. Aber bei einer Matrix 
die vermutlich komplett im L1-Cache liegt wird man den Unterschied in 
der Rechenzeit nicht feststellen können, wenn der mit Abstand größte 
Teil der Rechenzeit beim Plotten der Daten draufgeht.

Und was sind nochmal die Tücken dieses iterativen Suchalgorithmus?

[Wolfgang (Gast)]

mh schrieb:
> Aber bei einer Matrix die vermutlich komplett im L1-Cache liegt wird man
> den Unterschied in der Rechenzeit nicht feststellen können

Der Unterschied ist, dass man die Rechnung für jeden Iterationsschritt 
machen muss, nicht nur ein Mal.

> Und was sind nochmal die Tücken dieses iterativen Suchalgorithmus?
Die Startwerte - abhängig von der "Topologie des Fehlergebirges". Da ist 
der TO gerade drüber gestolpert.

mathe-ist-lang-her schrieb:
> Was ich noch herausgefunden haben: a und b müssen mit Werten vorbesetzt
> werden, die nicht um Grössenordnungen daneben liegen.