Seite 1 von 1

Analogkomparator

Verfasst: Mittwoch 20. Juli 2011, 08:55
von irrerpolterer
Hallo!

Kann noch jemand diese Situation beim Analogkomparator beobachten?

1. Rechnung: 1+0,1*10=2 ungleich 2+0=2 laut Analogkomparator, genauso 1+0,1*10=2 ungleich 2


2. Rechnung: Ich habe die Werte von oben normiert mit Faktor 1000, um etwaige Nachkommastellen zu unterdrücken. Zuvor habe ich das Ergebnis noch als Analogwert per Value(string zu Gleitkomazahl) gewandelt. Dann klappt es:

1000*(VAL(1+0,1*10=2))=2000 ist gleich 1000*(VAL(2))=2000

Ich habe die Beispielprojekte angehängt.

Grüße

Re: Analogkomparator

Verfasst: Mittwoch 20. Juli 2011, 09:41
von tmm
Hallo,

bei mir hier ist 2 gleich 2 (mit oder ohne $VAL-Modul)

Gruß MM

Re: Analogkomparator

Verfasst: Freitag 22. Juli 2011, 12:11
von RHH
Hallo,
ich kenne das Problem auch in anderen Programmiersprachen. Nun, jeder Rechner macht abhängig von seinem Prozessortyp und evtl. vom Betriebssystem mehr oder weniger markante Rundungsfehler. So was hat man auch in Excel, VBA, VB und sonstigen Programmen. Da man in PL keinen Einfluss auf das verwendete Datenformat hat, wird dies wohl übergeordnet durch das System bestimmt. Bei Gleitkommaoperationen sind datenabhängige Effekte wie Denormalisierung oder Absorption möglich. Guck mal bei Google nach. Ich vermute tatsächlich, dass bei deinem Beispiel ein Rundungsfehler so ca. an 32sigster Stelle nach dem Komma passiert. Klingt absurd, weil man diese überhaupt nicht braucht. Eigentlich sollte das Programm (hier PL) die Stellen nach dem Komma, welche es nicht mehr anzeigen kann, auch abschneiden. Du kannst den Fehler nämlich hier nicht darstellen bzw. lokalisieren (max. 12 Stellen).

Wenn du in deinem Beispiel einfach im Ergebnis der Fehlerhaften 0.1 x 10 + 1 Berechnung von String / auf V wandelst funktioniert es. Dann werden nämlich die fehlerhaften Stellen weit nach dem Komma beseitigt und das gewandelte Ergebnis wird vermutlich im System als Integer weiterverarbeitet, bzw. ist dann vielleicht auch ein bereinigter Gleitkommawert. Klingt unsinnig, funktioniert aber. Das mit x 1000 kannst du dir sparen. Man weiß auch nicht, ob PL am Eingang des Vergleichers verschiedene Datenformate vergleicht, das wäre natürlich auch ein Problem.

Übrigens, für interne Software von Geldinstituten wird deswegen häufig reine Integerverarbeitung gefordert.

An der Uni hatten wir, zu der Zeit in der ich dort beschäftigt war, gigantische Probleme bei extrem komplexen Berechnungen damit. Software wie das sündhaft teuere MatLab, korrigieren übrigens solche Effekte.

Der Analogkomparator ist ok.

Verfasst: Freitag 22. Juli 2011, 12:57
von irrerpolterer
Hallo und Danke für die Antworten!

Ich werde mir in Zukunft immer überlegen, ob ich mit Rundungsfehlern rechnen muß. Dann versuche ich diese abzufangen.

Hätte mir gleich kommen sollen. Das war doch mal ne Apple-Werbung, die haben sich 1992/93 über die Rechenkünste vom intel Pentium lustig gemacht.

Grüße