Domino 9 und frühere Versionen > ND6: Entwicklung

Datum und Zeitbrechnung

<< < (4/9) > >>

Semeaphoros:
Axel, wenn es eine allgemein gültige Lösung gäbe, wäre diese schon längstens in den Programmiersprachen oder unterdessen möglicherweise bereits auf Professorebene implementiert. Kurz zusammengefasst ist das Problem mit einer solche Lösung etwa so zu umschreiben:

Diese Korrektur geht davon aus, dass der Ist-Wert von einem korrekten Soll-Wert um ein Delta abweicht. Die Korrektur versucht nun, dieses Delta zu reduzieren (ein eliminieren ist leider nicht möglich). Dabei ist der korrekte Sollwert ja nicht wirklich bekannt, sondern wird vermutet. Leider kann dabei passieren, dass das Delta statt verkleinert auch vergrössert wird. Werden nun solche mit einem Fehler behafteten Operationen aneinandergehängt, dann zeigt sich das Phänomen der Fehlerfortpflanzung. Mit jeder neuen, korrigierten Operation wird die Fehlerwahrscheinlichkeit auch grösser. Von da kommt die ziemlich strikte Regel, dass solche Korrekturen erst am Endresultat vorzunehmen sind.

Soviel zum allgemeinen, im Speziellen für Zeit und Datum spricht das ganze dafür die NotesDateTime Klasse zu verwenden, anstatt die Berechnungen direkt am Zeitwert durchzuführen, in der Hoffnung, dass die interne Implementation dieser Klasse die Problematik so weit wie möglich berücksichtigt.

Marinero Atlántico:
Jens.
Ich spreche nicht von einer allgemeingültigen Lösung. Bin mir aber ziemlich sicher, dass du in dem Falle von Bernhard eine Menge special-rundungs-math-code in eine spezielle Klasse auslagern kannst. Die mathematischen Operationen über diese Klasse werden natürlich mehr Prozessorenzyklen beanspruchen als einfach mit double zu arbeiten.
Wenn du aber in bestimmten Anwendungsfällen 0.0002 Milisekunden pro mathematische Operation verlierst, dafür aber dein code übersichtlicher wird und du weniger Fehler beim programmieren dieser Logik machst, kann es Sinn machen.

Z.B. gibt es ja in SQL auch den Datentyp Decimal, wo *diese* Floating point Rundungsfehler nicht auftauchen, da du eine fixe Anzahl an Dezimalstellen angeben kannst.

In Java gibt es z.B. die Klasse BigDecimal, die man für Fälle benutzen kann, wo floating point Rundungsfehler problematisch sind:
http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html

Ich werd mal so weit ich es verstehe eine simple Klasse für Bernhards Fall erstellen und ihr entscheidet, ob das jetzt Sinn macht oder nicht.

AFAIK existiert z.B. in einigen Bereichen der Finanzmathematik die fixe Konvention, dass alle reele Zahlen auf 5 Stellen hinter dem Komma gerundet werden, bevor Operationen mit ihnen ausgeführt werden. 100% genau ist das natürlich auch nicht. Aber Bernhard benötigt ja auch nicht eine perfekte Genauigkeit, sondern einfach nur eine andere Unschärfe als die im Kontext von floating point.


später Axel

Marinero Atlántico:
Man kann wesentlich genauere und größere Zahlen als double speichern. Nur eben nicht im Registerspeicher, sondern im Heap Speicher.
Theoretisch müßte es möglich sein einen Großteil des Heap-Speichers zur Definition einer einzigen Zahl zu verwenden. Nur sind dann die Operationen mit dieser Zahl nicht so besonders schnell.
Natürlich ist die Genauigkeit der Zahl dann auch durch die eingesetzte Hardware eingeschränkt. Man kann aber das Genauigkeitsconstraint nach außen verschieben.
Oder man benutzt eine *andere* Unschärfe wie z.B. in Decimal.

Axel

animate:
ich sehe ehrlich gesagt keinen Grund, nicht die NotesDateTime-Klasse zu benutzen.
Kann mir das jemand mal erläutern, bitte?

Tipp:

erstelle zwei NotesDateTime-Objekte mit deinen beiden Daten und ermittle deren Differenz (TimeDifferenceDouble - Methode). Dann bekommst du das auf die Sekunde genaue Ergebnis in Sekunden und kannst es in ein Format deiner Wahl umrechnen (hh:mm, z.B.) und musst dich nicht mit runden, reellen Zahlen, Unschärfe, etc. beschäftigen.

Semeaphoros:
Thomas, volle Zustimmung, das war der Inhalt meines letzten Satzes.

Axel, wenn ich die BigDecimal Defintion richtig gelesen habe, ist das ebenfalls ein Float-Datentyp, der hat im Prinzip genau die gleichen Probleme, vermutlich einfach durch höhere Genauigkeit für die Praxis etwas entschärft.

Was bei Oracle der Decimal-Datentyp genau ist, weiss ich nicht. Ich vermute mal, dass es sich um einen BCD-Datentyp handelt. Der zeigt das Phänomen natürlich deutlich weniger als irgend ein rein binärer Datentyp, hat dafür andere Einschränkungen und leidet vor allem an der Effizienz. Und -- in LotusScript bzw. Notes/Domino gibts den Typ nicht, kommt also geradezu nicht in Frage.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete