Summenbildung einer Ansicht

[0xse]

Wie kommt Notes auf solche Summen? Und wie lässt sich das verhindern?

[diali]

wird die 0,06 berechnet und nur mit 2 Nachkommastellen dargestellt?
Wie sieht die Formel der Spalte mit den 0,06 aus?

Eventuell hilft in der Spalte ein @Round( Zahl ; 0,01 ).

[0xse]

Da steht im Moment ein @Round(@TextToNumber(Gebuehren)*100)/100 drin.
Das Ergebnis kann nicht mehr als zwei Nachkommastellen haben.

Und das habe ich nur eingebaut, um zu testen ob es daran liegt. Vorher stand da nur ein @TextToNumber(Gebuehren) drin.

[klaussal]

Da würde ich den Rundungsfaktor in @round einbauen.

[diali]

Wie ist denn Deine Spalte konfiguriert (Zahl mit 2 Nachkommastellen)?

[0xse]

Das ist aber auch nur ein Workaround mit den Spalteneinstellungen. Zugegeben, er funktioniert gut Aber warum rechnet Notes falsch?

[klaussal]

* 100 / 100 ist doch das Gleiche wie vorher. Welcher Sinn steckt denn dahinter ?

[klaussal]

Aber warum rechnet Notes falsch?

Nimm mal einen Taschenrechner und errechne 1) die Wurzel auf 5 und lass das Ergebnisse im 2) Schritt dann quadrieren. Eigentlich sollte da jetzt wieder 5 herauskommen. Das macht aber kaum ein Rechner. Die meisten verrechnen sich da in der x-ten Stelle.

[diali]

@klauss
@Round(@TextToNumber(Gebuehren)*100 ) /100

macht folgende Rechenschritte:
- Zahl mal 100
- Runden auf ganze Zahl
- teilen durch 100

Ist nicht gleich *100 / 100

[diali]

@Oxse
Du setzt aber keinen Pentium I der 1. Generation ein

[0xse]

Nein, keine dieser CPU auf denen "Bill sucks!" steht ^^

Das mit dem @Round(var * 100) / 100 müsste für den Interpreter der Formelsprache schneller gehen, als wenn er noch eine Formatangabe interpretieren muss. Und bei ner DB in die täglich 30k Datensätze kommen, soll das doch ordentlich laufen

[wflamme]

Notes rechnet da nicht falsch, sondern so richtig es kann. Liegt an der Art, wie alle Computer Dezimalzahlen intern als binäre Fließkomma-Formate (also Mantisse & Exponent) ablegen. Vieles, was dezimal als runde Zahl erscheint, wird dann periodisch und führt zu Rundungsfehlern.

->http://www.computerbase.de/lexikon/Flie%C3%9Fkomma-Zahlen

(Ach tut das gut, mal mit 25 Jahre altem Wissen protzen zu können  )

[flaite]

Ohne jetzt als Java-Freakshow abqualifiziert zu werden, aber...
Wir haben diese Diskussion alle 4 Wochen.
Es gibt Möglichkeiten Fliesskommazahlen genauer darzustellen. java.math.BigDecimal ist so ein Beispiel. Ich hab letztesmal für *empirical evidence* gesorgt. Wie das genau funktioniert weiss ich nicht. Jedenfalls nehme ich Wetten an, dass ich Operationen mit Fliesskommazahlen mit 1000 Nachkommastellen ohne Rundungsfehler auf einem Computer abbilden kann.
Z.B. kann ich auch in dem SQL-Datentyp Decimal die Anzahl der Nachkommastellen beschränken. Das ist dann keine Fliesskommazahl mehr.
Wenn ich aber als Input nur Zahlen mit 5 Nachkommastellen erwarte, dann wird zumindest bei Adition und Subtraktion das Ergebnis genauer, da eben die Menge der Zahlen deutlich eingeschränkt wird. Bei *richtigen* Fliesskommazahlen ist diese Menge ja unendlich. Wenn ich aber sage, dass es nur Zahlen mit 5 Nachkommastellen gibt, dann ist diese Menge nicht mehr unendlich.
Ich meine auch, dass es Konventionen in Finanzmathematik gibt, dass nach jeder Operation auf 5 Stellen gerundet wird. Auch wenn das natürlich zu unsauberen Ergebnissen führt.
 

[Semeaphoros]

Axel, sorry, aber dieses Posting ist Dummfug. Natürlich lässt sich das technisch anders lösen mit andern Vor- und Nachteilen, das ist aber nun mal in Notes nicht gemacht. Notes verwendet die von Wolfgang angegebene Fliesskommadarstellung und die hat diese Ungenauigkeiten, die sich dann eben - dank Fehlerkumulation und Fehlerfortpflanzung - genau so auswirkt wie beschrieben. Und wenn Du selber ja schreibst, dass Du nicht weisst, wie das genau funktioniert, dann gibt es auch keinen Grund, darüber überhaupt Worte zu verlieren. Das zusätzlich dazu, dass eine Diskussion an dieser Stelle sowieso unnütz ist, da wir die Implementation in Notes sowieso nicht beeinflussen können.

