Analogkomparator

Antworten
irrerpolterer
Beiträge: 102
Registriert: Mittwoch 19. November 2008, 16:20

Analogkomparator

Beitrag von irrerpolterer » Mittwoch 20. Juli 2011, 08:55

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
Dateianhänge
normiert.prj
(3.36 KiB) 325-mal heruntergeladen
Achtung_Komma.prj
(3.08 KiB) 359-mal heruntergeladen

tmm
Beiträge: 392
Registriert: Montag 23. Februar 2009, 06:38

Re: Analogkomparator

Beitrag von tmm » Mittwoch 20. Juli 2011, 09:41

Hallo,

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

Gruß MM

RHH
Beiträge: 22
Registriert: Freitag 5. Februar 2010, 08:36
Wohnort: Bayern / Nürnberg

Re: Analogkomparator

Beitrag von RHH » Freitag 22. Juli 2011, 12:11

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.
Gesetze der Programmierung:
Erweist sich ein Programm als nutzlos, muß es umfangreich dokumentiert werden.
Der Nutzwert eines Programms steigt antiproportional zur Menge seiner Ausgabedaten.

Grüße aus Franken
Roland


http://www.rhh-planet.de/

irrerpolterer
Beiträge: 102
Registriert: Mittwoch 19. November 2008, 16:20

Der Analogkomparator ist ok.

Beitrag von irrerpolterer » Freitag 22. Juli 2011, 12:57

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

Antworten

Zurück zu „Thema: Schaltung und Bauteile“