TDateTime + Mikrosekunden

[3_of_8]

Der 0.Januar 1900 ist der 31.Dezember 1899. ;)

Der Rest ist durchaus interessant, auf Wikipedia steht diese Information nicht (oder ich habe sie mehrfach überlesen).

EDIT: Eine Sache passt da nicht so ganz... Wie soll der Double dann die Zahl 0 aufnehmen?

Und ich würde die Zahl 7 eher so darstellen:

1 1100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 * 2^-50

Wäre dann in deiner Darstellung:

Mantisse: (1) 1100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 (erste 1 implizit)
Exponent: 111 1111 1100 1110

Wo ist mein Fehler?

[Amateurprofi]

Zitat:

Zitat von 3_of_8

Der 0.Januar 1900 ist der 31.Dezember 1899. ;)

Ja, aber das Bezugsdatum von TDateTime ist der 30.Dezember 1899 (nicht der 31.)

Zitat:

Zitat von 3_of_8

Der Rest ist durchaus interessant, auf Wikipedia steht diese Information nicht (oder ich habe sie mehrfach überlesen).

Wikipedia ist schon eine tolle Sache. Jedoch würde ich das nicht gerade als Referenz betrachten, weil die Beiträge von jedem editiert werden können, also jeder seine persönliche Sicht der Dinge dort verewigen kann. (Leider gibt es so viele Leute die so viele Dinge wissen, die so nicht sind)

Zitat:

Zitat von 3_of_8

EDIT: Eine Sache passt da nicht so ganz... Wie soll der Double dann die Zahl 0 aufnehmen?

Wenn alle Bits des Exponenten und alle Bits der Mantisse = 0 sind, dann ist die Zahl = 0. Das Vorzeichen Bit entscheidet dann, ob die Zahl +0 oder -0 ist. (Die FPU kennt tatsächlich positive und negative 0.)

Zitat:

Zitat von 3_of_8

Und ich würde die Zahl 7 eher so darstellen:
1 1100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 * 2^-50

Wäre dann in deiner Darstellung:

Mantisse: (1) 1100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 (erste 1 implizit)
Exponent: 111 1111 1100 1110

Wo ist mein Fehler?

Dein Fehler ist, daß Du davon ausgehst, die Mantisse sei ein simples IntegerFeld.
Stelle Dir die Mantisse so vor, das hinter dem höchsten Bit (das implizit = 1 ist) ein Punkt steht.
Der "Exponent" gibt dann an, um wiewiel Stellen dieser Punkt nach rechts, oder bei negativem Exponenten nach links, verschoben werden muß. Die (nach der Verschiebung) links vom Punkt stehenden Bits bilden dann den Integer-Teil, die rechts vom Punkt stehenden Bits bilden den Nachkomma-Teil.
Beim Exponenten ist noch zu beachten, daß er, wie Intel sagt, "biased" ist. Der wirkliche Exponent ergibt sich aus Exponent minus Bias-Konstante (127 für Singles, 1023 für Doubles, 16383 für Extended).
Zur Darstellung der Zahl 7 :

Code:

0 10000000001 (1).1100000000000000000000000000000000000000000000000000
Also:
Sign            = 0
Biased Exponent = 401H = 1025D (biased)  
True Exponent   = 2
Mantisse nach Verschiebung = (1)11.00000000000000000000000000000000000000000000000000

Und hier nochmal die komplette Definition für Singles, Doubles, Extendeds.
In der Tabelle ist "Integer" das höchste Bit der Mantisse und "Fraction" die auf "Integer" folgenden Bits.
Ein "." bedeutet, daß das vor dem "." stehende Zeichen wiederholt wird, um das Feld zu füllen.
Ein "x" beduetet, daß das betreffende Bit 0 oder 1 sein kann.

@3_of_8:
Ich habe mich bemüht, den folgenden Teil (hoffentlich) korrekt aus den Intel-Specs abzukupfern und zu interpretieren, gib Dir deshalb bitte auch Mühe ihn zu lesen und zu verstehen.
Die Intel-Specs kannst Du Dir hier holen: Intel Specs
Die Definitionen stehen in "Basic Architecture"

Code:

.                  Sign    Exponent         Integer Fraction
                   ----    ---------------  ------  --------------
+Unendlich         0       11.11            1       00.00
+Normale Zahlen    0       00.01 bis 11.10  1       00.00 bis 11.11
+Denormale Zahlen  0       00.00            0       00.01 bis 11.11
+0                 0       00.00            0       00.00
-------------------------------------------------------------------
-0                 1       00.00            0       00.00
-Denormale Zahlen  1       00.00            0       00.01 bis 11.11
-Normal Zahlen     1       00.01 bis 11.10  1       00.00 bis 11.11
-Unendlich         1       11.11            1       00.00
-------------------------------------------------------------------
SNaN               x       11.11            1       0x.xx (2)
QNaN               x       11.11            1       1x.xx
Indefinite         1       11.11            1       10.00
-------------------------------------------------------------------
Länge der Felder
Single             1       8                1 (1)   23
Double             1       11               1 (1)   52
Extended           1       15               1       63


