Hier mal was zum Thema
Gleitkomma-Berechnungen, das ich kürzlich entdeckt habe (betrifft TMS):
Das Problem war, dass bei sehr großen Werten (z.B. REC-Dateigrößen von 55 MB bis 15 GB in Byte-Angabe) keine Nachkommastellen berechnet wurden. In speziellen Fällen hat er sogar gar nichts angezeigt (auch nicht vor dem Komma).
Es handelt sich immer um double-Variablen. Jetzt könnte jemand sagen, dass es an der Datentyp-Begrenzung liegt. Allerdings war auch kein Unterschied zu float oder long double feststellbar.
Oder bezieht sich hierbei der größere Datentyp long double nicht auf die möglichen Werte vor dem Komma sondern eher auf die Genauigkeit, d.h. mehr Nachkommastellen?
float - 4 bytes
double - 8 bytes
long double - 8 bytes
Daher war hier z.B. das Umrechnen von Byte auf Kilobyte vorab nötig:
// eine Prozentanzeige für den Dateilesestand
calc1 = filepos / 1024;
calc2 = flen / 1024;
if (calc2 > 0) calc = calc1 * 100 / calc2; else calc = 0; //DIV0 vermeiden
TAP_SPrint(out, "%3.1f%%", calc);
Vorher war es:
if (flen > 0) calc = filepos * 100 / flen; else calc = 0; //DIV0 vermeiden
TAP_SPrint(out, "%3.1f%%", calc);
Dabei passierte es, dass meine Prozentanzeige während des Einlesens nach 78% wieder auf 0% zurücksprang (und nochmal bis 21% zählte), obwohl filepos definitiv bis flen hochlief.
Im nachfolgenden Fall half es nur, die Fileposition schrittweise erst von Byte auf Kilobyte und dann von Kilobyte auf Megabyte umzurechnen.
// eine Anzeige der bisher gelesenen Megabytes
calc = filepos / 1024;
calc = calc / 1024;
TAP_SPrint(out, "%4.1f MB", calc);
Vorher war es:
calc = filepos / (1024*1024);
TAP_SPrint(out, "%4.1f MB", calc);
Da zeigte er keine NKS, obwohl es mathematisch dasselbe wäre.
Zumindest funktionierte es mit den Umrechnungen erstmal für meine aktuellen Dateigrößen. Ob es bei noch größeren Dateien wieder Probleme gäbe, weiß ich momentan noch nicht.
Ansonsten gibts auch noch andere vom 5000er bekannte Probleme aufgrund eines
Implementierungsfehlers.