WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Mein MATLAB Forum - goMatlab.de

Mein MATLAB Forum

 
Gast > Registrieren       Autologin?   

Partner:




Forum
      Option
[Erweitert]
  • Diese Seite per Mail weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Problem mit Euler´s Formel

 

yukterez
Forum-Anfänger

Forum-Anfänger


Beiträge: 32
Anmeldedatum: 19.11.11
Wohnort: ---
Version: R2012b
     Beitrag Verfasst am: 19.11.2011, 05:02     Titel: Problem mit Euler´s Formel
  Antworten mit Zitat      
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 ?

Screenshot des Problems:
http://666kb.com/i/bysflhs9et7whlda9.png
Private Nachricht senden Benutzer-Profile anzeigen


Harald
Forum-Meister

Forum-Meister


Beiträge: 24.449
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 19.11.2011, 11:15     Titel:
  Antworten mit Zitat      
Hallo,

das hat mit der begrenzten Rechengenauigkeit eines Computers zu tun. Selbst
Code:

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:
Code:


Generell ist man jedoch mit Ergebnissen zufrieden, die auf 12 Stellen oder so genau sind.

Grüße,
Harald
Private Nachricht senden Benutzer-Profile anzeigen
 
eupho
Forum-Meister

Forum-Meister


Beiträge: 777
Anmeldedatum: 07.01.09
Wohnort: Marburg
Version: R2009b
     Beitrag Verfasst am: 19.11.2011, 11:54     Titel:
  Antworten mit Zitat      
Der zweite Teil ist der imaginär-Teil, wieso sollte der sich durch +1/+0 ändern?! --> Alles korrekt.
Private Nachricht senden Benutzer-Profile anzeigen
 
yukterez
Themenstarter

Forum-Anfänger

Forum-Anfänger


Beiträge: 32
Anmeldedatum: 19.11.11
Wohnort: ---
Version: R2012b
     Beitrag Verfasst am: 19.11.2011, 18:15     Titel:
  Antworten mit Zitat      
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.
Private Nachricht senden Benutzer-Profile anzeigen
 
eupho
Forum-Meister

Forum-Meister


Beiträge: 777
Anmeldedatum: 07.01.09
Wohnort: Marburg
Version: R2009b
     Beitrag Verfasst am: 19.11.2011, 19:32     Titel:
  Antworten mit Zitat      
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?!
Private Nachricht senden Benutzer-Profile anzeigen
 
Jan S
Moderator

Moderator


Beiträge: 11.057
Anmeldedatum: 08.07.10
Wohnort: Heidelberg
Version: 2009a, 2016b
     Beitrag Verfasst am: 19.11.2011, 19:33     Titel:
  Antworten mit Zitat      
Hallo yukterez,

Siehe z.B.:
Code:

Über die Rechengenauigkeit bei Doubles findest Du sehr viele Artikel im Netz.

Gruß, Jan
Private Nachricht senden Benutzer-Profile anzeigen
 
yukterez
Themenstarter

Forum-Anfänger

Forum-Anfänger


Beiträge: 32
Anmeldedatum: 19.11.11
Wohnort: ---
Version: R2012b
     Beitrag Verfasst am: 19.11.2011, 22:38     Titel:
  Antworten mit Zitat      
eupho hat Folgendes geschrieben:
1) Wie kommst du denn jetzt auf sym? Das ist nochmal eine komplett andere Baustelle (symbolisch).

Im zweiten Posting hier im Thread wurde mir diese Schreibweise empfohlen, sie liefert ja auch das erwartete Ergebnis.

Harald hat Folgendes geschrieben:
exp(sym(pi*i))

Dann liefert Matlab das gleiche wie Wolfram: http://666kb.com/i/bysh4gcaitf1g33b5.png - also das erwartete Ergebnis. So weit so gut.

eupho hat Folgendes geschrieben:
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)
Private Nachricht senden Benutzer-Profile anzeigen
 
Jan S
Moderator

Moderator


Beiträge: 11.057
Anmeldedatum: 08.07.10
Wohnort: Heidelberg
Version: 2009a, 2016b
     Beitrag Verfasst am: 19.11.2011, 23:38     Titel:
  Antworten mit Zitat      
Hallo yukterez,

Mit "sym" ist es eine vollkommen andere Fragestellung, als wenn Du numerisch rechnest.

Rundungsfehler treten beim Rechnen mit numerischen Variablen immer auf. Z.B:
Code:
sin(2 * pi)   % >> -2.4493e-016
v = 0:0.1:1;
v(4)-0.3     % >> 5.5511e-017

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.

Gruß, Jan
Private Nachricht senden Benutzer-Profile anzeigen
 
yukterez
Themenstarter

Forum-Anfänger

Forum-Anfänger


Beiträge: 32
Anmeldedatum: 19.11.11
Wohnort: ---
Version: R2012b
     Beitrag Verfasst am: 20.11.2011, 19:41     Titel:
  Antworten mit Zitat      
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 ?

http://666kb.com/i/byu2zvzrg1ncmb2k0.png
und
http://666kb.com/i/byu39r14zw4mjxfhs.png

(man wird sich fragen wozu solche Zahlen, aber die Berechnung der möglichen Formen einer Schneeflock zB erfordern solche Grössenordnungen)
Private Nachricht senden Benutzer-Profile anzeigen
 
Harald
Forum-Meister

Forum-Meister


Beiträge: 24.449
Anmeldedatum: 26.03.09
Wohnort: Nähe München
Version: ab 2017b
     Beitrag Verfasst am: 20.11.2011, 20:48     Titel:
  Antworten mit Zitat      
Hallo,

es geht vieles. Ob es sinnvoll oder für praktische Anwendungen relevant ist, ist die andere Frage:

Code:
a = sym(6)
vpa(a^a^a^a^a^a, 10)
vpa(a^a^a^a^a^a^a^a^a^a^a^a, 10)


Übrigens sind wir da jetzt bei verschiedenen Konzepten - das eine ist Rechengenauigkeit, das andere ist der mögliche Wertebereich eines Double.

Grüße,
Harald
Private Nachricht senden Benutzer-Profile anzeigen
 
eupho
Forum-Meister

Forum-Meister


Beiträge: 777
Anmeldedatum: 07.01.09
Wohnort: Marburg
Version: R2009b
     Beitrag Verfasst am: 20.11.2011, 21:56     Titel:
  Antworten mit Zitat      
yukterez hat Folgendes geschrieben:
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!
Private Nachricht senden Benutzer-Profile anzeigen
 
Jan S
Moderator

Moderator


Beiträge: 11.057
Anmeldedatum: 08.07.10
Wohnort: Heidelberg
Version: 2009a, 2016b
     Beitrag Verfasst am: 20.11.2011, 23:59     Titel:
  Antworten mit Zitat      
Hallo yukterez,

"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.

Gruß, Jan
Private Nachricht senden Benutzer-Profile anzeigen
 
yukterez
Themenstarter

Forum-Anfänger

Forum-Anfänger


Beiträge: 32
Anmeldedatum: 19.11.11
Wohnort: ---
Version: R2012b
     Beitrag Verfasst am: 21.11.2011, 04:27     Titel:
  Antworten mit Zitat      
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 :)
Private Nachricht senden Benutzer-Profile anzeigen
 
Neues Thema eröffnen Neue Antwort erstellen



Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:

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 | goMatlab RSS Button RSS

Hosted by:


Copyright © 2007 - 2024 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.