Softwareentwickler MATLAB/Simulink (w/m) Erarbeitung von Lösungen im Bereich der Schnittstelle zum Simulink-Modell und der Benutzeroberfläche von TargetLinkdSPACE GmbH - Paderborn
Verfasst am: 19.11.2011, 05:02
Titel: Problem mit Euler´s Formel
Was hat es zu bedeuten, dass ich für
e^(i*pi) = -1, +1.2246e-16*i
und für
e^(i*pi)+1 = 0, +1.2246e-16*i
rausbekomme ? Ist das ein Bug oder Rad/Deg ? Sowohl mit als auch ohne +1 kommt in der zweiten Spalte das selbe Ergebnis, was mache ich aus diesem zweiten Ergebnis ?
ist nicht genau 0, da pi auf dem Rechner nicht exakt dargestellt werden kann und damit der Sinus einer Zahl genommen wird, die genau genommen leicht neben pi liegt.
Wenn du exakte Ergebnisse benötigst, kannst du diese mit der Symbolic Math Toolbox und dem SYM-Befehl bekommen:
Ok, also ist nun die Rechenungenauigkeit genau 1.224646799147353e-16*i
oder ist das der echte Imaginärteil von e^(i*pi) ? Eine Rechenungenauigkeit kann ja nicht auf so viele Kommastellen genau sein, ich versteh´s nicht ganz /:
Bei exp(sym(pi*i)) kriege ich jedenfalls nur -1 raus, ohne diese zweite Zahl.
1) Wie kommst du denn jetzt auf sym? Das ist nochmal eine komplett andere Baustelle (symbolisch).
2) Streng genommen ist es keine Rechenungenauigkeit, sondern ein Rundungsfehler, weil Float-Zahlen (wie double hier) nicht beliebige Zahlen darstellen können.
3) Ja, es ist der echte Imaginärteil. Gibt es auch einen Unenchten?!
2) Streng genommen ist es keine Rechenungenauigkeit, sondern ein Rundungsfehler, weil Float-Zahlen (wie double hier) nicht beliebige Zahlen darstellen können.
3) Ja, es ist der echte Imaginärteil. Gibt es auch einen Unenchten?!
Unecht in dem Sinne das es nur eine Rechen- oder Rundungsungenauigkeit ist !
Also es ist sowohl ein Rundungsfehler als auch der echte Imaginärteil ? Wie geht das zusammen ?
(sorry für die vielleicht dummen Fragen, aber für mich klingt das widersprüchlich)
Die Ergebnisse weichen von 0.0 ab, da die internen Berechnungen Rundungsfehler aufweisen. Matlab kann z.B. Pi ja auch nicht mit den benötigten unendlichen vielen Stellen speichern.
Dies ist kein Fehler in der Berechnung, da das Ergebnis dem Erwartbaren entspricht.
Bei einer symbolischen Berechnung weiß Matlab aber, dass "sin(2*pi)" exakt Null ist. Dafür kann man viele Aufgaben aber nicht geschlossen lösen und eine symbolische Lösung ist auch nicht ubedingt nützlich: Wenn man z.B. ein Doppelpendel simuliert, ist das zwar symbolisch lösbar. Das Ergebnis hat aber so viele trigonometrische Funktionen, dass es für eine Visualisierung schneller ist, die Differentialgleichungen numerisch per ODE45 lösen zu lassen.
Der ("echte") Imaginärteil von "exp(pi*i)" ist Null. Der numerisch ermittelte ist 1.2246e-016, also fast Null. Ein numerisches Programm darf niemals auf die exakte Gleichheit zweier Doubles testen, sondern muss immer gewisse Toleranzen berücksichtigen.
Ein anderes einfaches Beispiel:
Code:
a = 1.0e17 + 1.0 - 1.0e17 % 0
Mit einer symbolischen Rechnung ist das Unsinn. Bei numerischer Rechnung ist das dagegen logisch, weil 1.0e17 die mögliche Anzahl von Stellen bereits ausgeschöpft hat und das addieren einer 1 den Wert nicht ändert. Intern werden die DOUBLEs nunmal mit 16 Ziffern gespeichert. Eine 17.te fällt dann einfach weg.
Das ist auch sinnvoll, da man die Numerik im Allgemeinen nicht zum Selbstzweck betreibt, sondern um Probleme aus der Physik, Chemie, Biologie, Astronomie etc. zu lösen. Messungen der Inputs bzw. Anfangswerte sind aber niemals mit 16 Stellen Genauigkeit bekannt. Rechnungen, die mehr als 16 Stellen für Fließkommazahlen benötigen, sind praktisch immer ein Hinweis auf eine Fehlkonzeption.
Ich verstehe, also kann ich bei Matlab alles hinter der 16ten Kommastelle ignorieren, links steht immer der Realteil, rechts der Imaginärteil, und alles unter 10^16 = praktisch 0.
Das reicht freilich für die meisten praktischen Aufgaben, aber solche Sachen wie Pi auf die 100ste oder 1000ste Stelle berechnen, oder die Eulersche Zahl (nur um ein Beispiel zu nennen), das muss ich dann mit dem kleinen Freeware Programm Smart Math Calculator machen (der auf 100 bis max. 1000 Digits präzise ist, was ich mit pi(100Digits)/pi(98digits) und das selbe Spiel mit e überprüfen konnte, oder kann ich das auch im Matlab irgendwie einstellen ? Wenn´s nicht geht ist es auch nicht schlimm da es ja noch den kleinen SMC gibt, aber geht es wirklich nicht ?
Ich verstehe, also kann ich bei Matlab alles hinter der 16ten Kommastelle ignorieren, ...
Das hat übrigens nichts mit MATLAB zu tun, sondern generell mit der Darstellung als Gleitkommazahl (Stichworte double, float), viele Informationen hierzu findest du bei Google! Double ist der numerische Standard in allen Programmiersprachen!
"Alles nach der 16.ten Stelle wird ignoriert" ist nicht korrekt:
Code:
2.0e-34 + 3.0e-34
>> 5e-034
Es geht also um die relative Genauigkeit, nicht um die absolute.
Zitat:
(man wird sich fragen wozu solche Zahlen, aber die Berechnung der möglichen Formen einer Schneeflock zB erfordern solche Grössenordnungen)
Die Form realer Schneeflocken hängt von der Temperatur ab, bei der sich die Wassermoleküle anlagern. Die Temperatur läßt sich nicht auf 16 Stellen genau bestimmen. Ebenso nicht der Ort, an dem sie sich anlagern. Die Quantenmechanik setzt da eine Grenze. Für die Simulation eines physikalischen Vorgangs sind 16 Stellen also (eigentlich) ausreichend.
Wenn man aber Probleme aus der Kombinatorik bearbeitet, sind 16 Stellen oft albern wenig. Man muss nur mal eben 32 Karten mischen oder ein paar große Primzahlen für ein Verschlüsselungsverfahren benötigen. Dann sind DOUBLEs nicht geeignet. Wie bereits erwähnt wird in Matlab dafür SYM und VPA verwendet.
Danke, mit sym und vpa ist mir sehr geholfen (ich habe vorher ein wenig mit freemat geübt, aber da hatte ich die befehle nicht :)
Options and Permissions
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