HomeMatic-Forum / FHZ-Forum

Verfasst: **26.03.2020, 23:27**

Hi Leute,

mal ne kurze Frage, kann die CCU nicht rechnen? Da macht das Skripten ja keinen Sinn, wenn ich jede Ausgabe erst mal in Frage stellen muss!

Code: Alles auswählen

integer value = 23 * 100 + 17;
WriteLine("Ergebnis = " + value.ToString());

Ausgabe:

Code: Alles auswählen

Ergebnis = 2691

Erst wenn ich Klammern setze kommt das richtige Ergebnis raus.
Ist das normal?

Verfasst: **27.03.2020, 00:02**

Matthias1912 hat geschrieben: ↑
26.03.2020, 23:27
Ist das normal?

Ja, ist es.

Grüße
Baxxy

Verfasst: **27.03.2020, 00:38**

klasse, Rangfolge hab ich klassisch "überlesen"

Ich komm aus der C Sprache, hätte mir nie einfallen lassen, das es hier ne eq-3 Mathe Variante gibt.

Danke für den Hinweis

Verfasst: **27.03.2020, 00:43**

OMG, zum Glück nutz ich NodeRED

Verfasst: **27.07.2020, 10:16**

Ja, Mathe mit der ReGaHSS macht echt Spaß.

Ein Beispiel:

Code: Alles auswählen

real a = 3.0;
real b = 6.0;

WriteLine((a + b)/2);

Ergebnis: 4.500000, wie erwartet

Code: Alles auswählen

real a = 3;
real b = 6.0;

WriteLine((a + b)/2);

Ergebnis: 4, weil nun nur noch mit Integer gerechnet wird, obwohl a als real definiert war.

Wenn man nun aber "/2" ersetzt durch "0.5 *", dann geht's wieder.

Code: Alles auswählen

real a = 3;
real b = 6.0;

WriteLine(0.5 * (a + b));

Ergebnis: 4.500000

Aber Vorsicht, richtig lustig wird's, wenn man die Multiplikation mit 0.5 nach hinten stellt.

Code: Alles auswählen

real a = 3;
real b = 6.0;

WriteLine((a + b) * 0.5);

Na, was kommt da wohl raus?
Ergebnis: 0
Da muss man erst mal drauf kommen.

Hat mich am Wochenende locker zwei Stunden beschäftigt, bis mir das aufgefallen war.

Verfasst: **27.07.2020, 10:45**

Alles vollkommen normal, dokumentiert und schon länger bekannt

Ersetze einfach deine „real“ Datentyp definitionen gegen „var“ und dir sollten solche Fehler nicht mehr So einfach passieren weil du dann mehr darauf achtest ob du einen integer oder float/real einer variable zuweist und damit die variable dann zu einem anderen typ zwingst wie das bei der ReGa Skriptsprache eben so ist.

Verfasst: **28.07.2020, 22:51**

dtp hat geschrieben: ↑
27.07.2020, 10:16
Ja, Mathe mit der ReGaHSS macht echt Spaß.
...
Hat mich am Wochenende locker zwei Stunden beschäftigt, bis mir das aufgefallen war.

upps.

Geht bedeutend schneller mit Spielzeug - inklussive Erklärung der Schritte & Typumwandlungen

jmaus hat geschrieben: ↑
27.07.2020, 10:45
Ersetze einfach deine „real“ Datentyp definitionen gegen „var“

Hilfe zur Selbsthilfe in dem man nicht deklariert? Auch ein Ansatz.
Da hätte man sich doch die Typen doch gleich ganz sparen können und alles var nennen.

Aber wie du schon geschrieben hast, die automatische Typumwandlung und von rechts nach links ist schon ewig bekannt und normal.

Alchy

Verfasst: **28.07.2020, 23:39**

Da hätte man sich doch die Typen doch gleich ganz sparen können und alles var nennen

Das habe ich mir auch gedacht. Gibt es noch irgendeine andere Programmiersprache auf der Welt, die in diesem Maße die Typ Deklarationen ignoriert? Und ist das nun Bug oder Feature?

Verfasst: **29.07.2020, 07:30**

Mir war zwar bewusst, dass die ReGaHSS von rechts nach links rechnet, aber ich war bisher der irrigen Annahme, dass auch die Variable bzw. Konstante, die ganz rechts steht, die also zuerst kommt, den Typ des Ergebnisses definiert. Aber es ist im Gegenteil die Variable bzw. Konstante, die zuletzt herangezogen wird, die also ganz links steht.

Verfasst: **29.07.2020, 10:29**

dtp hat geschrieben: ↑
29.07.2020, 07:30
Mir war zwar bewusst, dass die ReGaHSS von rechts nach links rechnet, aber ich war bisher der irrigen Annahme, dass auch die Variable bzw. Konstante, die ganz rechts steht, die also zuerst kommt, den Typ des Ergebnisses definiert. Aber es ist im Gegenteil die Variable bzw. Konstante, die zuletzt herangezogen wird, die also ganz links steht.

das ist fieserweise nicht so ganz richtig....

Der Ergebnis (oder besser zwischenergebnistyp) ist immer der Linksstehende der Operation, so wird ein schuh draus.

Beispiel:

Code: Alles auswählen

var a= 2.0+5*6.5;

Nach deiner Theorie kommt eine Gleitpunktzahl raus, und das musste 34.00 sein... isses aber nicht, das ergebnis ist nachher 32.00
Die rega arbeitet nach dem Stackpointer Verfahren, LIFO, last IN, First out.

die aufgabe landet durch den Parser auf dem Stackpoiunter

Code: Alles auswählen

2.0 --> 2.0  --> 2.0  --> 2.0  -- > 2.0
         +        +       +         +
                  5       5         5
                          *         *
                                    6.5

Nun kommt der Interpreter als schleife (Wenn Stack enthält mehr als 1 Wert) und arbeitet das ab
erster Wert 6.5
Operaton *
zweiter Wert 5
Zweiter wert ist Interger, also wird eine Intergermultiplikatoin gemacht 5 * 6.5 = 30, der wert kommt wieder auf den Stack

nach edm ersten Abarbeiten sieht der Stack so aus

Code: Alles auswählen

2.0 --> 2.0  --> 2.0  --> 2.0  -- > 2.0  --> 2.0
         +        +       +         +        +
                  5       5         5        30
                          *         *
                                    6.5

jetzt wirder das ganze
erster Wert 30
Operaton +
zweiter Wert 2.0
Zweiter wert ist float, also wird eine Gleitpunktaddition gemacht 2.0 + 30 = 32.00, der wert kommt wieder auf den Stack

Danach sieht der Stack so aus

Code: Alles auswählen

2.0 --> 2.0  --> 2.0  --> 2.0  -- > 2.0  --> 2.0  --> 32.00
         +        +       +         +        +
                  5       5         5        30
                          *         *
                                    6.5

Es ist nur noch ein Ergebnis auf dem Stack, heisst, abgearbeiet, Ergebnis liegt vor.

So kommen diese im ersten moment merkwürdigen Werte zustande

Black

HomeMatic-Forum / FHZ-Forum

[GELÖST] Mathematik

[GELÖST] Mathematik

Re: Mathematik

Re: Mathematik

Re: Mathematik

Re: [GELÖST] Mathematik

Re: [GELÖST] Mathematik

Re: [GELÖST] Mathematik

Re: [GELÖST] Mathematik

Re: [GELÖST] Mathematik

Re: [GELÖST] Mathematik