Konvertierungsfehler bei Funktion

[khh]

alsoooo,
ich hab jetzt ein numerisches Ergebnis mit

0,083333333 was 2 Stunden entspricht

14:00 - 12:00

wie rechne ich jetzt am besten mit dem Tagesbruchteil weiter?
Einfach in Sekunden, Minuten, Stunden umrechnen ?

Da bekomme ich mit meinen 9 Nachkommastellen wohl Rundungsfehler rein :-(

[Mikkey]

Zitat:

Zitat von khh (Beitrag 1304622)

Da bekomme ich mit meinen 9 Nachkommastellen wohl Rundungsfehler rein :-(

Ein Punkt der 9. Stelle nach dem Komma entspricht 86 Nanosekunden. Wenn Du größere Genauigkeit brauchst...

[himitsu]

siehe DateUtils (Delphi) und SysUtils ... Lazarus k.A. wo.

Mit HoursPerDay oder MinsPerDay multiplizieren und Letzeres kann man auch als Integer rounden.

[khh]

danke dir, gibt es bei Lazarus auch :-)

[Popov]

Welchen Anteil haben Stunden, Minuten und Sekunden am Tagesanteil?

Die 1 steht für 1 Tag oder 24 Stunden. Deshalb berechnet man mit

Delphi-Quellcode:

h := 1 / 24;
...

eine Stunde;

Delphi-Quellcode:

h := 1 / 24 / 60;
...

eine Minute;

Delphi-Quellcode:

h := 1 / 24 / 60 / 60;
...

eine Sekunde;

Delphi-Quellcode:

h := 1 / 24 / 60 / 60 / 1000;
...

eine Millisekunde;

Wobei Delphi 1 Millisekunde mit Double gar nicht erfassen kann. Somit unterliegen die Millisekunden den Rundungsfehlern. Damit sollte man also nicht rechnen.

15 Minuten können somit so berechnet werden:

Delphi-Quellcode:

h := 1 / 24 / 60 * 15;
...

5 Stunden so:

Delphi-Quellcode:

h := 1 / 24 * 5;
...

300 Sekunden so:

Delphi-Quellcode:

h := 1 / 24 / 60 / 60 * 300;
...

[Mikkey]

Zitat:

Zitat von Popov (Beitrag 1304648)

Wobei Delphi 1 Millisekunde mit Double gar nicht erfassen kann. Somit unterliegen die Millisekunden den Rundungsfehlern.

Stop, das kann man so nicht stehen lassen.

Ein Double stellt mehr als 15 signifikante Dezimalstellen dar. Ein Datum im jetzigen Zeitalter hat 5 Stellen vor dem Komma, so bleiben für die Uhrzeit 10 signifikante Ziffern übrig. Im Bereich von etwa A.D. 1700 bis 2200 wird ein Zeitstempel also einer Auflösung von <10ns dargestellt.

Dies gilt natürlich nicht für die Uhr des Rechners und auch nicht für das Format, das die Datenbank für die Speicherung solcher Werte verwendet.

[himitsu]

Delphi TDataTime/Double kann Millisekunden erfassen und zwar noch die nächsten paar hundert oder tausend Jahre lang.
Je größer der Datumsteil wird, mit steigendem Abstand von 30.12.1899, desto kleiner wird die Genauigkeit im Nachkommateil.

[edit] Ich sollte F5 benutzen.
15 bis 16 (15,7 oder so)

[p80286]

Zitat:

Zitat von khh (Beitrag 1304622)

wie rechne ich jetzt am besten mit dem Tagesbruchteil weiter?
Einfach in Sekunden, Minuten, Stunden umrechnen ?

wofür brauchst Du es denn? Wenn Du mit den Trainingszeiten eines Ferrari auf dem Hockenheimring umgehen mußt, dann ist die Millisekunde wohl durchaus relevant, geht es um die Bewegung Deiner Schildkröte im Salatbeet sollte die Sekunde durchaus reichen.
Nicht umsonst rechnen z.B. Autowerkstätten auch nicht minutengenau ab.

Gruß
K-H

[Popov]

Aus Erfahrungen die ich mit eine Projekt gesammelt habe kann ich sagen: 1/10 Sekunde ist drin; bei 1/100 Sekunde wird es schon kritisch, sollte aber noch drin sein; 1/1000 ist problematisch. Weniger vom System, als wegen Double.

//Edit:

Auf der anderen Seite, wenn man den Tag auf Null setzt, also kein Vorkommastellen hat, könnte evtl. auch die 1/1000 Sekunde erfasst werden. Ich hab es aber noch nicht getestet. Ist nur eine Theorie.

[BadenPower]

Zitat:

Zitat von p80286 (Beitrag 1304663)

Nicht umsonst rechnen z.B. Autowerkstätten auch nicht minutengenau ab.

Zum Teil sogar genauer als 1 Minute.

VW:
1h = 100ZE (ZE = Zeiteinheiten)
heißt also
1ZE = 36 Sekunden.