2017-02-23 4 views
1

Wegen des Gleitkommafehlers 2^(log (63)/log (2)) ist ungleich 63. Check die Ergebnisse unter:63 ist ungleich 2^(log (63)/log (2)) in Matlab

format long; 
>> 2^(log(63)/log(2)) 

ans = 

    63.000000000000014 

Und leider kann ich nicht VPA auf einem Logarithmus nach den Matlab-Dokumenten verwenden:

Im Gegensatz zu exakten symbolischen Werten doppelte Genauigkeit Werte von Natur aus enthalten Rundungsfehler . Wenn Sie vpa auf einem -Eingang mit doppelter Genauigkeit aufrufen, kann vpa die verlorene Genauigkeit nicht wiederherstellen, obwohl sie mehr Ziffern als der doppelte Genauigkeitswert zurückgibt. Vpa kann jedoch die Genauigkeit von Ausdrücken der Form p/q, pπ/q, (p/q) 1/2, 2q und 10q erkennen und wiederherstellen, wobei p und q ganzzahlige Ganzzahlen sind.

Also, wie kann ich dieses Problem lösen? Ich habe sehr große Zahlen wie 2^200 und ich bekomme sehr große Fehler.

Edit: Ich frage nicht, warum es passiert. Ich frage, wie diese Arbeit als 100% genau funktioniert, also ist dies kein Duplikat.

Die beste Lösung bisher:

Unfortunatelly die Lösung, die von @Sardar_Usama vorgeschlagen wird, nicht immer wie vorgesehen funktioniert. Schauen Sie sich die Ergebnisse unter:

>> sym(2^(log(2251799813685247)/log(2))) 

ans = 

2251799813685259 

Auf der anderen Seite

>> 2^(log(vpa(2251799813685247))/log(vpa(2))) 

ans = 

2.2517998136852470000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0*10^0*10^15 

ist viel viel mehr näher an 2251799813685247 = 2^51. Es ist ein Fehler um ~ 9.491 * 10^-494, was dies die beste Lösung bisher macht, aber es gibt immer noch einen Fehler.

+1

Was ist das spezifisches Problem? Wie kann man Gleitkommaungenauigkeiten im Allgemeinen vermeiden? Oder wie kann man 2^(log (k)/log (2)) ohne Ungenauigkeit auswerten? –

+0

Was ist daran falsch, nicht genau 63 zu sein? Es ist nur ein '2 * eps (63)' Unterschied. Im Allgemeinen sollten numerische Berechnungen nicht auf genauen Werten beruhen. – horchler

+0

@horcler Es wird deutlich höher, wenn Sie mit großen Zahlen arbeiten. – Kitiara

Antwort

4

Wenn Sie nicht round oder vpa verwenden können, gibt es einen langsamerer Weg, dies zu tun, wenn Sie Symbolic Math Toolbox haben, von creating symbolic numbers. dh

a = sym(2^(log(63)/log(2))) 

Dies wird Ihnen sym Klasse 63, die Sie später double mit umwandeln kann:

double(a) 

Dies ist, was Sie bekommen:

>> format long 
>> a = sym(2^(log(63)/log(2))) 

a = 

63 

>> double(a) 

ans = 

    63 
+0

Leider funktioniert das nicht immer wie vorgesehen. Überprüfen Sie dies 'sym (2^(log (2251799813685247)/log (2)))' = '2251799813685259'. (Andererseits ist 2251799813685247 2^51) Andererseits ist "2^(log (vpa (2251799813685247))/log (vpa (2)))" viel viel näher zu "2251799813685247". Es ist ein Fehler um ~ 2.252 * 10^-192', was für meine Berechnungen keine Probleme verursacht, aber es gibt immer noch einen Fehler. – Kitiara

+0

@Kitiara Es gibt nur zwei Optionen: * symbolische Arithmetik * und * numerische Arithmetik * (einschließlich * variabler Genauigkeit * und * doppelter Genauigkeit *). Es gibt * keine andere Möglichkeit. Eine 100% ige Genauigkeit ist nicht immer möglich. Lesen Sie diesen Artikel: https://www.mathworks.com/help/symbolic/recognize-and-avoid-roundoff-errors.html –

+0

Okay, danke. – Kitiara

Verwandte Themen