Warum werden große Zahlen falsch dargestellt ?



  • Hallo,

    da mein Problem eher allgemein ist, habe ich sie bewusst in dieses Forum gestellt.

    Wenn ich z.B große Zahlen von z.B long double in der Konsole anzeigen lasse, kommen dabei folgende Kombinationen heraus:

    3,4E-4932
    

    Aber nicht nur da, sondern in diversen Datentyp - Tabellen wird von dieser Darstellungsweise Gebrauch gemacht ! Was hat das genau zu bedeuten ? Was haben die Buchstaben darin verloren ? Und wie kann ich große Zahlen normal anzeigen lassen ?

    Danke Euch für die Hilfe,

    mikey.



  • Du musst das Ausgabeformat für die floats deinen Wünschen entsprechend einstellen.
    Wie das geht steht normalerweise in deinem C++ Buch, ansonsten findest du hier eine Erklärung.



  • Danke, davon habe ich bisher garnichts gewusst ! 😕

    Aufjedenfall funktioniert's jetzt.

    Grüße, mikey.



  • Hallo

    Und 3,4E-4932 ist die korrekte wissenschaftliche und standardisierte Anzeige von Fließkommazahlen. Es bedeutet 3,4 hoch -4932. Das E steht für Exponent.

    bis bald
    akari



  • akari schrieb:

    Es bedeutet 3,4 hoch -4932.

    Falsch. 3,4 mal 10 hoch -4932.


  • Mod

    Das ist im Übrigen eine sehr kleine Zahl 😉



  • So klein, dass man sie als 0 behandeln kann. Wenn du diese Zahl zu 1 dazuzählst kommt 1 raus. D.h. du kannst mit dieser Zahl nicht mehr vernünftig rechnen, zumindest was Addieren und Subtrahieren betrifft. Deswegen sind Gleitpunktzahlen etwas schwierig handzuhaben, auch long double.



  • Ne, ich fands am Anfang nur recht verwirrend ... Habs aber mit setprecision gelöst, wobei ich mich noch einbisschen um die Funktionsweise dieser Funktion schlau machen muss ... Wenn dann möchte ich schon wissen, wie sie arbeitet 🙂



  • Die gleitkomma arithmetik hab ich auch nicht verstanden. Gehört das aber auch nicht eher ins rund um die programmierung ?

    Das problem ist das ja gleitkommazahlen überabzählbar sind... denn schon von 0 - 1 sind es unendlich viele. Und egal wie sehr man sich anstrengt eine besonders kleine zu finden, es gibt immer eine noch kleinere. Also musste man sich bei der darstellung was einfallen lassen. Somit werden die zahlen besonders codiert.

    Irgendwie war das was damit das sie durch einen bestimmten wert geteilt werden und somit normirt..... dieser faktor wird irgendwo mit gespeichert.... dann kommen da noch andere dinge dazu... müsst ich mir nochmal genau anschauen, interessiert auch nicht. Es sollte nur gesagt werden das gleitkommazahlen in der berechnung sehr ungenau sind eben weil da irgendwo intern zu gewissen dingen konvertiert wird. Ausserdem sind gleitkommaoperationen ziemlich langsam.



  • Fedaykin schrieb:

    Das problem ist das ja gleitkommazahlen überabzählbar sind...

    Eben gerade nicht. Reelle Zahlen sind überabzählbar unendlich. Aber selbst wenn sie abzählbar unendlich wären, gäbe es zumindest ähnliche Probleme, weil der Wertebereich einer Computer-Zahl (sei sie ganzzahlig, Festkomma- oder Fließkommazahl) nunmal endlich ist (es sei denn, man verwendet eine BigNum-Implementierung).



  • Hin oder her, ich muss mit Gleitkommazahlen rechnen. Die Genauigkeit soll recht hoch sein, weswegen ich double genommen hab, und die Präzision einbisschen hochgestellt habe.



  • Dir ist aber schon klar, dass Dein setprecision nicht die Rechengenauigkeit erhöht hat, sondern nur eine weniger genaue Ausgabe eingestellt hat? Dadurch werden dann die Zahlen vor der Ausgabe auf eine feste Anzahl stellen gerundet und die Zahlen sehen oft ein bißchen netter aus. double (oder gar long double) ist schon gut für die Präzision, setprecision hat damit aber nichts zu tun.



  • Natürlich ist mir das klar. Ich bin nochdazu nicht gerade ein Mathefreak, dementsprechend habe ich auch die Zeichen im Ergebnis nicht deuten können ...

    Ehrlich gesagt sind mir Exponenten im Rechenergebnis wenig akzeptabel, weswegen ich auch eine gewisse Ungenauigkeit eingehe, was wirklich kein Weltuntergang ist solange sich relevante Rundungen mindestens noch im 10-6 Bereich befinden.


Log in to reply