INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Ungenauigkeit von Floatingpoint (allgemein)



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

26.07.2010, 12:51
Beitrag #11

eMKay Offline
LVF-Grünschnabel
*


Beiträge: 33
Registriert seit: Jul 2010

8.6 Student
2009
de


Deutschland
Ungenauigkeit von Floatingpoint (allgemein)
' schrieb:Hallo eMKay,

"Ich vergleiche die Zahlen nicht, aber ich muss eine sehr kleine Kommazahl und eine kleine Kommazahl addieren."
Um welche Werte (Größenordnungen) handelt es sich denn? Bisher hast du nur von 0.1 und 0.2 geschrieben...
Grundproblem:
Die Floatingpoint-Zahlen haben jeweils nur eine bestimmte Genauigkeit. Die beträgt bei DBL z.B. 53 bit oder auch ~16 Dezimalstellen. Liegen deine "sehr kleine" und "kleine" Zahl also 16 Zehnerpotenzen auseinander, gibt's Probleme (Rundungsfehler)...

"Leider existieren, die dort erwähnten dezimalen Datentypen, die das Problem umgehen sollen nicht in LabView oder ich bin zu doof sie zu finden."
Kennst du eine andere Programmiersprache, die diese dezimalen Datentypen von Haus aus unterstützt? Einen relativ neuen Standard, der bisher noch nicht von Hardware (d.h. CPU-Befehlen) unterstützt wird?
Alternativ kannst du ja Bibliotheken zum Rechnen mit "unbegrenzter" Genauigkeit einbinden. Der Aufwand dafür könnte aber erheblich sein...

Edit:
Nachtrag zu den CPU-Befehlen: beim 6502 konnte man in einen Dezimalmodus umschalten und dann "normale" Rechenbefehle (ADD, SUB) benutzen. Beim 68k gab's die ABCD/SBCD-Befehle zum Rechnen mit BinaryCodedDecimals. Kannst du natürlich in LabVIEW nachbauen - haben andere Leute mit den o.a. Bibliotheken ja auch schon gemacht...

Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5 (direkt aus Labview kopiert). Ich hatte das Beispiel mit 0,1 und 0,2 nur verwendet um mein Problem auf einer sehr einfachen Ebene zu veranschaulichen.
Meine Zahlen liegen in der Tat weit auseinander. Dry

Ich wusste nicht, dass diese dezimalen Datentypen nicht von Hardware unterstützt werden. Ich hatte mich nur auf den Artikel auf der oben genannten Webseite bezogen.


' schrieb:s. Gerd

DOCH, dem IST so!!!

Dieser Vergleich hinkt bzw. ist nicht zulässig. Ein Taschenrechner rechnet anders als eine FPU eines Computers.
http://www.wer-weiss-was.de/theme50/article2510135.html

Gruß, Jens


Faszinierend. Ich war mit nicht bewusst, dass eigentlch jeder ohne es zu wissen ständig ungenau rechnet. Danke für den Link mit dem Taschenrechner.


' schrieb:Hast du auch alle Controlls neu erstellt oder nur die Darstellungsart auf EXT geändert? Das hat bei mir auch nicht funktioniert... also einfach mal frische EXT Controlls ins BD ziehen.
Gruß SeBa


Ich habe alles neu erstellt. Der Unterschied ist, dass ich unter den Anzeigeformat auf "signifikante stellen" umgestellt habe und du auf "kommastellen". Wenn ich es auf Kommastellen einstelle bekomme ich auch den exakten Wert 0,300000000.. Wenn du es auf "sigifikante Stellen"umstellst wirst du sehen, dass du auch so einen "murks" rausbekommst wie ich.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
26.07.2010, 13:02 (Dieser Beitrag wurde zuletzt bearbeitet: 26.07.2010 13:10 von GerdW.)
Beitrag #12

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
Ungenauigkeit von Floatingpoint (allgemein)
Hallo eMKay,

"Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5"
EXT benutzen 64bit oder ~19 Dezimalstellen!
Schauen wir uns das mal an:
+0.000 100 000 000 000 000 000 000 000 000 000 0 (erste Zahl, abgesehen von Rundungsfehlern aufgrund unendlichem binären Bruch!)
+0.000 000 000 000 000 007 797 368 734 555 820 7 (zweite, sehr kleine Zahl)
=0.000 100 000 000 000 007 797 368 734 555 820 7 (Summe, "von Hand")
=0.000 100 000 000 000 007 797 4 (Summe, als EXT-Zahl, durch mich gerundet)

Problem erkannt? Dir fehlen plötzlich 12 Stellen im Ergebnis...

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
26.07.2010, 13:19
Beitrag #13

eMKay Offline
LVF-Grünschnabel
*


Beiträge: 33
Registriert seit: Jul 2010

8.6 Student
2009
de


Deutschland
Ungenauigkeit von Floatingpoint (allgemein)
Hi Gerd,

Ja das Problem habe ich erkanntWink. Erschwerend zu den Fehlenden 12 Nachkommastellen kommt eben dieser Rundungsfehler hinzu. Der Ist in dem Moment ein größeres Problem als die fehlenden Stellen, da der Fehler an einer Stelle mit wesentlich höherer Signifikanz auftritt. Den fehlenden Kommastellen könnte ich ja zu Leibe rücken in dem ich (wie hier schon vorgeschlagen wurde) mit 10^x multipliziere, aber wenn der Rundungsfehler so "hoch" ist bringt mir das ja nichts, da ich den wieder reinbekomme sowie ich zurück in die Kommazahl umwandle.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.08.2010, 10:44 (Dieser Beitrag wurde zuletzt bearbeitet: 17.08.2010 11:01 von rolfk.)
Beitrag #14

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
Ungenauigkeit von Floatingpoint (allgemein)
' schrieb:Hast du auch alle Controlls neu erstellt oder nur die Darstellungsart auf EXT geändert? Das hat bei mir auch nicht funktioniert... also einfach mal frische EXT Controlls ins BD ziehen.
Gruß SeBa

EXT löst das Problem nicht sondern vrschiebt es nur einige wenige Dezimalstellen nach hinten (und das auch nur auf Intel CPU Architekturen da das dem interenen FPU Zahlenformat entspricht, aber mit aktuellen LabVIEW Versionen ist alles gegenwärtig Intel CPU).

Die einzige wirkliche Lösung für dieses Problem ist eine Dezimalzahlrechnungsbibliothek zu machen. Das ist aber eine im Vergleich zu Floatingpointarithmetik mit eingebauter FPU-Unterstützung extrem langsame Berechnungsart. Greg McKaskle, einer der LabVIEW Programmierer der bis vor einigen Jahren ziemlich aktiv war in LabVIEW Foren hat mal so eine Library programmiert und verfügbar gemacht. Sie beruhte auf BCD Berechnungen und verwendete Strings um eine theoretisch unendliche Genauigkeit zu erreichen.

Für gewisse finanzielle Anwendungen manchmal unverzichtbar, aber sehr langsam und in vielen Dingen ziemlich unschön in der Verwendung da ein String natürlich alles beinhalten kann, nicht nur Zahlen, und die Library deshalb auch dass noch berücksichtigen muss.

' schrieb:Hallo eMKay,

"Ich addierte Zahlen im Bereich von 0,0001 bis 1 und Zahlen von 7,7973687345558207E-18 bis 9,9999999999985964E-5"
EXT benutzen 64bit oder ~19 Dezimalstellen!

Das stimmt so nicht ganz. LabVIEW Single Precision ist 4 Byte = 32 Bit (24 Bit Significand = ~8 digits), Double Precision ist 8 Byte oder 64 Bits (53 Bit Signifikant = ~15 digits) und Extended Precision ist 10 Bytes oder 80 Bits (64 Bit Signifikant = ~ 19 digits). Zwar verwendet LabVIEW 16 Bytes oder 128 Bits um eine Extended Precision Zahl in einem Flattened Format abzuspeichern das kommt aber daher dass in uralten Zeiten als LabVIEW auch noch auf Sun Sparc Stations lief, Gebrauch gemacht wurde von der Sun Software Mathematikbibliothek die eben ein 16 Byte Extended Format kannte.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.08.2010, 10:50
Beitrag #15

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
Ungenauigkeit von Floatingpoint (allgemein)
Hallo Rolf,

hast du einen Link auf diese Library?
Bin gerade an etwas ähnlichem dran, um mein Mandelbrot-VI für höhere Zoomstufen aufzubohren...

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.08.2010, 11:13
Beitrag #16

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
Ungenauigkeit von Floatingpoint (allgemein)
' schrieb:Hallo Rolf,

hast du einen Link auf diese Library?
Bin gerade an etwas ähnlichem dran, um mein Mandelbrot-VI für höhere Zoomstufen aufzubohren...

So auf die Schnelle nicht. Das war eine Diskussion auf der Info-LabVIEW Mailingliste ziemlich sicher mindestens 10 Jahre her.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  LV allgemein: Labels der VIs im block diagram immer anzeigen laumann 10 8.686 05.02.2016 09:44
Letzter Beitrag: Freddy
  Systeminformationen Allgemein ermitteln dbuckl 14 8.058 24.03.2015 10:20
Letzter Beitrag: GerdW
  [Allgemein] Hilfe bei Euler-Winkeln Yantit 1 2.978 09.03.2011 08:17
Letzter Beitrag: Yantit
  LabVIEW Allgemein kcccp 11 10.374 06.07.2009 15:00
Letzter Beitrag: kcccp
  DataSocket allgemein Snoop2000 3 4.634 16.04.2008 03:58
Letzter Beitrag: thomas.sandrisser
  Reihenfolge von 2 Case-Strukturen bzw. Case-Struktur allgemein Bob 2 5.161 10.08.2007 14:52
Letzter Beitrag: Bob

Gehe zu: