Typanpassung

[janausrissen]

Hallo Community,

schoen, dass ich dieses Forum gefunden habe,
ich habe gleich eine Frage:
in meinem Skript liest man zu Kompatibilitätsregeln
für einfache Datentypen:

"Jeder numerische Typ kann in einen anderen numerischen
Typ umgewandelt werden, was allerdings zu Informations-
verlust führen kann".

Ich benutze den JCreator als Umgebung.
Wenn ich mit

class HelloWorld {
	
       public static void main(String[] args) {
	
          // Display "Hello World!"
          byte b;
          short f;
          b=100;
          f=2000;
          b=b+f;
          System.out.println(b+f);
	}
}

Den oben zitierten Satz aus dem Skript überprüfe
meldet der Compiler aber:

"possible loss of precision"

Ausführen kann man den Programmblock dann nicht mehr.

ich habe durch

b=b+f;

b von byte in short umgewandelt. Mir ist klar, dass b nun (da
b=2100) den Wertebereich eines byte-Datentyps verlassen hat.

Meine Frage:
Kommt die Fehlermeldung nun, weil die Typumwandlung entgegen
der Behauptung im Skript doch nicht moeglich ist oder weisst
der Compiler nur darauf hin, dass ein Verlust an Genauigkeit
zu befürchten ist? Falls ja, warum kann man das Programm dann
nicht ausführen? Oder muss man den JCreator so einstellen, dass
eine Ausführung trotz Compiler-Warnung möglich ist?

Danke im Voraus
Jan

 

[P3AC3MAK3R]

Ich habe Deinen Code gerade einmal mit Eclipse getestet. Ich bekomme den Fehler (nicht die Warnung) "Type mismatch: cannot convert from int to byte".

 

[SlaterB]

du musst dem Compiler mitteilen, dass du seine Bedenken vernommen und in deine Entscheindung miteinbezogen hast,
dennoch das Ergebnis wieder als byte speichern möchtest,
kurz:

b=(byte) (b+f);

nennt sich Casten

 

[Murray]

ich habe durch

b=b+f;

b von byte in short umgewandelt. Mir ist klar, dass b nun (da
b=2100) den Wertebereich eines byte-Datentyps verlassen hat.

Das stimmt so nicht, b wird immer ein byte bleiben und kann dern Wertebereich nicht verlassen. Man kann aber durch einen expliziten Cast f zum byte machen (wobei der Wert ggfs. abgeschnitten wird)

b = (byte)(b + (byte)f);

Interessanterweise geht es bei

b += f;

auch ohne cast (siehe auch diesen Thread)

 

[janausrissen]

Man Leute....
Tolle Community!

Super, vielen Dank für eure netten und schnellen Antworten.

@P3AC3MAK3R:
mhh.., komisch, weil: ich habe doch gar kein int Datentyp "mit drin".
Trotzdem danke.

@SlaterB:
Ja Ok .... genauso habe ich es vermutet, gute Erklärung von Dir!
Das ist genau die Antwort, die meine Frage trifft, Supi!

@Murray:
Ahja, verstehe... mit der Antwort von SlaterB zusammen heisst das dann
wohl, dass zwar eine Umwandlung von jedem numerischen Typ in jeden
numerischen Typ moeglich ist, dies aber nicht automatisch geschieht
sondern nur durch das "Casten" stimmts?

Ok vielen Dank nochmal an alle!

Gruss
Jan

 

[janausrissen]

Ps.:
@Murray
guter Link, danke.

Gruss
Jan

 

[Marco13]

Die umwandlung geschieht automatisch, wenn es eine "Widening" conversion ist. D.h. vereinfacht gesagt(!!!!!!) dann, wenn durch die Zuweisung keine Information verlorengeht. Andernfalls muss man casten.

int zehn = 10;
int tausdent = 1000;
byte d = zehn; // Geht nicht - evtl. Informationsverlust
byte e = (byte)zehn; // Geht - "Der Programmier weiß, dass kein Informationsverlust auftritt"
byte g = (byte)tausend; // Geht - es tritt aber Informationsverlust auf.

Manchmal KANN aber auch bei einer "widening conversion" Information (bzw. "Präzision") verlorengehen. Schau dazu auch mal hier
http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25214

 

[janausrissen]

Hallo Marco13,

sehr schoene Beispiele! Das macht die
Sache noch klarer.
Danke auch duer deinen Link.

Allerdings... bei:

