LabVIEWForum.de

Hallo zusammen.

Ich bin ein wenig verwirrt, was das Problem angeht, über das ich heute gestolpert bin.
Ein Student hat ein (extrem schlechtes!) VI geschrieben, um eine Zahl in ein Array aus Ziffern umzuwandeln.
Die Umsetzung ist nicht das Problem, sondern das Ergebnis.
Das VI ist im Anhang. Die äußere FOR-Schleife habe ich darum gelegt, um das zu untersuchen.
Wie das ganze funktionieren soll, sei mal am Beispiel der Zahl 13 dargestellt, (die umzuwandelne Zahl
ist der Laufindex der For-Schleife):
1. 13/10 = 1,3 > 1 ; While Schleife terminiert nicht, 1,3 ins shift
2. 1,3 - [floor(1,3) = 1] = 0,3
3. 0,3 * 10 = 3
4. floor (3) = 3 -> ins Array

zweiter Durchlauf:
5. 1,3/10 = 0,13 < 1; Schleife terminiert.
6. 0,13 - [floor(0,13) = 0] = 0,13
7. 0,13 * 10 = 1,3
8. floor (1,3) = 1 -> ins Array

Ergebnis: ein Array mit [1] und [3] nach dem umkehren. Soweit so gut.
Das Problem ist, das gleiche Prinzip funktioniert nicht mit den Zahlen 12,14,23,24,28 .....
Mit diesen Zahlen <30 habe ich das mal getestet. Habe auch Zwischenergebnisse mit Haltepunkten u.ä. ausgewertet.
Bei der Zahl 12 z.B. liegt der Fehler in floor(2) = 1 laut Labview...

Mal abgesehen davon, dass die Umsetzung schlecht ist, kann jemand erklären, warum die Ergebnisse so sind, wie sie sind ?

Gruß,
Andre

Hallo Andre,

Wikipedia hat da eine gute Übersicht zum Einstieg in das Rechnen mit Gleitkommazahlen. Lesenswert!

Und in meiner Signatur findest du einen englischsprachigen Artikel zum Thema!

Allgemein: Dein Problem tritt in jeder Programmiersprache auf, die Floats nach IEEE754-Standard benutzt! Unendliche (Binär-)Brüche lassen sich nun mal schlecht in 64bit darstellen…

Servus,

ist ein numerisches Problem, wie Gerd schon sagte.
Die vermeindliche 2 mit vielen Nachkommastellen dargestellt:
[attachment=52261]

Hallo und danke für die Antworten.

Ich kenne das Problem natürlich aus anderen Programmiersprachen
insbesondere beim Versuch Gleichheit zweier Zahlen zu Prüfen.
Es ist nur das erste mal, dass mir dies in LV vorgekommen ist, dazu noch
an einer Stelle, an der ich es so nicht erwartet hätte. Da lobe ich mir doch
manchmal die standardmäßige wissenschaftliche Notation...

Gruß,
Andre

Hallo Andre,

Zitat:dazu noch an einer Stelle, an der ich es so nicht erwartet hätte.

Wieso das? Dort wird fortgesetzt durch 10 geteilt: Dividieren durch 10 führt zu unendlichen Binärbrüchen und damit quasi sofort zu Rundungsfehlern…

Zitat:Da lobe ich mir doch manchmal die standardmäßige wissenschaftliche Notation...

Die Art und Weise, wie du eine Zahl darstellen lässt, ändert überhaupt nichts an den zugrundeliegenden Rechenalgorithmen…

Hier ist ein Paket, das verschiedene Methoden anbietet, Gleitkommazahlen zu vergleichen:
https://lavag.org/topic/18712-cr-floating-point-almost-equal/

Alternativ:
[attachment=52329]