(1) Bei Singles und Doubles wird das Integer-Bit nicht gespeichert.
    Es wird von der FPU implizit angenommen als = 1, außer für die
    Zahl 0 und für Denormale Zahlen. Ich vermute, daß der Exponent
    ausschlaggebend ist (Exponent=0 : I=0, Exponent<>0 : I=1).
    
(2) Mindestens 1 Bit (jedoch nicht das höchste) muß = 1 sein

Und hier das ganze noch mal in Textform :

Normale Zahlen sind die Zahlen, bei denen
1) Im Exponenten mindestens 1 Bit = 1 und mindestens 1 Bit = 0 ist.
2) Das Integer-Bit = 1 ist.

DeNormale Zahlen sind die Zahlen, bei denen
1) Der Exponent = 0 ist
2) Das Integer-Bit = 0 ist
3) Die Fraction <> 0 ist

0 Werte sind die Zahlen, bei denen
1) Der Exponent = 0 ist
2) Das Integer-Bit = 0 ist
3) Die Fraction = 0 ist

Unendlich-Werte sind die Zahlen, bei denen
1) Alle Bits des Exponenten = 1 sind
2) Das Integer-Bit = 1 ist
3) Die Fraction = 0 ist

SNaN Werte (="Signalling Not a Number") sind die Zahlen, bei denen
1) Alle Bits des Exponenten = 1 sind
2) Das Integer-Bit = 1 ist
3) Das höchste Bit der Fraction = 0 ist.
4) Mindestens 1 Bit der Fraction = 1 ist.

QNaN Werte (="Quiet Not a Number") sind die Zahlen, bei denen
1) Alle Bits des Exponenten = 1 sind
2) Das Integer-Bit = 1 ist
3) Das höchste Bit der Fraction = 1 ist.

Der Unterschied zwischen SNaNs und QNaNs ist, daß SNaNs immer eine FPU-Exception auslösen während QNaNs ohne FPU-Exception verarbeitet werden. FPU-Operationen, bei denen NaNs beteiligt werden liefern als Resultat immer eine QNaN. SNaNs können von der FPU nicht erzeugt werden, müssen bei Bedarf also per Software generiert werden.

[3_of_8]

Klingt einleuchtend.

[MStoll]

Ok, ich sehe, das Thema wird weiter diskutiert. Das freut mich ;)

Also um euch meine Verwendung näher zu erklären:
Es geht um Zeitnahme im Motorsport. Bisher lief alles korrekt (mit Millisekunden). Habe ich oft genug an zufällig ausgewählten Beispielen nachgerechnet.

Was verwende ich bei TDateTime-Werten?

Addition (+), Subtraktion (-),
Durschnittsberechnung, also Addition + später Division durch Integer (= Anzahl der Werte)
Maximum, Minimum (d.h. auch Sortieren)

An vorgegebenen TDateTime-Routinen verwende ich im wesentlichen nur:
EncodeTime, DecodeTime

WICHTIG scheint für euch ja zu sein: Ich codiere KEIN Datum rein, ich benutze TDateTime nur für Zeiten.

Wenn ich das recht sehe, kann ich dann also ne ziemlich hohe Genauigkeit erwarten?

Ich hatte noch eine Idee:
Ich wollte evtl. TDateTime durch extended ersetzen. Weiß jemand ob das Probleme mit EncodeTime bzw. DecodeTime macht? Bzw. haltet ihr dies für sinnvoll unter dem Vorhaben, mittels eigener Funktionen "zusätzlich" noch Mikrosekunden reinzucodieren? Werden diese dann bei Addition bzw. Subtraktion korrekt mit einberechnet? D.h. z.b. dass, wenn ich 3 Zeiten habe mit jeweils 400µs und diese addiere, dass dann später bei DecodeDate korrekt ne Millisekunde mehr rauskommt, als wenn ich keine Mikrosekunden reincodiert habe?

Ich bin das auch schon gedanklich selbst durchgegangen, allerdings bringt es sicherlich mehr Sicherheit, mal noch andere Meinungen einzuholen, denn bei Zeitnahme im Motorsport wären Rechenfehler denkbar schlecht.

Vielen Dank für weitere Tips.

Gruß
Michael

[3_of_8]

Ja, wird es. Denn die DateUtils-Routinen erwarten TDateTime und keine Extendeds. Du könntest natürlich einen Typencast vornehmen, aber dadurch gewinnst du gar nichts.

Also entweder die Funktionen selbst neu schreiben oder lassen.

Wobei ich sagen muss, dass die Genauigkeit eines Singles oder Doubles auf jeden Fall ausreicht.

Soweit ich weiß, wenn du kein Datum reinkodierst, wird das implizit als 30.12.1899 angenommmen (Danke @Amateurprofi und Kopf->Wand) und dadurch hast du eine immense Genauigkeit. Rechnen wir das mal durch.
~9000000000000000 verschiedene Mantissen sind darstellbar.

Nehmen wir an, du rechnest nicht mit Zeiten >24h.
Das bedeutet, dass 1 die höchste Zahl ist, die erreicht wird.
Du kannst also bis auf 1/9000000000000000 Tag genau rechnen, also 1/(9*10^15) macht 9*10^-15.
9*10^-15d = 3,24*10^-11s
Das bedeutet, du bist sogar auf die Nanosekunde (eine Milliardstelsekunde) genau, genaugenommen sogar auf etwa 3 Pikosekunden genau.

Dürfte wohl ausreichen.

[Khabarakh]

Zitat:

Zitat von 3_of_8

Der Rest ist durchaus interessant, auf Wikipedia steht diese Information nicht (oder ich habe sie mehrfach überlesen).

Darüber habe ich vor einiger Zeit etwas gelesen, rate mal auf welcher Seite ;) .
Bei wissenschaftlichen Artikeln kann man Wikipedia wahrscheinlich etwas mehr Vertrauen schenken, ansonsten gibt es immer noch am Seitendende die verlinkten Spezifikationen ;) .

[3_of_8]

Tatsächlich, jetzt hab ichs auch gesehen. Muss ich wohl überlesen haben, so nach dem Motto "was momentan zu kompliziert für mich ist, ignoriere ich".

In meinem Mathe-Skript funktioniert das immer prima. :mrgreen:

[MStoll]

Zitat:

Zitat von 3_of_8

Ja, wird es. Denn die DateUtils-Routinen erwarten TDateTime und keine Extendeds. Du könntest natürlich einen Typencast vornehmen, aber dadurch gewinnst du gar nichts.

Mal angenommen, ich mache also eine Funktion die etwa so aussieht:

Delphi-Quellcode:

function EncodeMyTime(h,m,s,ms,mys : word) : extended;
begin
     result := EncodeTime(h,m,s,ms);
     result := result + MysToTime(mys);
end;

und eine Prozedur, die etwa so aussieht:

Delphi-Quellcode:

procedure DecodeMyTime(t : extended; var h,m,s,ms,mys : word);
begin
     DecodeTime(TDateTime(t), h, m, s, ms);
     DecodeTime(t, mys);
end;

Was würde dadran schief gehen?

Mein Ziel ist es halt, die Mikrosekunden so einzukodieren, dass z.B. ihr Übertrag bei Addition sich entsprechend auf die Millisekunden auswirkt, d.h. im allgemeinen, dass sich diese Mikrosekunden in die Berechnungen nahtlos einfügen und ich die für die Dekodierung von Stunden, Minuten, Sekunden und Millisekunden weiterhin DecodeDate nehmen könnte.

[3_of_8]

1. Was ist MysToTime?
2. Du hast einen impliziten Cast von Extended auf TDateTime, wenn du deinem Result das Ergebnis von EncodeTime zuweist. Das bedeutet, da verlierst du Genauigkeit. Das einzige, wo du eventuell was gewinnst, ist bei result:=result+MysToTime(...);, weil da addiert wird. Allerdings gewinnst du auch da nur was, wenn MysToTime entweder hohe oder sehr niedrige Werte liefert, zum Beispiel kleiner als 3 Pikosekunden.

Glaub mir, so tief kommst du nicht.

Es gibt übrigens nie Rechenfehler (bzw. nur sehr sehr selten) bei heutigen PCs. Nur eben Genauigkeitsfehler bei Gleitkommazahlen.

Nimm einfach TDateTime, das reicht LOCKER aus. Ich weiß nicht, wie genau im Rennsport gemessen wird, aber auf die Pikosekunde genau glaube ich nicht.

Nehmen wir an, der Abstand Rennwagen zu Messgerät beträgt 5 Meter. Die Lichtgeschwindigkeit nehmen wir vereinfacht mit 3*10^5 km/s an. Dann braucht das Licht für diese Strecke etwa 0,0000000166s, also 16 ns. Da wir auf 0,003 ns genau darstellen können, folgt daraus, dass du rein technisch gesehen gar nicht in den Bereich kommen könntest, in dem ein Double zu ungenau ist. Es sei denn du fährst Rennen, die mehrere Wochen dauern oder besitzt eine Tachyon-Lichtschranke.

[MStoll]

War ja nur mal ein Gedankenspiel.

MysToTime wäre eben die Funktion, die Mikrosekunden in den entsprechenden Teil des Tages umwandelt.
Die kodiert die Mikrosekunden da noch rein. Sollte doch funktionieren, egal ob mit extended oder TDateTime.
Mir schon klar, dass EncodeTime nen impliziten TypeCast macht. Ich wollte ja mit dem Extended lediglich noch "Platz schaffen" für genauere Werte, wenn das allerdings schon mit TDateTime geht, ist das ja ok. ;)

Ich meinte mit Rechenfehler auch nich CPU-bedingte Rechenfehler, sondern solche, die auf Grund von Ungenauigkeiten entstehen könnten, wenn man viele Zeiten codiert und mit diesen rechnet, z.b. sie addiert. Also solche, die auf eine Ansammlung von Genauigkeitsproblemen zurückzuführen sind.