BerniG schrieb:
Nein das habe ich auch nicht behauptet. Aber 32Bit Float und 32Bit Integer haben unterschiedliche Stärken und Schwächen hinsichtlich ihrer Genauigkeit.
Wie willst du mit einem Integer 3,5 darstellen (=> Genauigkeitsverlust)? Wie willst du mit einem Integer 5.000.000.000 darstellen? Mit float geht das einwandfrei, generell sind hier fast beliebig große Zahlen möglich (wenngleich man meist nicht exakt auf den gewünschten Wert hinkommt und das ist dann im entspr. Wertebereich eben der Vorteil von Integer).
Irgendwie komme ich mir gerade blöd vor. Weisst du auch warum? Weil ich Beiträge schreibe und keine Sau liest sich diese durch. Stattdessen wird irgend ein Blödsinn geschrieben.
BerniG schrieb:
Und wenn du jetzt auf deine folgenden Ausführungen zurückkommst: Wenn du einfach per memcpy oder Ähnlichem deine "Deepcopy" anlegst hast du immer noch eine float im Speicher und keinen Integer. Dass 32Bit 32Bit bleiben ist schon klar aber du betreibst hier Wortklauberei und gehst völlig mit deinen Ausführungen an der Fragestellung vorbei.
Falsch! Deine Aussagen waren nicht korrekt. Insbesondere hast du geschrieben das es bei der Konvertierung einer Gleitpunktzahl in einen String zu einem Verlust der Genauigkeit käme, was völliger Unfug ist.
Warum das so ist, habe ich bereits detailliert beschrieben und ich bin nicht hier um mich zu wiederholen, nur weil einige User zu faul sind Beiträge der Mitdiskutanten zu lesen.
Entscheidend ist einzig und allein die Interpretation der Daten und die Form der Konvertierung. Im Speicher gibt es keine Gleitpunktzahl, es gibt nur eine Aneinanderreihung von Bits.
Eine Gleitpunktzahl landet in der Regel in einem Register der FPU. Theoretisch kann Sie aber überall landen, sogar als DWORD, welches ich in ein ST Register schiebe. Es kommt einzig und allein auf die Interpretation der Daten an und wie ich auf diesen operiere. FDIV operiert logischerweise anders auf den Daten als DIV oder wenn ich einen MMX Befehl, wie DIVPD, nehme.
Tatsache ist, bei der Konvertierung einer 32-Bit Float in einen 32-Bit Integer, kommen in Programmiersprachen feste
Konvertierungsregeln zu Einsatz, die sich nach der Hierarchie der Datentypen richten. Die Konvertierung beschreibt eindeutig, dass die Nachkommastellen abgeschnitten werden und bei einer zu großen Ganzzahl das Ergebnis nicht definiert ist. Wenn ich also versuche 5.2E20 in einen 32-Bit Integer zu stopfen, so bekomme ich irgendeine undefinierte Ganzzahl heraus die natürlich im Wertebereich des 32-Bit Integers liegt.
Ein String ist aber kein primitiver Datentyp, sondern ein zusammengesetzter Datentyp! Eine Konvertierung von oder zu einem String ist abhängig von der Interpretation und den damit verbundenen Konvertierungsregeln, die ich aufstelle, so wie die Entwickler von C die Vereinbahrung getroffen haben das bei einem gewöhnlichen Cast die Nachkommastellen abgeschnitten werden ohne zu runden.
So kann der String "1625" mit seiner ASCII Repräsentation als 32- Bit Integer gespeichert werden. Der String könnte aber auch als Wert abgespeichert werden, d.h als Ganzzahl. Oder man nehme den String "110010010000111111011011". Ist das nun eine Ganzzahl oder eine Gleitpunktzahl? Ist es eine binäre Darstellung einer Ganzzahl, also die Zahl 13176795, oder ist es die Ganzzahl selbst? Oder ist es eine Gleitpunktzahl mit Mantisse, Vorzeichenbit und Exponent? Richtig, wir wissen es nicht. Wir können den String nur konvertieren, wenn wir das wissen. Es hängt von der Interpretation ab.
Cyba_Mephisto schrieb:
Das dürfte es mit hoher Wahrscheinlichkeit sein. Vor allem wie der Threadersteller die Fragen hingeklatscht hat, ohne selbst dazu Stellung zu nehmen, ganz nach dem Motto, "Macht ihr mal!".
