Domino 9 und frühere Versionen > ND6: Entwicklung

Datum und Zeitbrechnung

<< < (3/9) > >>

koehlerbv:
Hallo Matthias,

ich arbeite in etlichen Projekten exzessiv mit Datum-/Zeit-Werten (Beispiel Zeiterfassung, bei der nun wirklich nichts schiefgehen darf) , ich weiss also, wovon ich rede. Jens hat es im ersten Teil seines Postings schon gut beschrieben: Der Prozessor kann nur endlich viele Stellen verarbeiten, und DT-Angaben werden als Datumsseriennummern gespeichert. Gerade der durch Fraction herausgefilterte Bruchteil (!) des Tages kann dazu führen, das weitere Rechenoperationen mit diesem Wert, die eigentlich ganze Zahlen ergeben sollten (hier: Minuten), doch wieder reelle Zahlen ergeben. Um dies nachzuvollziehen (gerade, wenn man keine reellen Datenreihen zur Verfügung hat), braucht man sich nur entsprechende Datenreihen generieren.

Bernhard

TMC:
Hi Bernhard,

sorry, aber ich verstehe immer noch nicht ganz, warum hier eine Rundung erforderlich ist.

Die Designerhelp zu Fraction sagt ja auch:

--- Zitat ---Tip  It is always true that Fix(numExpr) + fraction(numExpr) = numExpr.
--- Ende Zitat ---

Was ja indirekt aufgrund Deiner Vorgehensweise heißen würde, man müsste Date/Time-Werte generell runden nach deren Bearbeitung, also unabhängig davon ob man das nun mit Fix/Fraction zusammensetzt oder nicht.

Wäre schön wenn Du als "Beweis" ein Beispiel nennen könntest. Wäre sicherlich auch für andere hilfreich, die sich mit Date/Time rumschlagen.

Danke,
Matthias

koehlerbv:
Hallo Matthias,

es geht hier nicht um das Problem, Datum-/Zeitwerte generell runden zu müssen, sondern um den Umgang von Notes (bzw. prinzipiell: Den begrenzten Möglichkeiten, in einem binären System reelle Zahlen abzubilden) mit reellen Zahlen.

Heute (12.06.2005) früh um 8 Uhr liefert @Now oder in LS Now die Datumsseriennummer 38515,3333333333 zurück. Wir reden hier ja darüber, Operationen mit derartigen gebrochenen Zahlen (mit denen wiederum Operationen ausgeführt werden) wieder auf ganze Zahlen sicher zurückzuführen. Sicher heisst da für mich: Round mit den entsprechenden Parametern liefert mir wieder eine Ganzzahl, die ich dringend brauche. Diese Sicherstellung muss zudem an der frühestmöglichen (Rechen-)Operationsstelle erfolgen (logischerweise, da es ansonsten ggf. mit jedem Rechenschritt immer schlimmer wird).

Ich zitiere nochmals Semeaphoros, der genau das formuliert hat, was auch ich für sichere Programme an dieser Stelle für erforderlich halte:

--- Zitat von: Semeaphoros am 10.06.05 - 23:13:49 ---Unschärfe kann dort durch das Rundungsproblem des Prozessors entstehen, da die Register nur endliche Grösse haben. Bernhards Schlussrundung schärft das schätzungsweise zu etwa 80%, um das noch ein wenig höher zu schrauben, müsste man mit einem Epsilon-Wert arbeiten und die Rundung noch ein wenig weiter "rechts" ansetzen.
--- Ende Zitat ---
Das nach "rechts verschieben" kann man sich aber angesichts der möglichen Unschärfen dank Round aber getrost schenken - wichtig ist das ergebnisnächste Runden ("ergebnisnah" heisst für mich hier: Genau an der Stelle, an der die Unschärfe auftreten kann).

Bernhard

Marinero Atlántico:
Vorschlag (evtl. naiv) kannst du nicht eine Skriptlibrary erstellen.
In Pseudocode und die Variablennamen stimmen vermutlich auch nicht:

Name: SafeMath

--- Code: ---function division(divisor as Integer, dividend as Integer, round As Integer) As Double
division = dividend/divisor
division = round (division, round)
end function

--- Ende Code ---
etc...
Und die problematischen Rechenoperationen grundsätzlich über diese Funktionen laufen lassen. Klasse geht natürlich auch.

Gruß Axel
 

koehlerbv:
Das ist ganz sicher gar keine schlechte Idee, Axel. Nur die Datentypen sind unpassend (Integer als Übergabewert und als Ergebnis Double). Ich sehe aber gerade, dass ich in meinem Code-Beispiel auch den Fehler gemacht habe, das erwünschte ganzzahlige Ergebnis einer Double-Variablen zuzuweisen - was natürlich kontraproduktiv ist.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete