Ieee-754

Status
Nicht offen für weitere Antworten.

burn3r

Mitglied
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?
 

Landei

Top Contributor
10 ist ein int, 10L ist ein long, und den Rest überlasse ich dem geneigten Leser als Übung.
 

javimka

Top Contributor
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).

Drei Mal darfst du raten, woher ich das wohl habe ;)
 

burn3r

Mitglied
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?
 

javimka

Top Contributor
Wegen Rundungsfehler. Aber wenn du einen float brauchst, bleibt dir gar nichts anderes übrig.
 

0x7F800000

Top Contributor
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?

ich verstehe nicht was das problem sein soll...
 
Zuletzt bearbeitet:
G

Gast2

Gast
IEE-754 kodierte Zahl ist eine Ganzzahl (int iwert),
IEEE-754 codiert Gleitkommazahlen ... Integerwerden anders codiert

warum ist die Verwendung des Cast-Operators (float) ungeeignet?
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
 

0x7F800000

Top Contributor
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
seit wann das denn?!? ???:L

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.
 

Noctarius

Top Contributor
@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 :D
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.
 
G

Gast2

Gast
Man könnte sowas vielleicht in C mit irgendwelchen wüsten pointer-castings hinbekommen,
das waren noch Zeiten.....................

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.
sollte dies so sein, dann habe ick nüschts geschrieben :oops:
 

0x7F800000

Top Contributor
Integer[] == int[] wtf?

Das eine ist ne Klasse das andere nicht, das macht schon nen unterschied.
Hmmm... Es ging ja auch nicht um
Code:
Integer
und
Code:
int
's, sondern um
Code:
Integer[]
und
Code:
int[]
's.
Code:
Integer[]
und
Code:
int[]
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.

Code:
(int)0.25f
ergibt eben
Code:
0
und nicht
Code:
1048576000
.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben