LabVIEWForum.de - runden IEEE-Standard

LabVIEWForum.de

Normale Version: runden IEEE-Standard
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,

[attachment=41926]
[attachment=41927]

Das finde ich inkonsequent. Wenn runden, dann bitte gleich.




Gruß dimitri
Schau dir mal die deine 1.515 mit 16 Nachkommastellen an, dann steht da 1.5149999999999999, auf 2 Stellen im String gerundet gleich 1.51.

EDIT: Nach deiner Multiplikation mit 100 kommt 151.5 raus (nicht wundern, schließlich numerische Operation und Fließkommazahlen), das gibt dann nach deiner Rundung 152.

Gruß, Jens
Ok - kapiert. (Blöd gelaufen.)

Dann sollte das round.vi auch einen Eingang "Genauigkeit" bekommen, damit mann nicht multiplizieren muss.


Danke Jens.
Gruß dimitri
Das wäre dann wieder was für den Idea Exchange bei NI. Big Grin
Meine Stimme hättest Du.

Gruß Markus

(18.10.2012 21:23 )dimitri84 schrieb: [ -> ]Ok - kapiert. (Blöd gelaufen.)

Dann sollte das round.vi auch einen Eingang "Genauigkeit" bekommen, damit mann nicht multiplizieren muss.


Danke Jens.
Gruß dimitri
Hallo Dimitri,

Zitat:Dann sollte das round.vi auch einen Eingang "Genauigkeit" bekommen, damit mann nicht multiplizieren muss.
Bitte nicht. Das ist eine nach IEEE-Standard vorgegebene Funktion und ich habe keine Lust, in einer Programmiersprache plötzlich Sonderwege gehen zu müssen, weil manche immer mal wieder die Limitierungen von FloatingPoint-Zahlen vergessen...

So eine Funktion kann man sich selbst schnell programmieren und in die user.lib legen. Oder man schaut bei OpenG nach, da gibt es sowas (glaube ich) auch schon länger!
(19.10.2012 08:41 )GerdW schrieb: [ -> ]So eine Funktion kann man sich selbst schnell programmieren und in die user.lib legen. Oder man schaut bei OpenG nach, da gibt es sowas (glaube ich) auch schon länger!
OpenG ist an meinem Arbeitsplatz nicht praktikabel.

Dann bleibt mir nur der Umweg über die Stringfunktion um die Originalzahl zu runden?

Zitat:ich habe keine Lust, in einer Programmiersprache plötzlich Sonderwege gehen zu müssen
Einfach auf Null setzen und schon hat man seine alte Funkion. Hätte meine ich ...

Gruß dimitri
Hallo Dimitri,

- Die Stringfunktion rundet aber auch falsch, zumindest in deinem Bild oben. Das korrekte Ergebnis deiner Rundung lautet "1,52", zumindest nach IEEE ("bankers rounding").
- Das Ergebnis deiner Rechnung ("1,52000000000000002000") enthält auch wieder Rundungsfehler, da IEEE-Floats keine Zehnerbrüche darstellen können.
- Mit EXT sieht die Sache (zumindest bei deinem Beispielwert) anders/"korrekter" aus...

Mit Floats zu rechnen birgt immer Unsicherheiten. Die muss man kennen und in Kauf nehmen...

Abgesehen davon gibt es (glaube ich) in diesem Forum schon andere Threads, die sich mit Float-Rechengenauigkeit beschäftigen. Im NI-Forum auf alle Fälle auch!
(19.10.2012 09:36 )GerdW schrieb: [ -> ]Abgesehen davon gibt es (glaube ich) in diesem Forum schon andere Threads, die sich mit Float-Rechengenauigkeit beschäftigen. Im NI-Forum auf alle Fälle auch!
Da hast du vollkommen recht. Mein Problem ist einfach, dass ich jetzt zwei unterschiedliche Varianten in meiner Applikation habe und ein Update ist nicht so trivial durchzuführen... Pech. Selber Schuld.


Gruß
Referenz-URLs