Wertebereich/Datentyp

[fenstergummi]

Hallo zusammen,

ich bin neu hier und versuche Java-Programmieren zu erlenern.

Kann mir jemand sagen, welcher Datentyp zu welchen Wertebereich passt? (kleinsmöglicher Datentyp) und wie ich sowas errechnen kann?

Vielen Dank schonmal.

510.33 bis 10012.61
0.987543219 bis 1
1 bis 100
-10 bis 3243231231
k bis z

 

[dayaftereh]

Hey, hättest du es schonmal gegoogelt ? Schau mal hier https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

 

[Xyz1]

1 bis 100 z. B. short, byte oder char - das kommt auf den Anwendungsfall an.

 

[fenstergummi]

Hey, erstmal danke für die schnellen Antworten und den Link.
ist für mich alles noch etwas unübersichtlich das ganze. Bin noch ganz am Anfang...

Sehe ich das also richtig...

510.33 bis 10012.61 = short
0.987543219 bis 1 = long
1 bis 100 = byte
-10 bis 3243231231 = float
k bis z = char

Sorry fürs bloede fragen

 

[da921610]

Hier siehst du eigentlich alle wichtigen Datentypen:

https://de.wikibooks.org/wiki/Java_Standard:_Primitive_Datentypen

Dort kannst du schauen, wozu deine Werte passen.
So wie du es geschrieben hast, ist es nicht ganz richtig.
Vielleicht liest du dir auch mal den Artikel durch.

 

[fenstergummi]

510.33 bis 10012.61 = double
0.987543219 bis 1 = float
1 bis 100 = byte
-10 bis 3243231231 = int
k bis z = char

 

[da921610]

Sieht gut aus

 

[fenstergummi]

Vielen Dank,vielen vielen Dank!!!

 

[dayaftereh]

Ich glaube die zwei sind noch falsch :

510.33 bis 10012.61
-10 bis 3243231231

 

[BuckRogers]

Ist leider nicht wirklich korrekt.

Kiek mal hier rin:

https://de.wikibooks.org/wiki/Java_Standard:_Primitive_Datentypen

 

[InfectedBytes]

Kommazahlen:
float oder double
Floats haben eine Genauigkeit von etwa 7 Dezimalstellen, Doubles eine von 14 Stellen.

Ganzzahlen:
byte (8Bit) => 2^8=256 verschiedene Zahlen darstellbar, da das Byte in Java vorzeichenbehaftet ist kannst du also Zahlen von -128 bis +127 darstellen
short (16Bit) => 2^16=65536 verschiedene Zahlen => -32768 bis +32767
int (32Bit) => 2^32 = ~4mrd => +-2 mrd
long (64Bit) => 2^64 = ~18 trillionen => +-9 trillionen

char ist wie short, allerdings ohne Vorzeichen => 0 bis 65536

 

[da921610]

Also bei -10 bis3243231231 stimmt ich dir zu, dass es falsch ist, aber nicht bei 510.33 bis 10012.61

 

[BuckRogers]

Fällt alles unter die Kategorie nice-to-know. Was man meistens braucht und was ausreicht ist long, int und String. Boolean nicht zu vergessen, haha!
Wenn es mal kniffelig wird brauchst du die anderen primitiven Datentypen. Versuche dich mal mit der simplen Standartausgabe in Java und spiel mit den Werten der Datentypen rum.

 

[fenstergummi]

Also doch nicht ganz richtig?

ich sollte diesen 5 Beispielen den kleinsmöglichen Datentyp zuordnen.
Wie würde es denn eurer Meinung nach aussehen?

 

[InfectedBytes]

510.33 bis 10012.61 = double
0.987543219 bis 1 = float
-10 bis 3243231231 = int

passt leider nicht

510.33 bis 10012.61: double passt auf jeden Fall, aber im Grunde könnte man auch Argumentieren, dass hier float reicht, da zumindest die Grenzen bereits mit einem float dargestellt werden können.

0.987543219: sind zu viele stellen für float, muss also auch double sein

Ein int geht nur bis etwa +2mrd, daher braucht man für 3243231231 bereits long

 

[Xyz1]

Du bist zwar Anfänger, aber es ist immer gut zu wissen, wenn man den Standard kennt: https://de.wikipedia.org/wiki/IEEE_754 und https://de.wikipedia.org/wiki/Gleitkommazahl - es ist ja nicht so, als wenn Datentypen in Java nicht standardisiert wären.

Demzufolge:
510.33 bis 10012.61 float
0.987543219 bis 1 double
1 bis 100 byte/char/short
-10 bis 3243231231 long
k bis z char/String

Wie ich eingangs schon schrieb, kommt es aber weiter auf den Anwendungsfall an. Soll das Rechnersystem später um Randwerte erweitert werden, zum Bleistift -1 bei 1 bis 100, oder nicht??? Raketenabstürze gab es in der Vergangenheit!!! Dabei geht dann viel Image, Material und Menschen verloren (nach Wichtigkeit nicht unbedingt in dieser Reihenfolge). Auch wäre es schlecht, wenn dein Prozessor in der CPU falsch rechnen würde...

Wie es auch sei, du kommst nicht drum rum, DICH intensiv mit der Anwendung auseinanderzusetzen.

 

[fenstergummi]

Alles klar, ich danke Euch vielmals! Ich werde mich auf jeden Fall weiter in diese Thematik stuerzen! Hoert sich wahrscheinlich alles erstmal sehr kompliziert an... ;-)

 

[Xyz1]

Ist das Thema denn gelöst? Die korrekte Berechnung zu zeigen - ohne bloßes Draufschauen - ist gar nicht so leicht. Möchte diese jemand hier machen? Es müsste ja gezeigt werden: float < 0.987543219 bis 1 < double. Wer möchte das tun?

 

[JStein52]

Es müsste ja gezeigt werden: float < 0.987543219 bis 1 < double. Wer möchte das tun?

Wo siehst du das Problem ? @InfectedBytes hat es oben ja schon getan:

0.987543219: sind zu viele stellen für float, muss also auch double sein

Und du kannst es ganz einfach nachvollziehen:

        float var = 0.987543219f;
        System.out.println("Float: "+var);

 

[Xyz1]

Wo siehst du das Problem ? @InfectedBytes hat es oben ja schon getan:

Damit ist nicht gezeigt, dass 0.987543219 mathematisch gesehen nicht in den Wertebereich passt.

Dass das als Literal nicht vom Compiler akzeptiert wird, ist noch kein math. Beweis.

Ohne Mathematischen Beweis sind schon Raketen abgestürzt.

Ich würde tendieren, mal eine Induktion von 0.987543219 bis .. zu machen.

 

[JStein52]

Es geht hier aber nicht um den Wertebereich ! Du hast doch oben selber den Link zur IEEE 754 gepostet. Demnach kannst du bei float nur 7-8 Dezimalstellen darstellen, also nicht den Wert 0.987543219 ! Und das hat nichts damit zu tun ob der Compiler das Literal akzeptiert. Das tut er ja. Aber es kann in float nicht dargestellt werden ! Wenn du hier float verwendest würde die Rakete auf jeden Fall abstürzen.

 

[InfectedBytes]

Hierfür brauchst du keine Induktion.
float hat nach IEEE 754 einen 8 Bit Exponenten und eine 23 Bit Mantisse.
Wenn man nun also per Hand 0.987543219 in eine Gleitkommazahl umwandelt, stellt man fest, dass die Mantisse mehr als 23 Bit haben wird => float reicht nicht

 

[Xyz1]

Oder man schreibt sich diese kleine Hilfsmethode:

    private static boolean equal(double d1, float f1) {
        // System.out.println(Long.toBinaryString(Double.doubleToLongBits(d1)));
        // System.out.println(Integer.toBinaryString(Float.floatToIntBits(f1)));
        System.out.println(Long.toBinaryString(Double.doubleToLongBits(d1) << 11));
        System.out.println(Long.toBinaryString((long) (Float.floatToIntBits(f1) << 8) << 32));
        return Double.doubleToLongBits(d1) << 11 == (long) (Float.floatToIntBits(f1) << 8) << 32;
    }

        System.out.println(equal(123, 123));
        System.out.println(equal(123.25, 123.25f));
        System.out.println(equal(0.9, 0.9f));
        System.out.println(equal(0.987543219, 0.987543219f));

Welche dann diese wunderschöne Ausgabe erstellt:

1111011000000000000000000000000000000000000000000000000000000000
1111011000000000000000000000000000000000000000000000000000000000
true
1111011010000000000000000000000000000000000000000000000000000000
1111011010000000000000000000000000000000000000000000000000000000
true
110011001100110011001100110011001100110011001100110100000000000
110011001100110011001100000000000000000000000000000000000000000
false
111110011001111101000011110010011111101110101110100000000000000
111110011001111101000100000000000000000000000000000000000000000
false

Woran dann erkennt, selbst 0.9(f) wäre für float nicht geeignet...

Edit: Vorzeichenbit ist (immer) 0, fällt deshalb out...

Exponent: immer 8 und 11 Bits...

 

[JStein52]

Woran dann erkennt, selbst 0.9(f) wäre für float nicht geeignet...

Wieso das denn ??

 

[Meniskusschaden]

Wieso das denn ??

Wenn sich der Nachkommateil bei n verfügbaren Stellen nicht als eine Summe der Kehrwerte der ersten n Zweierpotenzen darstellen lässt, wird es eben ungenau. Bei float natürlich ungenauer als bei double.

System.out.println(0.9f - 0.5);
System.out.println(0.9  - 0.5);

führt zu folgender Ausgabe:

0.3999999761581421
0.4

Edit: Was ich damit eigentlich sagen wollte: ob ein Wert als float oder double absolut präzise darstellbar ist, hängt nicht von der Anzahl der dezimalen Nachkommastellen ab, sondern davon, ob er binär "gut passt".

 

[JStein52]

hängt nicht von der Anzahl der dezimalen Nachkommastellen ab, sondern davon, ob er binär "gut passt"

Es lässt sich also nicht verhindern dass die Rakete abstürzt.

 

[Xyz1]

Die Rakete stürzte wegen eines Integer Over- oder Underflows ab, weil der Wertebereich, wahrscheinlich 16 Bit war. Das lässt sich nicht ganz übertragen - außer, ein Wertebereich ist zu klein oder zu groß. Vorzeichenwechsel auch noch mal ein Thema. Jetzt mal ungeachtet dessen ist Gleitkommazahlenarithmetik "ungenau". "Ungenau" ist auch nicht richtig gewählt. Was ich sagen wollte, nur selten ist Rechnen mit rationalen/irrationalen Dezimalzahlen "genau das Richtige"...