[DISKUSSION] Fließkomma- und Ganzzahlen in JavaScript

[mikdoe]

AW: Diskussion zum Speichern/Anzeigen von Fließkomma- und Ganzzahlen

Was ist denn ein interner Typecast?

Ich kann nur sagen, was ich mir darunter vorstelle: einen Mechanismus der dazu führt, dass das Ergebnis aus .57 x 100 intern als Ganzzahl abgespeichert wird, damit die interne Speicherung der Variable identisch mit dem per print angezeigten Wert ist.
Fände ich zumindest wünschenswert.

 

[ein schlauer]

AW: Richtig runden.

Und das meinte ich mit Typecast. Würde ein vorhandenes Typecast nicht von selbst hieraus intern eine Ganzzahl machen?

Nein, sowas gibt es nicht. Ein Typecast ist immer etwas erzwungenes, du musst also entweder int() - was aber rundet - oder mit sprintf runden.
also z.b.

my $a = (sprintf('%0.0f', .57*100));

 

[tsseh]

AW: Richtig runden.

Na ja, nicht ganz. Das Problem ist, dass ich nach einer Mulitiplikation von .57 mit 100 laut print in der Variable 57 stehen habe. Das ist ein erwartetes Ergebnis.

nein ist es nicht! bei (57 *100)/100 ist es das erwartete Ergebnis

Dennoch schlägt 57==57 fehl.

nein, 56.999999999999995115018691649311222136020660400390625 == 57 schlägt fehl

Was genau jetzt? Dass die Wurzel aus 2 irrational ist oder dass mein gezeigtes Beispiel nur scheinbar eine Ganzzahl ist?

das .57 als 64-Bit Gleitkommazahl .56999999999999995115018691649311222136020660400390625... ist

 

[mikdoe]

AW: Richtig runden.

nein ist es nicht! bei (57 *100)/100 ist es das erwartete Ergebnis

Das nützt ja nichts. Denn im Ursprungsthread war ja die Ausgangslage, dass man eine Fließkommazahl hat und empfohlen wurde, mit Ganzzahlen zu rechnen. Da komme ich ja nur über .57 x 100 hin. Oder ich verschiebe mit String-Funktionen das Komma zwei Stellen nach rechts, das war ja mein Alternativvorschlag, um dieses Problem hier zu umgehen, und kkapsner's Vorschlag dazu schien mir genau das zu machen.

nein, 56.999999999999995115018691649311222136020660400390625 == 57 schlägt fehl

Ja, ist mir klar.
Wieso kommt bei print nicht 56.999999999999995115018691649311222136020660400390625 zur Anzeige?
Darf man nicht davon ausgehen, dass ein einfaches print/echo/say oder sonst was den tatsächlichen Inhalt einer Variable anzeigt?

 

[tsseh]

AW: Richtig runden.

Das nützt ja nichts. Denn im Ursprungsthread war ja die Ausgangslage, dass man eine Fließkommazahl hat und empfohlen wurde, mit Ganzzahlen zu rechnen. Da komme ich ja nur über .57 x 100 hin.

da kommst du über eine Kettenbruchentwicklung hin. musst du aber nicht, da geld keine 0.57 € kennt sondern nur 0 € 57 cent.

Wieso kommt bei print nicht 56.999999999999995115018691649311222136020660400390625 zur Anzeige?

my $a = .57*100;
printf "%.16f", $a;

 

[mikdoe]

AW: Richtig runden.

musst du aber nicht, da geld keine 0.57 € kennt sondern nur 0 € 57 cent.

Jetzt drehen wir uns im Kreis. Wie kommt man denn am besten von Euro zu Cent ohne darüber zu stolpern, dass 0.57 x 100 nicht 57 ist?

printf "%.16f", $a;

Nee, das hatten wir schon. Ich habe nicht nach einer anderen Lösung gefragt sondern warum print ohne weitere Formatierung nicht das anzeigt, was die Variable wirklich enthält.

 

[ein schlauer]

AW: Diskussion zum Speichern/Anzeigen von Fließkomma- und Ganzzahlen

Wieso print zeigt doch das an was die Variabel enthält:

my $a = .57 * 100;
print $a; # => 57

Was dein Problem ist, dass int auf 56 kürzt, weil die Zahl in Wrklichkeit kleiner als 57 ist.

