Domino 9 und frühere Versionen > ND6: Entwicklung

Notes rechnet falsch

(1/2) > >>

Thunder:
Hallo Notesgemeinde,

ich programmiere zur Zeit eine Geldbestellungsanwendung, in der meine User Geld per Maske bestellen können. Ist eine einfache Tabelle, in der man hinter dem Stückelungswert (500EUR, 200 EUR, 100EUR,...) einfach den Betrag eingeben kann. Die Feldvalidierung kontrolliert, ob dieser Betrag den max.Bestellwert nicht übersteigt und ob er überhaupt möglich ist.
650 EUR kann man zB nicht mit 500EUR-Scheinen bekommen  ;)
Also habe ich folgende Formel.  wenn Wert/500 = @Integer(Wert/500) dann alles gut.
Das klappt auch soweit, nur gibt es bei den kleineren Beträgen scheinbar Rechenprobleme mit Lotus Notes. zB bei den 0,1 EUR.Ich will 30Cent also 0,3EUR in 0,1EUR Stückelung bestellen.
Diesen Wert lässt Notes nicht durch die Validierung-also habe ich mal geforscht.

0,3 / 0,1  = 3
@Integer (0,3 / 0,1) = 2      ???

Das kann man sehr leicht mit einem berechneten Feld darstellen.
Wie kommt das und was kann ich machen?

Gruß
Remko

koehlerbv:
Mit R5 wäre das nicht passiert  ;D

Spass beiseite: R5 rechnet hier noch richtig, R6 bringt einen Rundungsfehler. Das Ergebnis ist also 2,999999999999999999999999997 (oder so), @Integer macht daraus 2. Die neue Formula-Enhine von R6/R7 weist also einen weiteren Fehler auf.

Interessanterweise: Wenn Du die korrekten Werte verwenden würdest (also 0,01 EUR für 1 Cent), dann passt es auch wieder.

Vorschlag für einen Workaround (es ist natürlich übel, dass man sowas machen muss): Wenn es um Cent-Beträge geht, multipliziere die Grundwerte vorher mit 100 und mache erst dann Deine Prüfung.

Bernhard

Thunder:
..ist natürlich auch eine Lösungsmöglichkeit.
Das reicht mir aber soweit.

thx
Remko

flaite:
Ich tippe da eher auf die typischen Rundungsfehler von Fließkommazahlen.
Diese treten in jeder Programmiersprache auf, die Fließkommazahlen benutzen.
(versucht google). Man sollte das verstanden haben.
Möglicher Workaround besteht darin, dass du @Round statt Integer verwendest.


Gruß an Jens und Wolfgang Flamme.

Btw:
Dieses kleine Javaprogramm liefert auch einen ungenauen Wert:

--- Code: ---public class Test {

/**
* @param args
*/
public static void main(String[] args) {
System.out.println(0.3 / 0.1);
// TODO Auto-generated method stub

}

}

--- Ende Code ---
nämlich -> 2.9999999999999996

Nicht das Java immer Recht hätte, aber das hat was mit der spezifischen Implementierung von Fließkommazahlen in der jeweiligen Sprache zu tun. Ungenauhigkeiten ab einen gewissen Punkt sind zwangsläufig.

koehlerbv:
Eigentlich ist es keine Lösungsmöglichkeit, da Dir diese Unschärfe selbst bei Zahlen mit wenigen Nachkommastellen schon passiert und Du daher nie weisst, wann diese Ungenauigkeit wieder zuschlägt. Für die Geldbestellung ist die garantierte Wandlung zu Ganzzahlen aber auf jeden Fall eine Lösung. Obwohl: Man hat ja jetzt schon ein komisches Gefühl, was wohl bei 0,01 * 100 herauskommt ... Wirklich 1 EUR? Oder doch "etwa 1 EUR" ....

Interessanterweise versagt auch LS mit Fraction bei der Division 0,3 / 0,1 ... Mit Variablen vom Typ Currency funktioniert's dann aber doch. LS wäre somit also auch noch eine Alternative.

@Axel: Jo, Fliesskommazahlen und die Schweissperlen, die dabei der Prozessor und somit die Programmiersprachen bekommen, sollten schon verstanden sein. Und die "3" ist sowieso immer kritisch ...
Nur: Die Stellenanzahl hinter dem Komma ist hier arg klein. Und dass man es schon mal besser verstanden hat, zeigt die Gegenprobe mit R5. DAS ist das, was mich hier so stört.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite