RcRaCk2k

Leute ich glaub ich raffs nichtmehr!

FEHLER-SCRIPT:
http://mitarbeiter.salzburg.seminar-...rack/kakke.php

200 - 200 ist meiner Meinung nach 0, und nicht 1.70530256582E-13!

Wer weis wo der Fehler liegt?

Vielen Dank im Voraus.

Michael Rack

Mister Ad

Buhmann

weißt du, wie der datentyp floor funktioniert? http://de.wikipedia.org/wiki/Gleitkommazahl
lies dir das durch, dann verstehst du den grund.

dsmcg

ist es nicht eigentlich der Prozessor der die Rechnung ausrechnet? und nicht die Programmiersprache ?!

__________________
Wie man Fragen richtig stellt

RcRaCk2k

Ich versteh das trozdem nicht.. Gut ich verwende jetzt die bcsub funktion, jetzt funktioniert auch alles schön...

Aber dann sag mir mal warum einfachste Mathematik nicht funktioniert:
Ausgabe = float(0.00999999999999)
http://mitarbeiter.salzburg.seminar-...ack/kakke2.php

Buhmann

das wurde doch auf wikipedia erklärt. eine floatzahl wird als
m*2^e abgespeichert, wobei m und e ganzzahlen sind. Es gibt eben Zahlen, die sich so nicht exakt speichern lassen. wenn du das nicht willst, sach halt, dass du integer zahlen haben willst.

mepeisen

$a = 2.2;
$b = floor(2.2);

$intDoubleDetection = ($a - $b) * 1000;
settype($intDoubleDetection, "integer");



Obiger Zusatz sollte (mit etwas Glück) die Näherungsprobleme umgehen. Besser ist natürlich eine sauberere Lösung mittels ordentlicher Funktionen (round und Konsorten) unter Verwendung der gewünschten Nachkomastellen.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

dieselben Probleme tauchen auch bei JavaScript auf oder in alten, höheren DOS-Programmiersprachen die einen 32-Bit-Rechner auf einem 8-Bit-System simulierten. Ursache war immer der falsche Variablentyp.

wenn man sich mal mit einem Hex-Editor die Zahlen anzeigen lässt, findet man auch schnell heraus warum. Wenn man dan aus einer 8-Bit-Zahl (200) eine 64-Bit-Zahl macht (3.414E-13) dann kommt das richtige Ergebnis als 64-Bit-Zahl heraus.

11001000-11001000 ist 00000000 also richtig 0
setzt man vor die 11001000 eine undefinierte 56-Bit-Reihe und im Speicher wäre da noch was, schreibt er nicht in den Speicher hat aber den Platz reserviert und liest das aus, was noch da ist.

nur zum Verständnis ein Erklärungsversuch -200-200 :

minus 200 wäre dann als Byte 111000 oder 00111000 oder
11111111111111111111111111111111111111111111111111 11111100111000
wenn man von diesem 32-Bit-Code ein 8-Bit-Wert (int) mit dem Wert 200 also 00111000 abzieht käme dann
11111111111111111111111111111111111111111111111111 11111100000000
heraus. Das wäre dann 18446744073709551360 aber nicht -400 !

nun mache das man mal mit 64-Bit und positiven Zahlen

dsmcg

also nochmal ne ernste Frage, rechnet nicht der Prozessor?

Es rechnet doch nicht die Programmiersprache..

__________________
Wie man Fragen richtig stellt

mepeisen

@aberchen. Prinzipiell ist die Erklärung gut, aber in diesem Fall nicht zutreffend, da 1. PHP korrekt vorinitialisiert und b) das Problem nur bei Ganzzahligen Sachen auftreten, aber nicht bei Fliesskommazahlen.

@dsmcg. Letzlich rechnet immer der Prozessor. Wie kommt aber logischerweise auf die Programmiersprache an. C beispielsweise ist sehr prozessornah, weshalb eine Rechnung hier relativ transparent ist. Aber egal, PHP arbeitet hier auch relativ transparent. Es hat "nur" eine variable Zahlendrarstellung.
Das Hauptproblem ist immer, dass Fliesskommazahlen klassischerweise wie oben schon dargestellt in ein internes Format umgesetzt werden, dass nur Näherungen zulässt. Normalerweise wird dies berücksichtig, so dass eine gewisse Nachkommastellenzahl angenommen wird und dann entsprechend bei Ergebnissen gerundet wird. Problem ist, dass bei der Mulitplikation mit 1000 diese Näherung verlassen wird und damit die Rundung nicht mehr zuschlägt. Genau weiss ich es nicht, da auch die möglichen Näherungen variabel sind und ich nicht im Kopf habe, wie die Zend Engine effektiv arbeitet bzw. mit wieviel Bit die Fliesskommazahlen intern dargestellt werden. Ist auch egal.

Die Rechnung mit Ganzzahlen läuft anders, da die, wie aberchen schrieb, anders dargestellt werden und daher immer genau sind, solange die vorgesehene Bit-Breite nicht überschritten wird. Bei Divisionen wird eventuell ein Float aus einem Integer und damit gelten wieder die Näherungsprobleme.

bcsub arbeitet komplett anders, also mit anderen Zahlenrepräsentationen, was aber auch bedeutet, dass es die Näherungsprobleme nicht verhindert, nur soweit minimiert, dass sie bei "gängigen" Rechnungen nicht mehr auftreten. Aber Probleme haben die bc*- Funktionen ebenfalls. Zudem sind sie deutlich langsamer als die Prozessornahem Berechnungen.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nee, eigentlich kann der Prozessor gar nicht rechnen, bzw. rechnet er anders, z.B. es wird ein Bit nach links verschoben, das kann +8 bedeuten oder mal 2.

1000 ist 8, eins nach links ist 10000 ist 16
2 Rechnungen ein Ergbnis

andere Rechnung:
1100 ist 12, eins nach links ist 10100 also 20
das ist 12+8 aber nicht 12*2

12*2 wäre 11000 also 2 mal um 1 nach links verschoben
natürlich hat die hardware heutiger Prozessoren Millionen von solchen Verschiebeoperatoren in Form von Flops fest eingebaut.
aber das Prinzip ist 1 +1 oder 1-1