byte d = zehn; // Geht nicht - evtl. Informationsverlust

handelt es sich doch wohl um eine von Dir genannte
"Widening" conversion oder?



Gruss
Jan

 

[Murray]

byte d = zehn; // Geht nicht - evtl. Informationsverlust
handelt es sich doch wohl um eine von Dir genannte
"Widening" conversion oder?

Die nächste Gemeinheit - hier muss man noch zwischen Compile- und Laufzeit unterscheiden. Natürlich würde der Wert 10 in ein Byte passen, allerdings analysiert der Compiler den Code nicht soweit; zur Compilezeit steht hier nur die Information, dass der Variablen b irgendein int-Wert zugewiesen werden soll. Dass es sich bei diesem Wert zwingend um die 10 handelt, sieht der Compiler nicht. Anders sieht es aus, wenn man final verwendet:

int i1 = 10;
final int i2 = 10;

b = i1; //--- geht nicht
b = i2; //--- geht

 

[janausrissen]

für float Daten liest man auf einigen Seiten im Netz:

Wertebereich:3,4*(+/-)10^38,
7 Ziffern,
4 Bytes.

Warum gibt es für float Literale denn nur 7 Ziffern?
(Ab 8 gibt es wieder: possible loss of precision.)

Für eine 7 stellige Zahl brauche ich doch nur 20 Bits. Und 20 Bit
verbrauchen dann 3 Byte, da wohl immer in Byte,
also 8 Bit Einheiten gerechnet wird oder?

Da bleibt doch noch 1 Byte dann uebrig....

Warum also nur 7 Ziffern?


Gruss
Jan

 

[SlaterB]

mit 2^20 bist du nur bei 1.048.576, 3-4 Bits mehr brauchst du wohl um auch 9.999.999 darstellen zu können,
dann noch 1 Bit fürs Vorzeichen, 5-7 Bits für Exponent 10^38 bis 10^-37

wird also durchaus eng


24 Bit Zahl + 1 + 7 kommt genau hin: 32 Bit

 

[janausrissen]

Hallo SlaterB,

ich glaube es ist eher so:

pro Ziffer werden maximal (bei der Ziffer 9) 4 Bit verbraucht.
Beispiel: Ziffer 9
9 als Binärzahl: 1001 => 4 Bit.

Bei einem Literal mit 7 Ziffern haben wir also maximal
7 * 4 = 28 Bit. Das würde für die Ziffern bei
99.99999 zum Beispiel der Fall sein.
Das entspricht also 3.5 Bytes, im restlichen Halbbyte
müsste dann Vorzeichen und Decimalpunkt sein.

Weiss jemand genaueres?

Gruss
Jan

 

[SlaterB]

ich kann dir mit Gewissheit sagen, dass nicht 4 Bit für eine Ziffer verschwendet werden,

außerdem wäre es extrem unhandlich bei Rechnungen,
wenn 10 nicht der logische Nachfolger von 9, also 0000 1010, wäre sondern 0001 1001

---------

naja, die interne Darstellung ist wohl eh eine andere, siehe
http://www.h-schmidt.net/FloatApplet/IEEE754de.html

da wird ganz schön getrickst,
z.B. die Zahl 3 als 1.5 mit Exponent 2 dargestellt (Zweier-Exponent, nicht Zehner-Exponent)

1x Vorzeichen, 8x Exponent, 23x Mantisse

 

[janausrissen]

Man, das muss ich erstmal verdauen...

Super! danke fuer den interessanten Link.

Lieben Gruss
Jan

 

[Guest]

Hallo nochmal an alle, die den Thread verfolgen bzw. daran
beteiligt sind.

Hier ist ein Link der Uni bayreuth mit zahlreichen,
guten Beispielen zum Thema Typumwandlung und
casten.

www.math.uni-bayreuth.de/~rbaier/lectures/java_multimedia_ws2004_05/html/node25.html]Typumwandlung[/url]

Gruss
Jan

 

[janausrissen]

Ich habe noch eine Frage bitte:

Für das casten von char nach int wird wohl die Unicode
Codierung benutzt oder?
Ist die Codierung für unser Alphabet, unsere Zahlen und
Sonderzeichen eigentlich identisch mit der ASCII Codierung?
Kann man also die ASCII-Tabelle benutzen?

Und dann noch: ist der default-Typ fuer ganze Zahlen eigentlich int ?

Nochmal Gruss
Jan