Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
IEE-754 kodierte Zahl ist eine Ganzzahl (int iwert), warum ist die Verwendung des Cast-Operators (float) ungeeignet?
Kann mir das einer erklären?
Hier noch eine Frage, bei der ich verständnis Schwierigkeiten habe. Wie muss ein Zahl-Literal gekennzeichnet werden (Datentyp: double, float, long, int)? Ich versteh zwar was für Datentypen es sind und wofür sie gebraucht werden, aber wie meint man das gekennzeichnet im Quelltext? Dass es mit einem = deklariert werden muss?
Die Norm IEEE 754 (ANSI/IEEE Std 754-1985; IEC-60559:1989 - International version) definiert Standarddarstellungen für binäre Gleitkommazahlen in Computern und legt genaue Verfahren für die Durchführung mathematischer Operationen, insbesondere für Rundungen, fest. Der genaue Name der Norm ist IEEE Standard for Binary Floating-Point Arithmetic for microprocessor systems (ANSI/IEEE Std 754-1985).
Nunja, das steht auch in meinem Script, aber bringt mir 0 - hat doch nichts mit meiner Frage zu tun - warum ist die Verwendung des Cast-Operators (float) für eine IEEE-754 kordierte Ganzzahl ungeeignet?
Nunja, das steht auch in meinem Script, aber bringt mir 0 - hat doch nichts mit meiner Frage zu tun - warum ist die Verwendung des Cast-Operators (float) für eine IEEE-754 kordierte Ganzzahl ungeeignet?
1) IEEE-754 betrifft weder dich noch java (zumindest in den meisten fällen) sondern die FPU des Prozessors, darauf hast du von Java aus keinerlei einfluss.
2) In IEEE-754 werden float zahlen dargestellt, was soll das casten eines floats in ein float großartiges bringen?
weil Integer anders codiert werden als Float ... und ein Cast ist nur eine Reinterpretation der Bits ... nimm einfach mal eine 32 Bit Folge und interpretiere sie mal (wie die CPU/FPU) als IEEE-754 und als Integer
weil Integer anders codiert werden als Float ... und ein Cast ist nur eine Reinterpretation der Bits ... nimm einfach mal eine 32 Bit Folge und interpretiere sie mal (wie die CPU/FPU) als IEEE-754 und als Integer
Man könnte sowas vielleicht in C mit irgendwelchen wüsten pointer-castings hinbekommen, aber in java kriegst du nicht mal
Code:
Integer[]
als
Code:
int[]
reinterpretiert, obwohl da bit für bit genau dasselbe drin steht :noe:
In Java bewirken casts von floats in integer relativ intuitive Abrundungen, in andere Richtung bekommt man ungefähr genauso große ganze Zahlen ggf. mit ein wenig Präzisionsverlust. Aber da wird garantiert kein IEEE-754-Murks bit für bit als Integer reinterpretiert.
@0x7F800000:
Das habe ich jetzt auch mal überlesen und deute es als Basis einer Uhrzeit wo man nicht mehr posten sollte ;-)
Natürlich ist ein Integer nicht bit genau das Selbe wie ein int
Ein int hat genau 4 Byte, nämlich den Wert ansich.
Ein Integer hat mindestens 8 Byte, die Referenz und den Wert als interner int.
In Java bewirken casts von floats in integer relativ intuitive Abrundungen, in andere Richtung bekommt man ungefähr genauso große ganze Zahlen ggf. mit ein wenig Präzisionsverlust. Aber da wird garantiert kein IEEE-754-Murks bit für bit als Integer reinterpretiert.
verhalten sich beide jedenfalls einigermaßen als "Objekte", und die "Referenz" auf ihre "Klasse" müssten sie beide jeweils nur einmal abspeichern.
Aber du meinst also, dass wenn ich
Java:
new Integer[1000]
eintippe, die Runtime tatsächlich >8000 bytes für dieses Array allokiert, um 4000 bytes für Integer-Werte, und 4000 bytes immer dieselbe Referenzen auf die Integer-Klasse abzuspeichern? Ja, könnte eigentlich gut sein... Obwohl man wegen
public final class Integer
sich die ganze Redundanz einigermaßen schmerzfrei sparen könnte, indem man die Referenz auf Integer-Klasse einmal für's gesamte Array abspeichert, denn durch das [c]final[/c] hat man ja eine Garantie, dass da ausschließlich Integer reinkommen können, daher braucht man keinen extra-Platz für diesen ganzen Polymorphie-Kram. Jedenfalls sehe ich keinen guten Grund, eine unveränderliche Referenz zig tausend mal umsonst abzuspeichern, außer man will die Sprache und die JVM möglichst einfach und einheitlich halten (das ist bei Java leider nicht der Fall).
Aber ich weiß es nunmal wirklich nicht, du könntest natürlich recht haben, dass in Java jedes Objekt grundsätzlich alle Informationen über seine Klasse immer mitschleppt, auch in Arrays von finalen Klassen. Ich weiß es nicht, ich hab noch keine VM geschrieben, tschuldigung^^
Noctarius hat gesagt.:
Natürlich ist ein Integer nicht bit genau das Selbe wie ein int
Ein int hat genau 4 Byte, nämlich den Wert ansich.
Ein Integer hat mindestens 8 Byte, die Referenz und den Wert als interner int.
Zum einen: hier gilt dasselbe wie in der Antwort an Empire-Phoenix.
Zum anderen: okay, meinetwegen jedes mal 4 bytes skippen. Um den Aufbau von Objekten ging es ja auch nicht, sondern um Fließkommazahlen im Vergleich zu Integern.