[flaite]

Hallo Jens,

ich habe nur auf ein paar weitere Möglichkeiten hingewiesen, mit dieser Fragestellung in einem weiteren Kontext umzugehen. Ich für meinen Teil muß als Anwendungsentwickler nicht genau wissen *wie* alles funktioniert. Ich muß nur wissen wie ich es anwende. Nicht unbedingt die inneren Details. Oft führen dann natürlich Probleme bei der Umsetzung dazu, dass ich mich tiefer um das *interne wie* kümmern muß. Solange alles funktioniert, sehe ich das nicht als zwangsläufig an. Das interessante an den Job ist für mich gerade, dass sich meine Vorstellungen darüber wie meine Anwendungen funktionieren niemals mit der Wahrheit decken wird, ich mich aber annähere.
Manchmal ist es gut die Dinge in einen neuen Kontext zu stellen. Natürlich ist das anstrengend. *Exploratives Denken* (das Gegenteil von Spätscholastik). Mir geht es nicht darum, Recht zu haben. Wolfgang hat ja damit angefangen, den Kontext der Fragestellung zu erweitern. Und java.math.BigDecimal ist seit Notes6 Bestandteil jedes NotesClients und jedes NotesServers.
Natürlich kann man das nicht in Ansichten verwenden und überhaupt dürften die Use Cases für javaBigDecimal in typischen Notes-Anwendungen sehr unwahrscheinlich sein. Ausser bei JDBC mit neueren Treibern.
Axel

[wflamme]

Nein, er hat schon recht: Ich war da etwas unpräzise. Solche Rundungsfehler sind nicht zwingend  - es gibt ja auch Programme wie Mathematica und Maple, die symbolische Mathematik beherrschen und damit absolut genau rechnen (es sei denn, man befiehlt es ihnen ausdrücklich anders).

Sagen wir mal so: die Fließkommadarstellung ist in der IT aus zwei Gründen der mit Abstand beliebteste Standard:

• bis auf wenige Ausnahmen deckt sie alle praktischen Anforderungen ab
• sie wird von der üblichen Universal-Hardware unterstützt (integrierte, numerische Fließkommaprozessoren)

So besser?

[flaite]

So besser?

Wenn ich hier Beiträge von Leuten ergänze, mache ich das nicht, um die Beiträge zu bewerten, sondern im Dienste der Wissenschaft.
So ähnlich wie die Blues-Brothers im Namen des Herrn unterwegs waren.   
Gute Intentionen. Viele Blechschäden. 

• bis auf wenige Ausnahmen deckt sie alle praktischen Anforderungen ab
• sie wird von der üblichen Universal-Hardware unterstützt (integrierte, numerische Fließkommaprozessoren)

Vor allem ist der Datendurchsatz durch den Prozessor wesentlich schneller, da Rechnnen mit double, float Registeroperationen sind. BigDecimal findet z.B. im Heap statt (langsamer). Sobald ich Zeit dafür gefunden habe wie das funktioniert, poste ich das mal.

Axel

[flaite]

absolut genau rechnen

Glaub ich nicht. Irgendwo ist die Grenze der Hardware. Die Anzahl der Ziffern hinter dem Komma ist theoretisch unendlich. Und damit muß es zwingend eine Grenze des physischen Speichers der Hardware geben, ab dem die Zahlen einfach nicht mehr genau dargestellt werden können. 
Die Budgetgerade verschiebt sich einfach nur sehr weit nach rechts, wenn sie von dem verfügbaren Heap-Speicher und nicht mehr durch Register-Implementierungen abhängig ist. Sie ist aber noch da.

[wflamme]

Nee, da irrst Du Dich.
Pi zB hat unendlich viele Stellen und ist nichtperiodisch. Damit sollte Deiner Meinung nach kein Rechner mit Pi rechnen können, ohne Rundungsfehler zu machen.

Aber lassen wir mal Maple sprechen:

> solve(x=25794*Pi/176,x);

    12897/88*Pi


> solve(x=tan(Pi^(y/e)-2), y);

   ln(2+arctan(x))*e/ln(Pi)

 

[flaite]

Home Run. 

Das war aber auch ein 10 kyo Trick Move.

> solve(x=25794*Pi/176,x);

    12897/88*Pi


> solve(x=tan(Pi^(y/e)-2), y);

   ln(2+arctan(x))*e/ln(Pi)

Experten Tesujis. (Tesuji = Pattern für Go Nahkampf-Taktiken, komplexes Thema).

Hab ich wieder was gelernt.

Ich bin mir ziemlich sicher, dass java.math.BigDecimal nicht auf symbolischer Mathematik beruht, sondern auf etwas anderem. Schau mir das irgendwann mal an.

A doubt: Was macht Maple, wenn man z.B. Pi in Dezimaldarstellung anzeigen will?
Zeigt es alle Stellen