Notes rechnet falsch

[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 

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

	}

}

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

[flaite]

Currency ist kein Fließkommatyp. Afaik ist es ein Dezimaltyp.
Heisst: 5 Stellen hinter dem Komma, von denen 3 angezeigt werden.
Viele werden ja den Dezimaltyp aus SQL kennen.
Es gibt viele, die einen solchen Typ für Java 7 fordern.
In Java gibts BigDecimal als genauere Alternative. Ist aber ziemlich schwerfällig mit zu programmieren.
Wenn du ganz am Schluß der Rechnung rundest, sollte es in der Regel keine Probleme geben.

Gruß Axel

[koehlerbv]

Wenn du ganz am Schluß der Rechnung rundest, sollte es in der Regel keine Probleme geben.

Ich befürchte, das wäre kontraproduktiv: Wie willst Du runden? Mit welcher Genauigkeit? Wenn jemand 500.001 Cent in 2-Cent-Stücken bestellt, wirst Du einen anderen Maßstab ansetzen müssen als bei 700 EUR in 200 EUR-Scheinen ...
Dann doch lieber auf Ganzzahlen ausweichen. Es ist ja unterm Strich auch wurscht, was man als Basiseinheit hernimmt: 1 Cent oder 1 EUR. 70.000 Cent bekomme ich ja auch nicht in 20.000 Cent-Scheinen (so rein mathematisch ...).

Bernhard

[flaite]

Wieso?
Wenn man etwas in einer ganzen Stückelung benötigt, kann man es auf 0 Stellen hinter dem Komma runden.
Ich wurde schon 2 mal überzeugt, als ich glaubte wir bräuchten BigDecimal und jemand hat mich dann überzeugt, dass es mit der korrekten Rundungsoperation an der richtigen Stelle auch mit double geht.

[koehlerbv]

Wieso?
Wenn man etwas in einer ganzen Stückelung benötigt, kann man es auf 0 Stellen hinter dem Komma runden.

Ich glaube, Du hast Dir nicht mal mein Beispiel oben rechnerisch durch den Kopf gehen lassen. Wo willst Du denn da runden, ohne (fehlerhaft) genau das falsche Ergebnis (500.001 Cent kann ich in Zwei-Cent-Münzen bekommen) zu erhalten? Genau die Rundung ist hier doch das Kontraproduktive ...

Bernhard