Ankündigung

Einklappen
Keine Ankündigung bisher.

EibPC Umrechnung/Konvertierung

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    EibPC Umrechnung/Konvertierung

    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 ?

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

    Kommentar


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

      Kommentar


        #4
        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.
        ....und versuchen Sie nicht erst anhand der Farbe der Stichflamme zu erkennen, was Sie falsch gemacht haben!

        Kommentar


          #5
          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.

          Kommentar


            #6
            Zitat von traxanos Beitrag anzeigen
            Werte mal 100
            das ist die "Lösung", die ich zum Teil anwende
            Zitat von traxanos Beitrag anzeigen
            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?
            ....und versuchen Sie nicht erst anhand der Farbe der Stichflamme zu erkennen, was Sie falsch gemacht haben!

            Kommentar


              #7
              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.

              Kommentar


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

                Kommentar


                  #9
                  Zitat von foobar0815 Beitrag anzeigen
                  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.
                  ....und versuchen Sie nicht erst anhand der Farbe der Stichflamme zu erkennen, was Sie falsch gemacht haben!

                  Kommentar


                    #10
                    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.

                    Kommentar

                    Lädt...
                    X