|
|
| yukterez |
Forum-Anfänger
|
 |
Beiträge: 32
|
|
|
|
Anmeldedatum: 19.11.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: R2012b
|
|
|
|
 |
|
Verfasst am: 27.11.2011, 00:52
Titel: eklatanter Logikfehler
|
 |
Ich habe einen offenbaren Bug gefunden:
Die Variablen sind wie folgt definiert (obwohl das hier auch nichts mehr zur Sache tut)
Der Unterschied liegt zwar wie sich´s gehört im Bereich von
Aber eigentlich müsste bei beiden Schreibweisen (siehe oberster Code) das gleiche rauskommen ! Vielleicht liegt der eklatante Logikfehler aber auch in meiner Notation.
Das gleiche passiert übrigens auch bei Freemat:
|
|
|
|
|
|
| eupho |
Forum-Meister
|
|
Beiträge: 777
|
|
|
|
Anmeldedatum: 07.01.09
|
|
|
|
Wohnort: Marburg
|
|
|
|
Version: R2009b
|
|
|
|
|
|
|
Verfasst am: 27.11.2011, 08:03
Titel:
|
|
Das wurde dir doch das letzte mal alles schon erklärt:
Du hast bei den Doubles eine relative Unsicherheit von etwa 16 Nachkommastellen, rechnest du mit 10^24, so ist die 16. Nachkommastelle nunmal 10^8. Du machst jedes mal so, als ob das eine neue Information oder ein neuer Bug wäre, den du erstaunlicherweise rausgefunden hast. Deine Neugier aller Ehre, aber hierzu gibt es 100000 Google-Einträge, weil dies nicht MATLAB-spezifisch sondern double-spezifisch (alle Programmiersprachen) ist!
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.502
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 27.11.2011, 10:55
Titel:
|
|
Hallo,
VPA macht nur im Zusammenhang mit symbolischen Objekten wirklich Sinn.
Wenn du symbolisch rechnest, kommen allerdings ohnehin schon exakte Ergebnisse heraus:
Wenn du die letzten Berechnungen mit VPA durchführst, kommen zwar einmal minimal von 0 verschiedene Resultate heraus; das wird aber bei einer begrenzten Anzahl von Stellen immer so sein.
Auch dass bei Berechnungen mit begrenzter Stellenanzahl unterschiedliche Ergebnisse herauskommen können, selbst wenn die Ergebnisse bei beliebiger Genauigkeit eigentlich gleich sein sollten, sollte nach dem nächsten Beispiel nicht weiter überraschen:
Grüße,
Harald
|
|
|
|
Verschoben: 27.11.2011, 12:49 Uhr von Jan S
Von Bugs MATLAB nach Programmierung |
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 27.11.2011, 12:56
Titel: Re: eklatanter Logikfehler
|
|
| |
 |
 |
Hallo yukterez,
Ich habe das Thema von "Bugs MATLAB" nach "Programmierung" verschoben.
Matlab wird zunächst von hunderten Ingenieuren getestet, danach von tausenden Beta-Testern und schließlich von der gesamten Matlab-Community. Natürlich gibt es immer wieder Bugs in Matlab, da Bugs ein inherentes Phänomen in großen komplexen Systemen sind.
Wenn man aber als Nutzer über einen unerwarteten Effekt stolpert, sind in 99.9% der Fälle lediglich die Erwartungen falsch, die Berechnungen aber richtig. Man sollte also zunächst zurückhaltend sein, wenn man einen Bug vermutet. Wenn zudem FreeMat das gleiche Ergebnis liefert, spricht das sehr dafür, dass kein "eklatanter Logikfehler" vorliegt, sondern Deine Erwartungen nicht korrekt sind.
Die Effekte der begrenzten Rechengenauigkeit wurden Dir hier im Forum bereits eingehend erläutert. Um die Auswirkungen in ihrer Gesamtheit zu verstehen, ist zwar ein Studium der Numerik erforderlich. Aber die Grundzüge der IEEE-Arithmetik kannst Du auch bei WikiPedia nachlesen.
Gruß, Jan
|
|
|
|
| yukterez |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 32
|
|
|
|
Anmeldedatum: 19.11.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: R2012b
|
|
|
|
|
|
|
Verfasst am: 28.11.2011, 13:54
Titel: ok (:
|
|
Es stimmt schon, daher habe ich ja geschrieben
| Zitat: |
| Vielleicht liegt der eklatante Logikfehler aber auch in meiner Notation. |
Ich habe meine Variablen für solche Fälle auf sym umgestellt, mich hat aber bei der normalen Rechnung dennoch gewundert, dass ich bei
a - b - c - d
ein anderes ergebnis erhalte als bei
a - c - d - b
erhalte,
weil es nur eine subtraktion ist, aber wenn ihr sagt dass das ok ist bin ich beruhigt (: es stimmt schon, es wurde mir schon einmal erklärt, aber manchmal muss man 2x fragen (ein ganzes studium der numerik geht sich auf meine alten tage nicht mehr aus, aber mit eurer Hilfe hab ich´s trotzdem hingekriegt :)
|
|
|
|
| Harald |
Forum-Meister
|
|
Beiträge: 24.502
|
|
|
|
Anmeldedatum: 26.03.09
|
|
|
|
Wohnort: Nähe München
|
|
|
|
Version: ab 2017b
|
|
|
|
|
|
|
Verfasst am: 28.11.2011, 17:16
Titel:
|
|
Hallo,
ein einfacheres Beispiel, in dem ein ähnliches Problem auftritt, habe ich ja schon geschickt:
Eine etwas unwissenschaftliche, aber vielleicht zum Verständnis beitragende Erklärung:
Ein numerischer Fehler wird ja nun auch nicht eingeführt, um Nutzer zu ärgern, sondern ist ein auf den ersten Blick zufälliges Resultat minimalster Ungenauigkeiten und daher bei komplexeren Anwendungen oft nicht wirklich nachvollziehbar. Eben deswegen rechnet man mit 16 Stellen, obwohl sie ja eigentlich kaum jemand interessieren: damit es nichts ausmacht, wenn man "ein paar Stellen" an Genauigkeit verliert.
Trotz allem ist es natürlich eine gute Idee, bei der Implementierung der Algorithmen mitzudenken und beispielsweise die Subtraktion ähnlich großer Zahlen nach Möglichkeit zu vermeiden.
Grüße,
Harald
|
|
|
|
| yukterez |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 32
|
|
|
|
Anmeldedatum: 19.11.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: R2012b
|
|
|
|
|
|
|
Verfasst am: 28.11.2011, 22:11
Titel:
|
|
Ja, jetzt geht´s sogar mit dem eps (:
|
|
|
|
|
|
|
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
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2026
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
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.
|
|
