Domino 9 und frühere Versionen > ND6: Entwicklung

Summenbildung einer Ansicht

<< < (3/4) > >>

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  ;D)

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete