EibPC Umrechnung/Konvertierung

[PharaDOS]

Warum kommt dieser Wert raus bei einer Umrechnung bzw. Konvertierung
Original Wert ist 112676 $$c6

Rechnung: convert(convert(weight@,0f16)/1000f16,$$)

Ergebnis ist: 112.64

Wäre nicht 112.68 oder 112.67 richtig ?

[DerRenovator]

Hallo Phara,
der Datentyp f16 ist von Natur aus ungenau. Rechne mal stattdessen mit f32; ich denke, dann sollte das Ergebnis passen.

[PharaDOS]

komischerweise kommen die Zahlen jetzt hin. bei unter 113.
aber f16 müsste doch auch das schaffen,

[Uwe!]

das Thema haben wird vor Jahren schon mal diskutiert, ohne zu einem aus meiner Sicht befriedigenden Ergebnis zu kommen. Ich rechne im Normalfall auch nur noch mit f32, aber selbst da muss man ggf. ne manuelle Rundung einbauen um nicht zu komischen Ergebnissen zu kommen.

Grundsätzlich liegt das natürlich tatsächlich and der Art wie Float Zahlen kodiert werden. Die Auswirkungen sind teilweise aber "strange" und es gibt auch Beispiele, die es (wie auch immer) besser können.

Aber diese Art von "Fehler" taucht häufig auf. Mein WinServer zeigt z. B. die freie Kapazität je Platte an. Meist steht da so was wie "3,05 GB frei". Manchmal steht da aber auch 4,100000000000001 GB frei". Das war dann sicher eine Float Berechnung bei der dann am Ende eben nicht richtig gerundet wurde.

[traxanos]

Nein das ist normal siehe auch https://de.wikipedia.org/wiki/Gleitkommazahl.

Du kannst das ganze aber Tricksen. Wenn du nur zwei Nachkommastellen brauchst, so kannst du zuerst deine Werte mal 100 rechnen, dann deine Rechnung durchführen und zum Schluss wieder durch 100 (+ ggf Runden)rechnen. So bekommst du zuverläßige Ergebnisse. Alternativ gibt es für Rechenaufgaben extra Libraries, aber vermutlich nicht für den EibPC.

[Uwe!]

Werte mal 100

das ist die "Lösung", die ich zum Teil anwende

extra Libraries

und das ist vermutlich das, was ich mit "die es (wie auch immer) besser können" meine.

brauchen die Libraries so viel Rechenpower/Speicher, dass sie für den EibPC(2) nicht in Frage kommen?

[foobar0815]

Es geht nicht so sehr darum, ob das intern nicht genauer gerechnet werden könnte, sondern was der Anwender programmiert, und vom Anwender als Ergebnis erwartet wird.
Wenn ich eine 8-bit-Zahl um 8 Stellen nach links und anschließend wieder um 8 Stellen nach rechts schiebe, kann das Gerät klar intern einen breiteren Datentypen verwenden und den Ausgangswert zurückliefern. Erwarten würde ich das aber nicht. Ähnlich auch beim f16 bzw DPT 9.

F16, so wie von der KNA spezifiziert, hat nunmal nicht mehr als 11 Bit Mantisse (-2048 ... 2047 * 0.01) und 4 Bit für den Exponenten (0..15). Durch die begrenzte Darstellbarkeit von Dezimalbrüchen als Binärbruch ergeben sich dann die entsprechenden Ungenauigkeiten.

Da wo es zu ungenau wird, einfach f32 verwenden.

[PharaDOS]

vielen dank für die Zahlreichen Erklärungen.
ich denke ich werde auch f32 nehmen und dann mir Stringformat das Formatieren und umwandeln.

[Uwe!]

Wenn ich eine 8-bit-Zahl um 8 Stellen nach links und anschließend wieder um 8 Stellen nach rechts schiebe, kann das Gerät klar intern einen breiteren Datentypen verwenden und den Ausgangswert zurückliefern. Erwarten würde ich das aber nicht

Beim bitweisen schieben würde ich das auch nicht erwarten. Und ich versteh auch voll und ganz auf was Du hinaus willst.

Beim klassischen Rechnen erwarte ich (das mag aber auch nur meine Erwartungshaltung sein) aber tatsächlich ein mathematisch korrektes Rechnen, kein IT-technisch korrektes Rechnen. Das ich mit snn (nn=8/16/32 etc) keine Nachkommastellen habe, ist klar. Das ich auch mit fnn keine beliebige Genauigkeit habe ist auch klar.

Aber bei 112676/1000 würde wohl fast jeder 112,676 erwarten. Ob das nun grad zufällig eine Zahl ist, die mit f16 darstellbar ist, hat wohl kaum einer direkt im Blick.

Meine Idee damals war intern immer mit f32 oder besser f64 zu rechnen und die Konvertierung zu f16 wenn ich so einen Wert auf den Bus schreibe kann der EibPC automatisch machen. Selbst auf s16 könnte automatisch konvertiert werden.

[traxanos]

Ich habe keinen EibPC aber ich würde es vom Anwendungszweck abhängig machen. Und da bin ich eher bei dir Uwe, denn bei solchen Rechnungen erwartet "mathematisch korrektes Rechnen" wie du schreibst.