Genauigkeit/Precision ?? (1e-017 = 0 "setzten")
-
r00t schrieb:
Denn - hätte ich vll vorher sagen sollen - muss auch 0 herauskommen und nicht etwa 0 (denke ich zumindest). Sind halt Berechnungen vorher schon zu ungenau/gerundet/oder sowas gewesen...!?
Die Frage versteh ich jetzt nicht genau, aber vielleicht hilft das weiter:
double d03 = 0.3; //ist nicht genau 0.3 double d12 = 1.2; //ist nicht genau 1.2 double d15 = 1.5; //auch nicht genau... double summe = d03+d12; //natürlich nicht 1.5 if (summe == d15) //greift nicht unbedingt.
-
pumuckl schrieb:
double d15 = 1.5; //auch nicht genau...Doch, die schon
-
Bashar schrieb:
Doch, die schon
Gnarf. Ersetze es durch was entsprechend (un-)passendes.
-
Der Fragesteller möchte 30 Nachkommastellen, also mindestens 30 signifikate Stellen einer Gleitkommavariablen. Das passt derzeit in keinen vorbereiteten
Datentyp hinein. Dafür wären andere aufwendigere Massnahmen erforderlich.
-
berniebutt schrieb:
Der Fragesteller möchte 30 Nachkommastellen, also mindestens 30 signifikate Stellen einer Gleitkommavariablen. Das passt derzeit in keinen vorbereiteten
Datentyp hinein. Dafür wären andere aufwendigere Massnahmen erforderlich.Nun, es gibt quadruple precision libraries
. Ich behaupte aber einfach mal, dass der Fragesteller die Frage nach der nötigen Genauigkeit nicht qualifiziert beantworten kann und seine Bedürfnisse weit überschätzt.
-
berniebutt schrieb:
Der Fragesteller möchte 30 Nachkommastellen, also mindestens 30 signifikate Stellen einer Gleitkommavariablen.
Nö. Er hat nur Pi mit 30 Nachkommastellen angegeben. Die Info ist aber garnicht relevant. Sein Problem ist, dass er bei Rechnungen mit double keine exakten Werte bekommt, was einfach das übliche Genauigkeitsproblem mit Fließkommazahlen ist.
-
Ich häng mich mal hier ein, denn ich hab da mal 'ne Frage:
#include <iostream> #include <limits> #include <iomanip> int main() { std::cout<<std::fixed<<std::numeric_limits<long double>::max()<<"\n\n\n" <<std::numeric_limits<long double>::epsilon()<<std::endl; }1. Wieso ist das zweite Ergebniss Null ?
2. Müsste nicht das Verhältniss gelten: größe ersten Wertes geteilt durch 1 ist der Epsilon ?
Also Anzahl möglicher Nachkommastellen gleich Anzahl möglicher 'Vorkommastellen' (ich weiß da gibt es einen Begriff, fällt mir leider grad nicht ein ?
-
1. Weil das epsilon so klein ist, dass du es nicht mit der von dir fixierten Stellenzahl ausgeben kannst, ohne es auf 0 zu runden.
2. Wolltest du "1 geteilt durch" schreiben? Und selbst dann nicht. Du hast den Exponenten vergessen.edit: Schreib doch mal statt fixed scientific (oder lass es weg, da es sowieso Standard ist), dann sollte das klarer werden.
-
SeppJ schrieb:
Weil das epsilon so klein ist, dass du es nicht mit der von dir fixierten Stellenzahl ausgeben kannst, ohne es auf 0 zu runden.
Schafft dieser Datentyp dann also 30 Nachkommastellen ?
Ich würds mit ja ausrechnen, leider weiß ich nicht wie...
Und ja, 1 geteilt durch, das wollt ich schreiben.
-
Hacker schrieb:
Schafft dieser Datentyp dann also 30 Nachkommastellen ?
Wie kommst du auf 30? Kann sein, dass das bei dir so ist, würde mich sehr aber wundern. Und das epsilon hat auch nicht so wirklich was damit zu tun. Beziehungsweise schon, aber nicht so, wie du vermutlich denkst.
-
SeppJ schrieb:
Wie kommst du auf 30?
Wurde im Thread angesprochen.
-
Hacker schrieb:
SeppJ schrieb:
Wie kommst du auf 30?
Wurde im Thread angesprochen.
Es ging darum, dass die Genauigkeit üblicherweise nicht 30 Stellen ist...
-
Eben ?
Da wollt ich wissen ob ein long double diese genauigkeit schafft ...
-
Hacker schrieb:
Eben ?
Da wollt ich wissen ob ein long double diese genauigkeit schafft ...In der Regel nicht, wie du aus dem Wert für das epsilon ablesen kannst, wenn du fähig wärst, es dir anzeigen zu lassen. Dass hier bei dir nichts erscheint, liegt nicht da dran, dass der Wert an sich zu klein ist für die Anzeige, sondern dass du nicht genau weißt, was du da mit den Streammanipulatoren getan hast.
-
Ahh, sry. Ich hab setprecision vergessen. Jetz seh ich's.
Edit: Nein, immer noch falsch. Es scheint, als ob long double (edit) ca. 80 Nachkommastellen schafft.
-
Hacker schrieb:
Ahh, sry. Ich hab setprecision vergessen. Jetz seh ich's.
Edit: Nein, immer noch falsch. Es scheint, als ob long double 63 Nachkommastellen schafft.
Wenn du nicht an einem Spezialrechner sitzt, dann ist auch das Unsinn. Wie kommst du auf die Werte?
-
Nein, vergiss es. Durch schwachsinnige Methoden (precision auf 100 und dann epsilon angeguckt).
-
-
krümelkacker schrieb:
Äm es ging mir um die Anzahl möglicher Nachkommastellen.
Kannst du mir erklären, inwiefern mich das weiterbringt ...?
Außerdem hab ich genau dasselbe schon aussprobiert.
-
Antworten auf sinnfreie Fragen bringen Dich auch nicht weiter. Die Anzahl der darstellbaren Nachkommastellen hängt bei Fließkommazahlen vom Betrag der Zahl ab -- betragsmäßig große Zahlen -> wenig bis gar keine Nachkommastellen, betragsmäßig kleine Zahl -> viele Nachkommastellen. Interessant ist hier die Anzahl der signifikanten Stellen; denn wo das Komma bei einer Fließkommazahl steht, ist fast egal. Verwechselst Du da vielleicht Fließkommazahl mit Fixpunktzahl?