EDIT: Ok, ich hatte grad einen Knoten im Hirn. print zeigt nicht alle Nachkomastellen an
To what precision does perl print floating-point numbers? - Stack Overflow

 

[tsseh]

AW: Richtig runden.

Jetzt drehen wir uns im Kreis. Wie kommt man denn am besten von Euro zu Cent ohne darüber zu stolpern, dass 0.57 x 100 nicht 57 ist?

eigentlich nicht, wir haben nie 0.57. wenn aber doch, warum nehmen wir nicht die 2 stellen nach dem "."?

Nee, das hatten wir schon. Ich habe nicht nach einer anderen Lösung gefragt sondern warum print ohne weitere Formatierung nicht das anzeigt, was die Variable wirklich enthält.

ja und was soll das sein? woher soll print wissen, in welcher genauigkeit du den wert anzeigen willst? das kann man ja extra angeben, weil man das nicht sagen kann. da gibt es irgendeine defaulteinstellung, ob die nun in den meisten fällen richtig ist, wer will das sagen?

 

[ein schlauer]

AW: Richtig runden.

ja und was soll das sein? woher soll print wissen, in welcher genauigkeit du den wert anzeigen willst? das kann man ja extra angeben, weil man das nicht sagen kann. da gibt es irgendeine defaulteinstellung, ob die nun in den meisten fällen richtig ist, wer will das sagen?

die steckt hier C <float.h> Library

FLT_DIG 6

DBL_DIG 10

LDBL_DIG 10
These macros define the maximum number decimal digits (base-10) that can be represented without change after rounding.

 

[tsseh]

AW: Richtig runden.

die steckt hier C <float.h> Library

dann müsste aber DBL_DIG aber 15 sein und FLT_DIG 7
und perl nutzt doch sicher auch double, oder? damit hat man wider min. 15 unterscheidbare ziffern und print müsste 56.999999.. anzeigen.

 

[mikdoe]

AW: Richtig runden.

EDIT: Ok, ich hatte grad einen Knoten im Hirn. print zeigt nicht alle Nachkomastellen an

Endlich. Ich dachte schon wir machen noch eine Runde

Und genau das wollte ich zeigen. Man hat - auch wenn man es denkt - nicht immer eine Ganzzahl vor sich. Zumindest in Perl. Man muss sich diese stets selbst erzeugen.
In JS habe ich das nicht genauer untersucht.

eigentlich nicht, wir haben nie 0.57. wenn aber doch, warum nehmen wir nicht die 2 stellen nach dem "."?

In jeder normale Eingabemaske einer kaufmännischen Anwendung würde man als Eingabe 0.57 oder 0,57 erwarten, wenn jemand 57 Cent ausdrücken will.
Und was meinst du mit "warum nehmen wir nicht die 2 Stellen nach dem ."?

woher soll print wissen, in welcher genauigkeit du den wert anzeigen willst?

Das ist nicht die Frage.
Ich stelle sie nochmal: Wenn eine Variable den Wert 56.99999999999946373..... irgendwas hat, wieso zeigt in meinem Beispiel das print ohne jegliche Formatierung trotzdem 57 an? Dass mit Formatierung printf oder sprintf 57 kommt ist ja ok. Aber wieso sehe ich ohne Formatierung nicht den tatsächlichen Wert?

 

[ein schlauer]

AW: Richtig runden.

dann müsste aber DBL_DIG aber 15 sein und FLT_DIG 7
und perl nutzt doch sicher auch double, oder? damit hat man wider min. 15 unterscheidbare ziffern und print müsste 56.999999.. anzeigen.

Das sind die Einstellung in C (womit die aussage, das C "genauer" wäre auch widerlegt ist), Perl verwendet tatsächlich andere Werte Re^3: float values and operators
https://metacpan.org/source/RJBS/perl-5.18.0/perl.h

 

[mikdoe]

AW: Richtig runden.

womit die aussage, das C "genauer" wäre auch widerlegt ist

Ja, das habe ich daraus auch gelernt.

 

[tsseh]

AW: Richtig runden.

Endlich. Ich dachte schon wir machen noch eine Runde

ja, hast ja gerade eine neue angefangen.

Und genau das wollte ich zeigen. Man hat - auch wenn man es denkt - nicht immer eine Ganzzahl vor sich. Zumindest in Perl.

man weiß, wann man gleitkommazahlen hat und wann nicht. in nicht typisierten sprachen nicht so eindeutig, aber wenn man .57 * 100 schreibt weiß man, daß man eine gleitkommazahl hat!

In jeder normale Eingabemaske einer kaufmännischen Anwendung würde man als Eingabe 0.57 oder 0,57 erwarten, wenn jemand 57 Cent ausdrücken will.
Und was meinst du mit "warum nehmen wir nicht die 2 Stellen nach dem ."?

warum nehmen wir dann nicht aus dem string der eingabemaske die 57 (2 Stellen nach dem .)?
man darf nur mit den 0.57 nicht rechnen

Aber wieso sehe ich ohne Formatierung nicht den tatsächlichen Wert?

weil 56.99999 mit 6 Stellen genauigkeit 57 ist.

 

[mikdoe]

AW: Richtig runden.

man weiß, wann man gleitkommazahlen hat und wann nicht.

Dass das jeder weiß glaube ich nicht. Daher hatte ich ganz am Anfang des Ursprungssthread darauf hingewiesen.
Jeder Hinz und Kunz macht heutzutage Webanwendungen. Wenn man die alle fragen würden, ob sie das wissen, was käme da raus?

in nicht typisierten sprachen nicht so eindeutig, aber wenn man .57 * 100 schreibt weiß man, daß man eine gleitkommazahl hat!

OK, wenn du meinst.
Eine Umfrage würde mich wirklich interessieren.
"Wussten Sie, dass 0.57 x 100 nicht 57 ergibt, obwohl print 57 ausgibt?"
Geile Fragestellung

weil 56.99999 mit 6 Stellen genauigkeit 57 ist.

Welche Aussage triffst du mit diesem Satz? Wie kommst du auf ausgerechnet 6 Stellen?

 

[tsseh]

AW: Richtig runden.

Das sind die Einstellung in C (womit die aussage, das C "genauer" wäre auch widerlegt ist),

in c ist das genauso wie in perl wie in irgendetwas anderem. maximal kann ich mich in c entscheiden 32 Bit oder 64 Bit darstellung zu nehmen. irgendeine andere sprache hat vielleicht noch 128 Bit darstellung. Ich glaube nicht, dass irgendeine sprache sich nicht an den standard für gleitkommadarstellung hält.
damit hat man aber 7.22 Dezimalstellen für 32 Bit und 15.95 für 64 bit die als binär-gleitkommazahl verlustfrei speicherbar sind

Welche Aussage triffst du mit diesem Satz?

das diese zahl 57 ist in der geforderten genauigkeit!
in der physikarbeit hast du doch auch nicht diskutiert, wenn das ergebniss mit 2 nachkommastellen angegeben werden sollte.
so ähnlich ist es mit der genauigkeit.

Wie kommst du auf ausgerechnet 6 Stellen?

das hatte der schlaue mal gepostet, aber auch schon wieder geändert.

 

[mikdoe]

AW: Richtig runden.

das diese zahl 57 ist in der geforderten genauigkeit!

Mir geht es darum, dass eine Variable u.U. nicht den Wert enthält, den man aufgrund der print Ausgabe annimmt.
Haben wir jetzt aber ausreichend dargestellt, kann glaube ich beendet werden

in der physikarbeit hast du doch auch nicht diskutiert, wenn das ergebniss mit 2 nachkommastellen angegeben werden sollte.

Was hat das jetzt hiermit zu tun?

das hatte der schlaue mal gepostet, aber auch schon wieder geändert.

print in Perl zeigt mehr als 6 Stellen an. Also könnte es das Ergebnis von .57 x 100 eigentlich auch korrekt anzeigen.
Bringt uns zum Ergebnis, dass print in Perl selbst auch zu runden scheint. Und das kann tückisch sein, wenn man es nicht weiß, denn man sieht es nicht bei der Ausgabe von Zwischenergebnissen und beim Weiterrechnen mit dem Wert führt es theoretisch zu unendlich kleinen Abweichungen zum tatsächlich mathematisch korrekten Ergebnis. Oder ist .57 x 100 mathematisch nicht 57?
Und um mehr ging es mir nicht, als das zu zeigen, weil ich vermute, dass JS dahingehend ähnlich ist und vielleicht noch schlimmer, weil browserabhängig.

 

[tsseh]

AW: Richtig runden.

in c ist das genauso wie in perl wie in irgendetwas anderem. maximal kann ich mich in c entscheiden 32 Bit oder 64 Bit darstellung zu nehmen. irgendeine andere sprache hat vielleicht noch 128 Bit darstellung. Ich glaube nicht, dass irgendeine sprache sich nicht an den standard für gleitkommadarstellung hält.
damit hat man aber 7.22 Dezimalstellen für 32 Bit und 15.95 für 64 bit die als binär-gleitkommazahl verlustfrei speicherbar sind

6 ist doch richtig für 32 bit.

std::numeric_limits::digits10 - cppreference.com

The standard 32-bit IEEE 754 floating-point type has a 24 bit fractional part (23 bits written, one implied), which may suggest that it can represent 7 digit decimals (24 * std::log10(2) is 7.22), but relative rounding errors are non-uniform and some floating-point values with 7 decimal digits do not survive conversion to 32-bit float and back: the smallest positive example is 8.589973e9, which becomes 8.589974e9 after the roundtrip. These rounding errors cannot exceed one bit in the representation, and digits10 is calculated as (24-1)*std::log10(2), which is 6.92. Rounding down results in the value 6.

damit sind es 6.92 für 32 und 15.65 für 64 bit.

Was hat das jetzt hiermit zu tun?

du musst wissen, welche genauigkeit benötigt wird.

print in Perl zeigt mehr als 6 Stellen an. Also könnte es das Ergebnis von .57 x 100 eigentlich auch korrekt anzeigen.
Bringt uns zum Ergebnis, dass print in Perl selbst auch zu runden scheint.

die ausgabe einer gleitpunktzahl ist immer gerundet.

und beim Weiterrechnen mit dem Wert führt es theoretisch zu unendlich kleinen Abweichungen zum tatsächlich mathematisch korrekten Ergebnis.

und es kommt sogar noch auf die operatorreihenfolge an. ja, ein mathematisch korrekten Ergebnis bekommt man in den wenigsten fällen. man benötigt es aber auch nicht. du selbst rundest doch bestimmt auch meistens.
wenn du von hier nach da fährst, zeigt dein navi auch keine mm an.

Oder ist .57 x 100 mathematisch nicht 57?

und ist gerundet auf 2 nachkommastellen .569 x 100 nicht 57?

Und um mehr ging es mir nicht, als das zu zeigen, weil ich vermute, dass JS dahingehend ähnlich ist und vielleicht noch schlimmer, weil browserabhängig.

NOCH MAL das ist sprachunabhängig.

 

[ein schlauer]

AW: Richtig runden.

print in Perl zeigt mehr als 6 Stellen an. Also könnte es das Ergebnis von .57 x 100 eigentlich auch korrekt anzeigen.
Bringt uns zum Ergebnis, dass print in Perl selbst auch zu runden scheint.

Genau das war das was ich oben gezeigt hatte - Perl und alle Sprachen die diese C floating point libary benuzten runden bei der Anzeige von Fliesskommazahlen, je nachdem welcher Wert in DBL_DIG steht. Ich dachte du hast das verstanden.
Wenn du eine genaue Ausgabe möchtest musst du printf nehmen.

 

[mikdoe]

AW: Richtig runden.

du selbst rundest doch bestimmt auch meistens.

Das ist die zentrale Frage.
Bei .57 x 100 = 57 wäre ich - ich bin kein Berufsprogrammierer! - früher auch nicht davon ausgegangen, dass da "intern" nicht 57 bei raus kommt und man formatieren/runden/abschneiden muss/kann/soll.

Genau das war das was ich oben gezeigt hatte - Perl und alle Sprachen die diese C floating point libary benuzten runden bei der Anzeige von Fliesskommazahlen, je nachdem welcher Wert in DBL_DIG steht. Ich dachte du hast das verstanden.

Insgesamt hatte ich es schon verstanden. Ihr brauchtet jetzt für mich auch keine umfangreichen Recherchen durchzuführen, um meine meist retorischen Fragen zu beantworten.
Aber bis ich das wusste hätte ich niemals gedacht, dass ein Computer aus .57 x 100 nicht 57 raus bekommt, insbesondere weil print das ja suggeriert.
Ein Taschenrechner kommt ja auch auf 57, mal ganz platt gesprochen

Dennoch mal stellvertretend für alle interessierten Leser danke für die angeregte Diskussion. Ich habe wieder was dazu gelernt.