12 != 12 ?? Datentypen? - Seite 2

HPR1974 · 24.02.2009, 20:50

Weil die Genauigkeit des Datentyp float genau das hergibt, die Ungenauigkeit beginnt im Beispiel tatsächlich an der 15. Nachkommastelle. Sowas kommt irgendwann jedem mal in die Quere...

echo number_format(64.8/5.4,14);
12.00000000000000
echo number_format(64.8/5.4,15);
11.999999999999998

dav1d · 24.02.2009, 20:53

Danke für die schnelle Hilfe!
Gut zu wissen.

nikosch · 24.02.2009, 20:53

[MOD: verschoben]

papalangi_44 · 26.02.2009, 02:16

Gleitkommazahlen werden intern mit einen Exponenten und einer Mantisse
gespeichet. Die Anzahl der Bits (Signifikanz) der Mantisse ist davon abhängig, ob float oder double gerechnt wird.
0,4 ist als Gleitkommazahl nicht exakt darstellbar, da es keine Potenz von 2 ist.
Deshalb wurde früher auch mit COBOL oder in Assembler programmiert, da gab es Dezimalarithmetik.

PHP-Code:

  Beispiel:
Bei einer 32 Bit Gleitkommazahl werden 8 Bits für den Exponenten und
24 Bits für die Mantisse verwendet.
Um die Mantisse mal manuell zu berechnen kann man die 
Multiplikationsmethode verwenden, 
da ich nicht sooft multiplizieren will bereche ich das  Oktal und 
überführe das dann in das Binärsystem.

bei der Multiplikationsmethode wird die Zahl mit der Basis des neuen 
Zahlensystens multipliziert.
Das gilt aber nur für den Nachkommateil, Stellen vor dem Komma werden mit
Divisionsrestmethodeumgewandelt. 

Also: 

     0,4 * 8
     3,2 * 8     die 3 ist die erste Ziffer der Mantisse  es wird nur mit dem
     1,6 * 8     mit dem  Teil hinter dem Komma  0,2 *8 weitergerechnet.
     4,8 * 8
     6,4 * 8      Hier kommt das Problem, wir haben eine Periode, da wieder
     3,2              nur  mit 0,4 weiter multiplizert wird.

    unsere Mantisse wird somit zu :
      3   1   4    6   3   1   4   6   3   1   4    6   ...    (oktal)
    011 001 100 110  011 001 100 110  011 001 100  110    (binär)
                                  110  011 001 100  110 Das geht in den Bit/Mülleimer

    Die Mantisse wird dann normalisiert, d.h. führende nullen werden entfernt
    und der Exponent ermittelt (schenke ich mir hier, Stichwort Bias Exponent).
    Egal wieviel Stellen die Mantisse hat, es muss es muss abgeschnitten 
    werden, dadurch ist die Zahl ungenau.

Warum werden dann machmal aber trotzdem die Zahlen genau
ausgegeben?
Das liegt daran, daß die Ausgaberoutinen schlichtweg manchmal runden,
wenn weniger Stellen ausgegeben werden.

Wieviel Stellen sind genau?
Das lässt sich leicht aus der Bitanzahl der Mantisse überschlagen.
Für jede Dezimalstelle werden ca 3,3 Bits benötigt.
D.H. bei einer 32 Bit Gleitkommazahl 123456789,4 liegt die
Ungenauigkeit bereits in den Vorkommastellen.

Man sollte also nie Gleitkommazahlen auf == vergleichen.
if(abs($a - $b) < 0.000005) { print 'fast gleich'; }
wäre eine Möglichkeit. Dabei ist darauf zu achten, das der Schwellwert
nicht ausserhalb der möglichen Genauigkeit der Gleikommazahl liegt.

Ich hoffe , dieser kleine Exkurs in die Grundlagen der Datenverarbeitung
bringt dir das Verständnis für das Problem.
Tröste Dich, Du bist nicht allein in dieser Richtung ahnungslos.

Gruß Papalangi_44 der das vor ca. 40 Jahren gelernt hat.

