Verfasst am: 19.11.2021, 14:49
Titel: Wie "klein" dürfen Solver options sein
Hallo,
eine Frage beschäftigt mich sehr: Kann es generell Sinn machen, Konvergenzkritieren in den Solveroptions (eines lsqnonlin Solvers bspw.) kleiner als.. sagen wir 10^-50 zu stellen? Ist hier eine technische Grenze überschritten, oder formt der Solver das numerisch irgendwie um, so dass er auch bei derart geringen Toleranzen noch sinnvoll arbeiten kann?
kleiner als etwa 1e-12 ist aus meiner Sicht nicht sinnvoll, da Double nur 15-16 Nachkommastellen hat. Selbst so genaue Ergebnisse braucht man doch in aller Regel gar nicht?
Was der Solver mit zu kleinen Toleranzen macht, weiß ich offen gesagt nicht.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Für mein Problem erhalte ich andere Lösungen, wenn ich die Toleranzen strenger einstelle. Er sucht dann länger - endet aber in beiden Fällen mit dem exitflag 3:
"Change in the residual is less than the specified tolerance."
Auch nähern sich die angegeben Werte, wenn ich Display auf "iter" stelle, stetig dem von mir angesetzten, absurd kleinen Grenzwert an (und stoppen nicht etwa bei 10^-16, wie in meinem Screenshot zu sehen ist).
Ganz sicher, dass der lsqnonlin Solver bzw. Matlab an der Stelle die Werte nicht irgendwie "umskaliert" ? Wie kann ich Ergebnisse mit 24 bzw. 50 Nachkommastellen erhalten, wenn die Grenze matlab-intern bei 10^-16 liegt ?
(Für den Screenshot habe ich die Solveroptions auf 10^-60 gestellt und nicht wie im ersten Beitrag auf 10^-50)
Mein Argument wäre, dass die Anzahl der Nachkommastellen doch nur etwas über die mögliche Genauigkeit aussagt. Jedoch lässt sich ein Ergebnis doch beliebig um 10er Potenzen erweitern - und kann dennoch 15 Nachkommastellen haben.
Also zB.:
1,534857665243526 * 10^-30
Macht das Sinn?
Zitat:
Selbst so genaue Ergebnisse braucht man doch in aller Regel gar nicht?
Das hängt natürlich vom Problem ab. Wenn ich mit Terrakubikmetern rechne (statt mit Kubikcentimetern) brauche ich enorm kleine Werte. Bei dem Problem, an dem ich arbeite, kann ich die Variablen leider nicht umskalieren. Und die Ergebnisse scheinen nun mal entsprechend dimensioniert zu sein.
Alles natürlich unter dem Vorbehalt, dass wir "Genauigkeit" und "sehr kleine Werte" vertauscht haben (wie oben in diesem Beitrag dargestellt).
den Ausdruck "Nachkommastellen" hätte ich in der Tat nicht verwenden sollen, stattdessen nur Stellen. Es geht letztlich um eine relative Genauigkeit.
Zitat:
Wenn ich mit Terrakubikmeters rechne (statt mit Kubikmetern) brauche ich enorm kleine Werte.
Die Frage ist nicht, wie groß oder klein die Werte sind, sondern wie groß oder klein die relative Genauigkeit ist. Ein 1,23456789012345e10 kann man als genauso genau oder ungenau ansehen wie ein 1,23456789012345e-10. Die entscheidende Frage ist, ob nach der 5 vor dem e noch weitere Genauigkeitsstellen sind.
In deinem Fall sieht es so aus, als ob die wahre Lösung 0 ist. Finden wird man sie aber halt mit numerischen Mitteln nie.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Generally set tolerances such as OptimalityTolerance and StepTolerance to be well above eps, and usually above 1e-14. Setting small tolerances does not always result in accurate results. Instead, a solver can fail to recognize when it has converged, and can continue futile iterations. A tolerance value smaller than eps effectively disables that stopping condition. This tip does not apply to fzero, which uses a default value of eps for the TolX tolerance.
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Vielen Dank! Genau nach so etwas suche ich. Also so eine Art offizielle Erklärung.
Ich habe nochmal recherchiert: Matlab kann wohl die relative Genauigkeit auf 15 Nachkommastellen angeben. Jedoch können Werte im Bereich 10^300 bis 10^-300 dimensioniert werden. Wichtig ist aus meiner Sicht, dass man sich der Rechenfehler im Klaren ist, die dabei entstehen.
Die beiden Rechnungen
1,123456789 + 1,123456789
und
1,123456789 * 10^-100 + 1,123456789*10^-100
sind also gleichmeraßen genau und durchführbar.
Was nicht geht, ist das folgende:
1,123456789 + 1,123456789*10^-100
weil dann ca. 90 Nullen zusätzlich an den ersten Wert anhängt werden müssten.
Es kommt also bei Rechnungen ganz auf die Ähnlichkeiten der Zahlen an, die miteinander summiert oder multipliziert werden.
Nichts desto trotz muss ich noch irgendwie dahinter steigen, warum ich bei 10^-24 bessere Ergebnisse erhalte als bei 10^-16.
Zitat:
Generally set tolerances such as OptimalityTolerance and StepTolerance to be well above eps, and usually above 1e-14. Setting small tolerances does not always result in accurate results. Instead, a solver can fail to recognize when it has converged, and can continue futile iterations. A tolerance value smaller than eps effectively disables that stopping condition. This tip does not apply to fzero, which uses a default value of eps for the TolX tolerance.
Der Text schließt aus meiner Sicht nicht völlig aus, dass bei Toleranzen unterhalb 10^-14 sinnvoll gearbeitet werden kann, sondern stellt ein Risiko in Aussicht. Möglicherweise aus genau den oben geschilderten Gründen. Wenn an absolut 0 angefittet werden soll, sehe ich aber eigentlich keinen Grund, weshalb der erwartete Funktionswert nicht unterhalb 10^-14 liegen sollte. (anders wäre es, wenn man vorher 1,0 - f(x) rechnen würde)
Wenn an absolut 0 angefittet werden soll, sehe ich aber eigentlich keinen Grund, weshalb der erwartete Funktionswert nicht unterhalb 10^-14 liegen sollte.
Er kann sogar bei 1e-50 liegen. Eine relative Toleranz von 1e-14 würde dann bedeuten, dass auch die 64. Nachkommastelle genau bestimmt werden soll. Das erscheint mir reichlich überzogen.
Mangels eines reproduzierbaren Beispiels kann ich das ganze nicht selbst komplett nachvollziehen. In deinem Screenshot sieht man allerdings, dass im Zielfunktionswert und in der Gradientennorm keine Änderungen mehr erkennbar sind.
Wenn die zu optimierenden Variablen nicht in einer Größenordnung von unter 1e-34 sind, ist das auch kein Wunder: bei einer Schrittweite von 1e-50 wäre die Veränderung unterhalb der Maschinengenauigkeit.
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Wenn die zu optimierenden Variablen nicht in einer Größenordnung von unter 1e-34 sind, ist das auch kein Wunder: bei einer Schrittweite von 1e-50 wäre die Veränderung unterhalb der Maschinengenauigkeit.
Genau das glaube ich auch. Die Schrittweiten noch kleiner zu wählen, macht hier wirklich keinen Sinn. (Die Variablen spielen sich im 1 bis 10^-4 Bereich ab.) Ich hatte einfach sicherheitshalber mal alles intoleranter gestellt.
Aber was den Funktionswert angeht (bzw. die Änderung des Funktionswertes), kann man dann, wie ich es jetzt verstehe, beliebig kleine Werte als Abbruchkriterium definieren und sinnvoll damit arbeiten. Solange:
- der Funktionswert nicht durch die Verrechnung von festen Werten einer bestimmten Größenordnung bestimmt wird (zB wenn durch Rechnung von 1,0 * 10^1 ein beliebiger Wert abgezogen wird. Änderungen kleiner 10^-16 werden dann nicht registriert, weil die Anzahl der Nachkommastellen sicher nicht ausreichen wird, um das geänderte Ergebnis darzustellen.)
- man nicht die Matlab eigene "Grenze" von 10^-300 sprengt
Hierzu noch eine Frage: Ich habe jetzt etwas recherchiert und nichts "offizielles" zu den 10^-300 gefunden. Hast du noch einen Tipp, wo ich da suchen kann?
Aber was den Funktionswert angeht (bzw. die Änderung des Funktionswertes), kann man dann, wie ich es jetzt verstehe, beliebig kleine Werte als Abbruchkriterium definieren und sinnvoll damit arbeiten.
Sehe ich nicht so. Relative Änderungen < eps sind ja ohnehin nicht möglich.
Zitat:
Hierzu noch eine Frage: Ich habe jetzt etwas recherchiert und nichts "offizielles" zu den 10^-300 gefunden. Hast du noch einen Tipp, wo ich da suchen kann?
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Sehe ich nicht so. Relative Änderungen < eps sind ja ohnehin nicht möglich.
Dann gut, dass ich nochmal nachgefragt habe.
Leider werde ich mich dem Thema wahrscheinlich erst wieder in einigen Wochen widmen können. Dann bleibt die Frage zu klären, warum mein Problem "besser" gelöst wird, wenn die obigen Toleranzen auf derart kleine Werte eingestellt werden.
Meinetwegen kann das Thema also gerne noch offen bleiben, damit ich mich in Zukunft dazu mitteilen kann. Danke für die Unterstützung bis hierher
ich würde es gerne nachvollziehen können. In deinem Screenshot sieht man ja eben nicht, dass die Funktionswerte noch besser werden.
Die Doku verstehe ich so, dass du das entsprechende Stopp-Kriterium quasi deaktivierst, wenn du es so klein setzt.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Einstellungen und Berechtigungen
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS