Aus Zahl (Int/Float) wird String

[Gwunderi]

Hallo zusammen,

Habe ein Javascript-Programm, um mir etwas auszurechnen.

In zwei Input-Feldern muss man erst r und x eingeben.
Dann startet das folgende Rechenprogramm.

<script>
function rechne()
{var r  = document.getElementById("rd").value;
var x = document.getElementById("diff").value;
x = Math.pow(r,2) - Math.pow(x,2);
x = Math.sqrt(x) / 5;
var y = 15 - 3*x;
var z = r + 4*x;
y = y - (4/3)*z;
alert(y);}
</script>

Habe für r = 2 und für x = 1 eingegeben, aber das Ergebnis war immer falsch.
Das erste falsche Zwischenergebnis wird nach "var z = r + 4*x" ausgegeben - bis mir auffiel warum. Es behandelt das r offenbar als String, denn anstatt 3,3856… wird 21,3856… ausgegeben (also 2 + 1,3856). Obwohl es weiter oben Math.pow(r,2) richtig berechnet, also die 2 als Zahl interpretiert.

Habe nun unmittelbar vor der Zeile "var z = r + 4*x" die Zeile "r = parseFloat(r)" eingegeben, und nun kommt das richtige Ergebnis heraus.

Täte dennoch gerne wissen, warum die Variable r erst (richtig) als Zahl und später plötzlich offenbar als String interpretiert wird?

 

[Quaese]

Hi,

an der Stelle, an der x berechnet wird, erfolgt mit Sicherheit innerhalb der pow-Methode eine Umwandlung des Datentyps.

An der Stelle var z = r + 4*x; handelt es sich jedoch nicht um eine Rechenvorschrift, sondern um eine Zeichenkettenkonkatination, da es sich bei r um eine String-Variable handelt. Diese Operation besitzt eine höhere Priorität und wird daher vorrangig ausgeführt.

Du solltest einen Typcast von input-Feldern immer vornehmen, wenn du sicher sein möchtest, Zahlen zu erhalten. Hier sollte zudem eine Prüfung mit isNaN erfolgen.

Ciao
Quaese

 

[Gwunderi]

an der Stelle, an der x berechnet wird, erfolgt mit Sicherheit innerhalb der pow-Methode eine Umwandlung des Datentyps.

An der Stelle var z = r + 4*x; handelt es sich jedoch nicht um eine Rechenvorschrift, sondern um eine Zeichenkettenkonkatination, da es sich bei r um eine String-Variable handelt. Diese Operation besitzt eine höhere Priorität und wird daher vorrangig ausgeführt.

Du solltest einen Typcast von input-Feldern immer vornehmen, wenn du sicher sein möchtest, Zahlen zu erhalten. Hier sollte zudem eine Prüfung mit isNaN erfolgen.

Hallo Quaese

Zu Rechenvorschrift versus Zeichenkettenkombination habe ich vorhin etwas versucht. Habe wieder für r=2 und für x=1 eingegeben und in die erste Zeile alert(r - x) eingegeben, es kommt richtig 1 heraus, dann alert(r + x), und dann kommt 21 heraus.
Dann interpretiert JS also anhand der Operatoren, ob String oder Zahl. Das war mir auch nicht ganz neu, nur dass es das r einmal als Zahl und weiter unten im selben Programm als String behandelt verwirrt(e) mich.

Nehme an, dass es danach "vergisst", dass es bei Math.pow(r,2) das r als Zahl interpretiert hatte (hier ist es ja auch ganz eindeutig eine Rechenvorschrift). Wenn es zu "var z = r + …" kommt, holt es sich das r erneut und interpretiert es anhand des + als String.

Habe dann auch anstatt "r = parseFloat(r)" einfach "r = 1*r" eingegeben, und schwups wird das r wieder zur Zahl (auch wenn mir das parseFloat besser gefällt, da sieht man auch später die Umwandlung unmittelbarer).

Was ein Typcast von input-Feldern ist, habe vorhin kurz gegoogelt aber so auf die Schnelle nicht richtig verstanden, das isNaN hingegen kenne ich.

Guter Vorsatz also: Traue nie einem (selbst geschriebenen) Rechenprogramm, traute ich ja eh nie Bei solch kurzen Rechnungen ist es ja kein Ding, die Lösung für einige Werte von Hand auszurechnen, aber bei längeren und komplizierteren Berechnungen wird es dann gewiss sinnvoll, nach jedem Schritt prüfen zu lassen, mit welchem Datentyp man es da zu tun hat …
Vor allem beim "+" muss man wohl seeehr vorsichtig sein.

Danke Dir und Ciao
Gwunderi

 

[j-l-n]

Guter Vorsatz also: Traue nie einem (selbst geschriebenen) Rechenprogramm

Ne, ein guter Vorsatz ist das eigentlich nicht
Wenn man sauber arbeitet und nicht mehrere Variablentypen vermischt, ist Rechnen in JS wie in jeder anderen Skriptsprache kein Problem...

 

[Gwunderi]

Ne, ein guter Vorsatz ist das eigentlich nicht
Wenn man sauber arbeitet und nicht mehrere Variablentypen vermischt, ist Rechnen in JS wie in jeder anderen Skriptsprache kein Problem...

Ja gewiss, ich traue ja auch MIR nicht, dem Programm schon : )
Wie schnell ist etwas vergessen oder nicht beachtet: die Variable wird als String interpretiert, eine Klammer falsch gesetzt, die Vorzeichen innerhalb einer Klammer falsch gesetzt usw. usf.
Kann alles auch beim Rechnen von Hand passieren, aber da sieht man die Rechenoperationen unmittelbarer, z.B. ein Math.round(Math.pow(1.57,3) * 100) / 100 - da muss man ja erst einige Interpretationsarbeit leisten, von Hand in den gewohnten Zeichen geschrieben sieht man unmittelbarer, was die Rechnung soll.

Darum bleibe ich besser bei meinem guten Vorsatz :icon6:

 

[mikdoe]

wie in jeder anderen Skriptsprache kein Problem...

Ja, bis auf die geringfügige Einschränkung, dass Rechner nicht rechnen können.

 

[j-l-n]

bis auf die geringfügige Einschränkung, dass Rechner nicht rechnen können.

?

 

[mikdoe]

Na ja, was würdest du hiervon erwarten? Bitte wirklich NICHT testen, erst hier schreiben, welches Rechenergebnis du erwarten würdest bei folgendem Code!!!

JS Code:
alert(0.57 * 100);

 

[j-l-n]

Mik, ich kenne mich mit Fließkommazahlen/Runden in JS aus - hab ja selbst dazu mehrere Beiträge verfasst; muss die mal raussuchen...

Auch wenn man das als Laie vielleicht anders erwarten würde, ist das Ergebnis (56.99999999999999) vollkommen logisch, wenn man versteht, dass 0,57 eben nicht 0,570000... ist...

var float = 0.57;
//float.toFixed(20): "0.56999999999999995115"

Der Grund liegt in der von JavaScript verwendeten Methode (IEEE 754-Standard) des Umgangs mit Fließkommazahlen: Double-precision floating-point format - Wikipedia, the free encyclopedia

Unter "sauber arbeiten" fällt für mich eben auch der korrekte Umgang mit Fließkommazahlen und das richtige Runden. Und die vermeintlichen Rundungs-"Fehler" bedeuten doch trotzdem in keinster Weise, dass "Rechner nicht rechnen können"...
Mit Ganzzahlen hat man sowieso keine Probleme: 57*100 würde z.B. korrekt 5700 ergeben.

 

[mikdoe]

Ja, ist Auffassungssache. Rechnen ist für mich menschliche Mathematik und danach würde ich 57 erwarten. Und alle anderen Ergebnisse sind für mich falsche "Rechenergebnisse". Kommt halt drauf an, wie man rechnen definiert.

 

[Gwunderi]

Ja, ist Auffassungssache. Rechnen ist für mich menschliche Mathematik und danach würde ich 57 erwarten. Und alle anderen Ergebnisse sind für mich falsche "Rechenergebnisse". Kommt halt drauf an, wie man rechnen definiert.

Rechner wissen ja nicht einmal, was Rechnen bedeutet, wie sollen sie da noch rechnen können, strohdumm wie die sind?
(Hoffentlich ist jetzt mein Rechner nicht beleidigt und stürzt mir morgen ab : )

- - - Aktualisiert - - -

Du solltest einen Typcast von input-Feldern immer vornehmen, wenn du sicher sein möchtest, Zahlen zu erhalten.

Ja, merke gerade, wahrscheinlich hat es auch damit zu tun, dass der Wert aus einem Input-Feld herausgelesen wird, denn dieses Script gibt richtig erst 1 und dann 3 aus.

var r = 2;
var s = 1;
alert(r-s);
alert(r+s);

Habe bisher immer input type="text" oder gar kein type eingegeben, werde noch nachschauen, was es so alles für Typen gibt.

Danke an alle und Grüsslein
Gwunderi

 

[j-l-n]

Habe bisher immer input type="text" oder gar kein type eingegeben, werde noch nachschauen, was es so alles für Typen gibt.

Das wird dir rein gar nichts bringen, da das nichts mit Type-Conversion zu tun hat...
Javascript Type-Conversion

 

[Gwunderi]

Das wird dir rein gar nichts bringen, da das nichts mit Type-Conversion zu tun hat...
Javascript Type-Conversion

Ja, dachte ich mir, wenn sogar input type="number" nichts nützt …
Aber danke für die Bestätigung, so suche ich nicht auf dem falschen Weg weiter.

In der verlinkten Seite steht auch:
«As mentioned above, type conversion to a string most often results from the action of the + operator …»
und zur Umwandlung von String zu Zahl wird weiter unten auch die Multiplikation bzw. Division mit 1 vorgeschlagen, oder -0.

P.S. Mein PC ist scheint's nicht beleidigt, der Blödmann (mal sehen, wie weit ich's treiben kann …)

Grüsslein,
Gwunderi