Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: cococo69 am 30.03.04 - 15:17:44
-
Hallo,
in einem berechneten Feld (A) wird das Ergebnis aus 21 / 6 korrekt mit dem Wert 3,5 ausgegeben. Dieses Ergebnis verwende ich in einem weiteren berechneten Feld mit @Round(A), das Ergebnis ist erstaunlicherweise 3 und nicht wie anzunehmen 4 ???
Lasse ich Notes jedoch direkt @Round(3,5) rechnen, ist das Ergebnis 4!
Wie kommt das?
Gruß
Armin
-
Was hast Du denn für eine Version ? Bei mir kommt bei
@Round (Zahl1 / Zahl2) mit Deinen Werten 4 heraus ...
Bernhard
-
Hi,
wenn ich mir die Hilfe so ansehe:
If the first non-significant digit is 5, and all subsequent digits are 0, the last significant digit is rounded to the nearest even digit. See the example that follows.
Print Round(4.45, 1) ' Prints 4.4
rundet die Funktion bei einer 5 ab...
oder auch:
Beispiele: @Round
1. Dieses Beispiel ergibt 1.
@Round(1,499)
2. Dieses Beispiel gibt 2 zurück.
@Round(1,5)
Funktioniert auch so bei mir (4 statt 3) unter 5.07. Selbst das gerundete Feld nochmal gerundet funktioniert. Was steht denn in der Formel des zweiten Feldes?
Gruß
sloe
-
Hallo,
habe die Sache nochmal genauer untersucht.
An der Version liegt es nicht - getestet mit 3 Versionen (4, 5 und 6).
@Round(21/6) ergibt bei mir auch in allen Versionen 4!
Irgend wie muss das mit der internen Speicherverwalung zu tun haben!?
Der Wert 21 setzt sich folgendermaßen zusammen:
(6*2)+1+(5/3)+(9/3)+(10/3)
Als Ergebnis wird 21,00000000 ausgegeben!
Der Wert 6 ist das Ergebnis von
5+1
Lasse ich Notes nun
@Round(((6*2)+1+(5/3)+(9/3)+(10/3)) / (5+1))
rechnen, ist das Ergebnis immer 3 ??? ??? ???
Wie kann ich dies meinem Chef nur beibringen?
Gruß
Armin
-
Ist wirklich komisch, ich probier auch schon alle Kombinationen durch. Kann es sein, daß Notes intern durch die Brüche nicht mit 3,5 rechnet, sondern mit 3,4999999... ?
-
Jo, da bleibt was auf der Strecke bei 5/3 oder 10/3).
Notes ist rechenschwach. Dass es für sowas auch nicht gemacht wurde, ist dabei ein schwacher Trost.
Bindet am besten 1-2-3 oder Excel et.al. für sowas ein, um kompliziertere Sachen berechnen zu lassen. Ansonsten hilft es nur, mit normierten Zwischenergebnissen zu arbeiten (ggf. wegen der Übersichtlichkeit in ein LS-Modul auslagern). Die Angst bleibt dabei aber immer ...
Bernhard
-
Tja,
es kommt auf die Reihenfolge an:
So geht es
@Round(((6*2)+1+(9/3)+(10/3)+(5/3)) / (5+1))
Notes und Rechenoperationen ist so wie Notes und Drucken - nur schlimmer!
Andreas
-
@Glombi :
Du hast einfach nur die Reihenfolge der Brüche vertauscht, oder ?
Aber wie ich das verstanden habe, kommen die Werte ja aus einem Dokument, d.h. ich kann in der Formel so nicht sicherstellen, daß eine bestimmte Reihenfolge eingehalten wird.
Wenn der Teiler bei den Brüchen immer identisch ist, dann sollte man die Formel besser so aufbauen :
@Round(((6*2)+1+((5+9+10)/3)) / (5+1))
-
Da die Reihenfolge sicher nicht garantiert werden kann, würde ich die Finger von Feldern lassen und das ganze auslagern und bei jedem Rechenschritt das Runden überwachen.
Und auch damit kann Notes noch nicht richtig rechnen ;D
Bernhard
-
Ich wollte nur darauf hinweisen, dass bei anderer Reihenfolge der Summanden Notes (zufällig) richtig rechnet. Das kann natürlich keine Lösung sein.
Mit Notes Rechenoperationen durchzuführen halte ich nicht für sonderlich empfehlenswert.
Andreas
-
Also mal zuerst wegen 1-2-3 oder Excel für solche Berechnungen:
Lehrerin: "Deine Rechenaufgaben sind ja alle falsch! Wie kommt denn das?"
Schülerin: "Was kann ich für die Bugs in Excel?"
****
Kurz: es ist nicht gesagt, dass der Einsatz eines Spreadsheets tatsächlich bessere Lösungen bringt. Keines der genannten Produkte beherrscht irgend eine Form von BCD-Arithmetik und ist damit der Problematik der Umrechnugspräzision ausgesetzt, die sich - wie man bei den theoretischen Informatikern nachlesen kann - nicht beheben lässt. Genauso, wie wir in der Dezimalschreibweise gewisse Zahlen nicht darstellen können (eindrittel zum Bleistift, da wir nicht unendliche 3er schreiben können) gibt es genauso Werte, die sich binär bei einer beschränkten Registerlänge (und die ist für einen realen Rechner unvermeidlich) nicht korrekt darstellen lassen. Wir arbeiten also in jedem Falle - egal welches Produkt - mit Näherungswerten. Bei längeren Berechnungen machen sich dann sofort die Probleme der Fehlerfortpflanzung bemerkbar. Um dies zu vertuschen, werden in den Implementationen in der Regel die letzten paar Binärstellen nicht angezeigt, sondern per Rundung "zum Verschwinden" gebracht.
Das am Anfagn erwähnte Resultat von 3,5, welches mit Round auf 3 runterrutscht, ist intern offensichtlich ein 3,499999999999999, welches durch die oben erwähnte Ausblendung als 3,5 darstellt.
Ganz typisch für dieses Phänomen ist ebenfalls das von Glombi 1.0 festgestellte Verhalten, dass bei Umstellung der Rechenreihenfolge das Ergebnis beeinflusst wird, das ist die Folge des permanenten Abschneidens von Werten weit hinter dem Komma, das bei Umstellung der Rechenreihenfolge an anderer Stelle oder gar nicht auftritt.
Ein relativ einfach einsehbares Beispiel für ein ähnliches Phänomen:
Rechnet man
100 ! / 99 !
bekommt man schon beim Zähler hoffnungslos einen Overflow, wenn mans so rechnet, wie es da steht.
Aendert man die Reihenfolge so, dass man abwechslungsweise einen Faktor vom Zähler und einen vom Nenner nimmt, dann gelingt die Ausrechnung:
100 / 99 * 99 / 98 * 97 / 97 ..... usw. nirgends auch nur der geringste Over- oder Underflow. Soviel zum Einfluss der Reihenfolge.
Wie gesagt, die genannten Spreadsheets sind von diesem Problem genau gleich betroffen wie Notes selbst (nur ziemlich sicher nicht unbedingt bei den gleichen Beispielen, da die internen Engines unterschiedllich arbeiten)
-
Danke Jens für die wie immer lehrreiche Darstellung!
Ich habe es mal ausprobiert. Es ist
@Round(3,49999999999999999999999999999999999999) = 4
und
@Round(3,4999999999999999999999999999999999999) = 3
Laut KBASE gilt übrigens:
"Notes is designed to use 15 significant digits"
Andreas
-
Wow, wie lange hast Du ausprobiert?
Da ja nicht die dezimale sondern die binäre Darstellung massgebend ist, ist es gar nicht so selbstverständlich, dass man so ohne weiteres auf die Beispiele stösst.
-
Wow, wie lange hast Du ausprobiert?
Gerundet, so ca. 3 Minuten ;)
-
Aha, gemäss Titel des Thread ist das von 3,5 abgerundet ... ;D
-
Ich habe es weiter untersucht:
Es ist
3,49999999999999 = 3,5
und
3,4999999999999 = 3,4999999999999
Wie: Man gebe das als Vorgabewert in ein Zahlfeld ein und speichere die Maske. Dann wieder öffnen.
Mit Notes kann man dann wahrscheinlich auch die Quadratur des Kreises beweisen ;D
-
Ich habe es weiter untersucht:
Es ist
3,49999999999999 = 3,5
Moment, langsam. Da müsste man dann noch dahinter schauen, was da wirklich abgespeichert ist. Kann tatsächlich sein, dass durch die genannten Effekte der Wert geändert wird, muss aber nicht, möglich, dass nur die Darstellung geändert ist. Das nur so der Vollständigkeit halber.
-
Du hast recht, es wird 3,5 angezeigt, intern wird (irgendwo) der Wert 3,49999999999999 verwendet.
Wenn ich als Wert
3,5 - 3,49999999999999 nehme, zeigt er
1,0214051827E-14 an.
Erst bei
3,5 - 3,49999999999999999999999999999999999999
ist es wirklich 0.
Aber irgendwie ist das für den User nicht ganz verständlich, wenn er vor dem Rechner sitzt...
-
Natürlich ist das für den User nicht verständlich, technisch aber leider überhaupt nicht zu beherrschen.
Welcher User glaubt Dir das, wenn Du ihm sagst, dass der Taschenrechner ungenau rechnet? Ist dasselbe Phänomen, und doch glauben fast alle Benutzer dieser Dinger, dass die wirklich richtig rechnen ....... tja .....
-
Der Taschenrechner kommt aber zumindest mit der von cococo genannten Formel klar. 1-2-3 auch (incl. runden). Trotzdem hat Jens natürlich vollkommen Recht - intern werden die Ergebnisse bei entsprechenden Voraussetzungen nur als "Teil der Wahrheit" weiter verarbeitet.
Ein denkbares Verfahren (was aber auch nicht garantiert, das es unter allen Umständen funktioniert !!!) ist, die Zwischenergebnisse normiert zwischenzuspeichern. Aber auch hier Fallstricke ! Ein simples Beispiel:
1/3 + 1/3 + 1/3 = 1,00. Soweit okay. Wenn man aber hier die drei Zwischenergebnisse "sicherheitshalber" jeweils auf zwei Dezimalstellen rundet, dann wird daraus
0,33 + 0,33 + 0,33 = 0,99. Nicht gerade befriedigend. Besser, aber eben auch nicht sicher - sind da Taschenrechner, 1-2-3, Excel und Konsorten.
Wenn die Stellengenauigkeit eine sehr grosse Rolle spielt, ist überall (nicht nur in Notes) viel Strategie gefragt.
Bernhard
PS: Wie war das bei der Euro-Umstellung ? Auf wieviel Stellen mussten da die Zwischenergebnisse gerundet werden ? Fünf, glaube ich ...
PPS: COBOL müsste doch eigentlich "perfekt" rechnen können ? Vielleicht sollte man sowas zwischenschalten ;D
-
Was soll's! Ich habe eh immer nur mit Buchstaben "gerechnet" - lateinische und griechische, da gibt es nur einige wenige und die Probleme liegen in weit höheren Dimensionen ;D
Andreas
P.S.: Nicht das einer sagt: "Algebraische Symbole werden benutzt, wenn man nicht mehr weiß, worüber man redet."
-
Bernhard: Gewisse Taschenrechner kommen vielleicht mit Cococo's Rechnung zurecht, dafür aber mit anderen nicht. Cobol hat da ein paar Schwierigkeiten weniger, kommt aber ins Schwitzen, wenn man mal einen Sinus oder so braucht, und wenn mans dann über den COMPUTE Befehl absetzt, ist die Wahrscheinlichkeit gross, dass die gewählte Implementation auch wieder unsere Schwierigkeiten zeigt (vielleicht nicht bei der gleichen Rechnung, je nach Implementation).
Nur so als Hinweis: die Experimente, die Andreas Glombi 1.0 hier gemacht hat, lassen sich auch auf Taschenrechner durchrühren und ähnliche "Unregelmässigkeiten" beobachten. Man lese nur mal die Handbücher von teureren Geräten etwas genauer durch, das steht normalerweise irgendwo drin.