Hallo Tom,
sorry, ich war im Urlaub und hab erst grade gesehen, dass du nochmal was zu dem Thema geschrieben hast.
Ich hab mir grad nochmal Yves Beitrag im WCM-Forum angeschaut. Dort scheint mir einiges durcheinander geraten zu sein. Die Werte, die Yves im Hex-Editor hervorgehoben hat sind nicht vollständig - die jeweils 8 Ziffern vor den fett markierten gehören zu den Zahlen mit dazu.
840000009999993F --> konvertiert nach Big-Endien: 3F 99 99 99 00 00 00 84 --> 0.025
8C000000E17AE43F --> konvertiert nach Big-Endien: 3F E4 7A E1 00 00 00 8C --> 0.64
940000006666E63F --> konvertiert nach Big-Endien: 3F E6 66 66 00 00 00 94 ist 0.7
Alle Werte sind als 32-bit Double gespeichert (z.B. 99 99 A9 3F für 0.05), bei diesen kleinen Zahlen meist an der Endung 3F zu erkennen
Diese Aussage ist somit tatsächlich falsch (und macht auch keinen Sinn, da ein double per Definition 64 bit lang ist). 3F ist übrigens kein Indikator für eine 64 Bit Gleitkommazahl.
Auch die angegebenen Offsetwerte scheinen somit falsch zu sein (jeweils um 4 Bytes verschoben):
Rollreibungskoeff. ist nicht auf der 48cbc, sondern auf der 48CB8
Gleitreibungskoeff ist nicht auf der 48cd2 sondern auf der 48CCE
Bremskoeff ist nicht auf der 48ce8 sondern auf der 48CE4
Ich vermute mal, dass auch die anderen angegebenen Offsetwerte jeweils um 4 Bytes falsch sind.
Ich hab also, wie Andreas oben geschrieben hat, erst das ganze umgedreht und dann die letzten 8 Stellen inklusive 3F genommen:
E17A743F
Nur ist das ja irgendwie kein richtiger Wert mehr...
Stimmt, dass kann so nicht funktionieren. Wenn du eine 64 Bit Gleitkommazahl einfach in der Mitte durchschneidest, kommt einfach nur Datenmüll dabei raus. 0.001 müsste FC A9 F1 D2 4D 62 50 3F sein (bereits gedreht in die Intel-Reihenfolge).
F747AE147AE147B ist übrigens nicht 0.001 sondern 0.005.
Ich hoffe, ich konnte dir ein wenig weiterhelfen.
Viele Grüße,
Andreas