Wenn ich mal Zeit habe, werden ich mal ne Demo dafür programmieren.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Datentypen: varchar(65.535) vs. text	coding007	Datenbanken	18	07.07.2010 17:25
Frage zu Datentypen und Indizes	tayke	Datenbanken	2	29.10.2006 04:00
[MSSQL + PHP] Konflikt zwischen Datentypen / Probleme bei IN	winfo_cologne	PHP Tipps 2006	3	29.03.2006 14:05
Datentypen in MySQL		Datenbanken	12	02.02.2006 15:34
Datentypen und deren Größe		Datenbanken	5	29.11.2005 08:38
[erledigt]SQL: Datentypen in Kriterienausdruck unverträglich		PHP Tipps 2005-2	2	11.07.2005 09:51
[Erledigt] Select Statement - Order by Problem mit Datentypen		Datenbanken	6	03.06.2005 16:02
Dokumentation Datentypen PHPMyAdmin	Lia	PHP Tipps 2005	3	14.04.2005 15:02
Java Datentypen umwandeln		HTML, Usability und Barrierefreiheit	8	07.02.2005 16:18
Größe einer Datenbank und Datentypen anzeigen	Klaus	Datenbanken	2	18.12.2004 16:21
Variable Datentypen		PHP Tipps 2004-2	8	24.11.2004 00:40
in_array, falsche Datentypen... :-(		PHP Tipps 2004	1	21.10.2004 14:38

24.02.2009, 20:50
HPR1974 Erfahrener Benutzer Registriert seit: 28.03.2008 Beiträge: 1.847	Weil die Genauigkeit des Datentyp float genau das hergibt, die Ungenauigkeit beginnt im Beispiel tatsächlich an der 15. Nachkommastelle. Sowas kommt irgendwann jedem mal in die Quere... echo number_format(64.8/5.4,14); 12.00000000000000 echo number_format(64.8/5.4,15); 11.999999999999998


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

24.02.2009, 20:53
dav1d Neuer Benutzer Registriert seit: 24.02.2009 Beiträge: 5	Danke für die schnelle Hilfe! Gut zu wissen.

24.02.2009, 20:53
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.989 PHP-Kenntnisse: Fortgeschritten	[MOD: verschoben] __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

26.02.2009, 02:16
papalangi_44 Benutzer Registriert seit: 12.02.2009 Beiträge: 63 PHP-Kenntnisse: Fortgeschritten	Nicht PHp ist ungenau sondern Gleitkommazahlen mit Nachkommastellen Gleitkommazahlen werden intern mit einen Exponenten und einer Mantisse gespeichet. Die Anzahl der Bits (Signifikanz) der Mantisse ist davon abhängig, ob float oder double gerechnt wird. 0,4 ist als Gleitkommazahl nicht exakt darstellbar, da es keine Potenz von 2 ist. Deshalb wurde früher auch mit COBOL oder in Assembler programmiert, da gab es Dezimalarithmetik. PHP-Code: Beispiel: Bei einer 32 Bit Gleitkommazahl werden 8 Bits für den Exponenten und 24 Bits für die Mantisse verwendet. Um die Mantisse mal manuell zu berechnen kann man die Multiplikationsmethode verwenden, da ich nicht sooft multiplizieren will bereche ich das Oktal und überführe das dann in das Binärsystem. bei der Multiplikationsmethode wird die Zahl mit der Basis des neuen Zahlensystens multipliziert. Das gilt aber nur für den Nachkommateil, Stellen vor dem Komma werden mit Divisionsrestmethodeumgewandelt. Also: 0,4 * 8 3,2 * 8 die 3 ist die erste Ziffer der Mantisse es wird nur mit dem 1,6 * 8 mit dem Teil hinter dem Komma 0,2 8 weitergerechnet. 4,8 8 6,4 * 8 Hier kommt das Problem, wir haben eine Periode, da wieder 3,2 nur mit 0,4 weiter multiplizert wird. unsere Mantisse wird somit zu : 3 1 4 6 3 1 4 6 3 1 4 6 ... (oktal) 011 001 100 110 011 001 100 110 011 001 100 110 (binär) 110 011 001 100 110 Das geht in den Bit/Mülleimer Die Mantisse wird dann normalisiert, d.h. führende nullen werden entfernt und der Exponent ermittelt (schenke ich mir hier, Stichwort Bias Exponent). Egal wieviel Stellen die Mantisse hat, es muss es muss abgeschnitten werden, dadurch ist die Zahl ungenau. Warum werden dann machmal aber trotzdem die Zahlen genau ausgegeben? Das liegt daran, daß die Ausgaberoutinen schlichtweg manchmal runden, wenn weniger Stellen ausgegeben werden. Wieviel Stellen sind genau? Das lässt sich leicht aus der Bitanzahl der Mantisse überschlagen. Für jede Dezimalstelle werden ca 3,3 Bits benötigt. D.H. bei einer 32 Bit Gleitkommazahl 123456789,4 liegt die Ungenauigkeit bereits in den Vorkommastellen. Man sollte also nie Gleitkommazahlen auf == vergleichen. if(abs($a - $b) < 0.000005) { print 'fast gleich'; } wäre eine Möglichkeit. Dabei ist darauf zu achten, das der Schwellwert nicht ausserhalb der möglichen Genauigkeit der Gleikommazahl liegt. Ich hoffe , dieser kleine Exkurs in die Grundlagen der Datenverarbeitung bringt dir das Verständnis für das Problem. Tröste Dich, Du bist nicht allein in dieser Richtung ahnungslos. Gruß Papalangi_44 der das vor ca. 40 Jahren gelernt hat. Wenn ich mal Zeit habe, werden ich mal ne Demo dafür programmieren. Geändert von papalangi_44 (26.02.2009 um 02:33 Uhr).