Interner aufbau von Datentypen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Interner aufbau von Datentypen

    guten morgen zusammen,

    ich würde gerne den internen aufbau primitiver datentypen genauer verstehen. hierzu habe ich mir mal den wiki eintrag über die IEEE754 zu gemüte geführt. leider muss ich sagen, dass meine mathematischen kenntnisse etwas eingestaubt sind ;)
    ich würde mich freun wenn mir jemand der sich vieleicht mal etwas genauer mit dem thema beschäfftigt hat, mir das ganze ne bisschen näher bringen könnte.

    mir geht es ausschließlich um den internen aufbau. also sachen wie den wertebereich und der gleichen habe ich dann doch verstanden^^

    hier der link zu wiki IEEE754

    thx, truespin

  • hallo,

    das freud mich das du dir soviel arbeit machen willst! aber mach dir auf keinen fall stress wegen mir^^
    so wichtig ist es nicht, mich würde das nur interessieren... vieleicht komm ich bei genauerem suchen bzw. richtigem durcharbeiten des wiki eintrags doch dahinter ;)

    aber wenn du zufällig die unterlagen auf nen filserver hättest oder so... würde ich sicher nicht nein sagen ;)


    thx, truespin

  • guten morgen,

    mich würde z.B. interessieren, warum beim hochzählen und ausgeben einer double variable unterschiedlich viele stellen ausgegeben werden.

    ich zähle eine double variable hoch (immer +0.01) und gebe das ganze auf der console aus. mein ergebnis sieht wie folgt aus:

    Double: 2,27
    Double: 2,28
    Double: 2,29
    Double: 2,29999999999999
    Double: 2,30999999999999
    Double: 2,31999999999999
    Double: 2,32999999999999
    Double: 2,33999999999999
    Double: 2,34999999999999
    Double: 2,35999999999999
    Double: 2,36999999999999
    Double: 2,37999999999999

    warum wird die vierte zeile ausgegeben? warum werden ab 2,29 14 nachkommastellen ausgegeben?


    thx, truespin

  • Naja, das liegt einfach daran, dass man 0.01 als double nicht exakt darstellen kann.
    Man kann sich ja mal anschauen, wie die 0.01 als bitmuster abgespeichert wird.
    Ich mach das einfach mal in Java

    Quellcode

    1. long x = Double.doubleToLongBits(0.01);
    2. System.out.println(Long.toBinaryString(x));

    dabei kommt dann sowas raus:

    Quellcode

    1. 11111110000100011110101110000101000111101011100001010001111011

    jetzt muss man erstmal aufpassen, da Java hier die führenden Nullen weglässt, also vorne noch 2 Nullen dazu, damit man auf 64bit kommt
    0011111110000100011110101110000101000111101011100001010001111011
    jetzt zerlegen wir das in die einzelnen Bestandteile:
    Vorzeichen (1 Bit): 0
    Exponent (11 Bits): 01111111000
    Mantisse (52Bits): 0100011110101110000101000111101011100001010001111011
    bei der Mantisse wird implizit noch ein "1." davorgehängt:
    Mantisse : 1.0100011110101110000101000111101011100001010001111011

    Und dann rechnen wir mal aus, was da rauskommt:
    Vorzeichen 0 -> positive Zahl
    Exponent: 1016. Der Bias ist für Double 1023 also ergibt das:
    Exponent: -7
    Mantisse: 1,28000000000000002664535259100376

    Und wenn man jetzt die Dezimaldarstellung anschaut ergibt das folgendes:
    1,28000000000000002664535259100376 * 2^-7 = 0,010000000000000000208166817117211

    Man erkennt: 0.01 ist nicht wirklich 0.01. Das fällt nur nicht auf, wenn man sich die Zahl anzeigen lässt, oder wie du ein paarmal damit rechnet, weil die ungenauigkeiten erst so weit hinter dem Komma auftreten, dass sie das Programm bei der Dezimaldarstellung einfach hinten abschneidet (Da ja bekannt ist, dass ab einer gewissen Stelle hinter dem Komma eh nurnoch Mist steht).
    Wenn man jetzt aber (mehrmals) damit rechnet, addiert sich der Fehler auf.
    Ich hab einfach mal zu 0.01 immer wieder 0.01 hinzuaddiert:

    Quellcode

    1. 0.01
    2. 0.02
    3. 0.03
    4. 0.04
    5. 0.05
    6. 0.060000000000000005

    Der Fehler hat sich aufaddiert und zeigt dadurch ein "falsches" Ergebnis.

    Das gleiche geht natürlich auch in die andere Richtung, dass der von ner Double repräsentierte Wert kleiner ist, als er sein sollte. Das wird bis zu einem gewissen Grad auch richtig gerundet, kann aber dann irgendwann zu diesen "2,29999999999999" Ergebnissen führen.

    So, hoffe das war einigermaßen verständlich.