Float in zwei Integer zerlegen

[Popov]

Zitat von Shark99:

Irgendwas ist faul. Aus einem TDateTime von 42173,681694 wird durch Trunc(Frac(DateTime) * 24 * 60 * 60 * 1000) ein Integer von 58898345. Werde es wohl doch in einen String speichern müssen damit ich es wieder finde.

Bezeichne bitte nicht etwas als faul was nicht faul ist. Alles ist so wie es sein soll. Aber seit Menschengedenken weiß man, dass man Fließkommawerte nicht miteinander vergleicht, bzw. es dabei zu Problemen kommen kann. Was glaubst du bedeutet das Wort: Fließkomma?

Ich hab schon zig Projekte geschrieben in deinen ich Daten miteinander verglichen oder gesucht habe. Das klappt schon, man muss sich nur der Problematik bewußt sein.

Zitat von Shark99:

Eben, es gibt Rundungsfehler und ich finde den Record nicht wieder.

Wenn du das Datum und Uhrzeit in zwei Integer zerlegst, warum machst du dann wieder ein Double daraus um es zu vergleichen. Warum machst du den Double mit dem du suchst nicht zu zwei Integern? Und schon ist das Problem beseitigt. Und sollte es nötig sein mit Double-Werten zu vergleichen, wie wäre es den Double zuerst zu zerlegen und dann wieder zum Double zu machen. Dann haben beide Double-Werte, der gespeicherte und der mit dem du vergleichst, die gleiche Rundungs-Ungenauigkeiten.

[Dejan Vu]

Wer Fließkommazahlen auf exakte Gleichheit vergleicht, wird geteert und gefedert. Wie oft denn noch?

[Stevie]

Zitat von Dejan Vu:

Wer Fließkommazahlen auf exakte Gleichheit vergleicht, wird geteert und gefedert. Wie oft denn noch?

Blödsinn, ein Float kann sehr wohl als Index benutzt werden. Man darf nur nicht weiter rechnen damit oder ihn zerlegen und wieder zusammenfügen!

[Medium]

Also wenn die Zeit als Index dient und vor allem mit anderen Zeitwerten verglichen werden soll, ist ein TDateTime (=Double) so ziemlich die schlechtest mögliche Struktur die man wählen könnte. Die Gründe werden hier fast wöchentlich durchgekaut. Nimm einfach statt eines TDateTimes eien Cardinal, hau das Datum als Unix-Timestamp da rein, und fertig ist die Laube. Passt sogar in TListItem.Data. Ab 2038 wird man vermutlich aber mal einen Wartungslauf machen müssen, oder man nimmt einen Int64 und hat ein paar Jahrtausende Ruhe (muss dann aber auch wieder Pointer im ListItem hinterlegen).
Aber mit dem Float wirst du dir irgendwann gewaltig den Rücken brechen hier.

[Dejan Vu]

Zitat von Stevie:

Zitat von Dejan Vu:

Wer Fließkommazahlen auf exakte Gleichheit vergleicht, wird geteert und gefedert. Wie oft denn noch?

Blödsinn, ein Float kann sehr wohl als Index benutzt werden. Man darf nur nicht weiter rechnen damit oder ihn zerlegen und wieder zusammenfügen!

Und das ist dann auch Blödsinn. Natürlich darf man rechnen, zerlegen und wieder zusammenfügen. Nur e-x-a-k-t v-e-r-g-l-e-i-c-h-e-n nicht. Aber Dir muss ich das ja nicht erklären, sondern höchstens um Formulierungen ringen.

[Stevie]

Zitat von Dejan Vu:

Zitat von Stevie:

Zitat von Dejan Vu:

Wer Fließkommazahlen auf exakte Gleichheit vergleicht, wird geteert und gefedert. Wie oft denn noch?

Blödsinn, ein Float kann sehr wohl als Index benutzt werden. Man darf nur nicht weiter rechnen damit oder ihn zerlegen und wieder zusammenfügen!

Und das ist dann auch Blödsinn. Natürlich darf man rechnen, zerlegen und wieder zusammenfügen. Nur e-x-a-k-t v-e-r-g-l-e-i-c-h-e-n nicht. Aber Dir muss ich das ja nicht erklären, sondern höchstens um Formulierungen ringen.

Irgendwie bezweifle ich den Nutzen eines Indexes, den man nur beinahe vergleichen kann.

[Popov]

Zitat von Stevie:

Irgendwie bezweifle ich den Nutzen eines Indexes, den man nur beinahe vergleichen kann.

Gibt es, nennt sich SVerweis in Excel und hat eine Option mit der man einstellen kann ob das Suchkriterium genau sein muss oder nur in der Nähe.

[mkinzler]

Als Index aber alles andere als optimal