Variablen longBitsToDouble(long bits) als int

[lLycan]

Hallo liebe Community,

wir sitzen in meiner Abteilung nun seit ca. 3 Stunden dran und versuchen herauszufinden was mit dieser Methode nicht stimmt.

Laut der Firma SonarQube besagt eine Regel, dass in die Methode longBitsToDouble(long bits) aus java.lang.Double KEIN int eingelesen werden darf, da sonst wohl das Ergebnis nicht stimmt.

Ich hatte am Anfang dieser Zeit die Idee, dass das int ja automatisch zu einem long umgewandelt wird (also das 32-Bit Format zu einem 64-Bit Format). Es wurde in dieser Zeit durch verschiedenste Ideen versucht meine These zu widerlegen was aber nicht geklappt hat. Meine Kollegen sind nach diesem Kampf der rauchenden Köpfe zu dem Entschluss gekommen, dass sie es nicht schaffen werden meine These zu widerlegen.

Nun stellt sich natürlich die Frage: Warum gibt es diese Regel bei SonarQube und warum ist diese Regel als "Blocker" deklariert also als ein Verstoß der sofort aus dem Quellcode entfernt werden muss bzw. sollte.
Auch nach gefühlten Milliarden Versuchen Onkel google zum reden zu bringen sind wir nicht weiter.

Kann uns einer von euch klugen Köpfen erklären warum kein int eingelesen werden darf? Wenn möglich bitte mit einem Beispiel um das ganze nachvollziehen zu können. Oder habe ich in meinen Jungen Jahren sogar weiter gedacht als die langjährigen Java-Programmier? :lol:

Vielen Dank schonmal


Mit freundlichen Grüßen
lLycan

 

[nvidia]

Das hat was mit dem Bitlayout zu tun. Angenommen wir haben einen int a = 2049, dann sieht der binär wie folgt aus 000000000000000000000100000000001. Wird das implizit zu einem long konvertiert wird ein 000000000000000000000000000000000000000000000000000100000000001 daraus. Ein Double ist aber anders strukturiert. Eine 3.0 sieht als Double so aus 100000000001000000000000000000000000000000000000000000000000000. Der äquivalente long wäre dafür 4613937818241073152. Das wiederrum passt noch nicht mal mehr in einen int.

Du kannst natürlich einen int übergeben wenn du wie oben z.B. dieses Bitlayout meinst 000000000000000000000000000000000000000000000000000100000000001 was zu 1.0123E-320 gehört. Aber in den meisten Fällen ist es eben nicht so und diese Regel ist einfach dafür da um noch einmal darüber nachzudenken ob es wirklich ist das was man meint.

 

[lLycan]

Hallo nvidia,

vielen Dank für die Antwort.

Da der Wert 2049 als long deklariert ebenfalls binär zu
000000000000000000000000000000000000000000000000000100000000001
wird, ist es doch eigentlich egal ob jetzt int oder long verwendet wird oder?

Versteh ich das jetzt richtig, dass es hier nur darum geht nochmal nachzudenken ob man diesen Wert wirklich so umwandeln will wie man es vorhat und durch die Überprüfung von SonarQube quasi "noch ein zweites mal drüberschaut"?

Mfg lLycan

 

[nvidia]

[...] ist es doch eigentlich egal ob jetzt int oder long verwendet wird oder?

Versteh ich das jetzt richtig, dass es hier nur darum geht nochmal nachzudenken ob man diesen Wert wirklich so umwandeln will wie man es vorhat und durch die Überprüfung von SonarQube quasi "noch ein zweites mal drüberschaut"?

Mfg lLycan

Ja, ich schrieb ja das es egal ist, da in der Spezifikation steht das ein int in einen long "verbreitert" werden kann. Es kommt bei der Methode auf das Bitmuster an. Und da kann es eben zu Überraschungen kommen wenn man glaubt man könne z.B. 100000000001 übergeben und 3.0 herausbekommen. Man muss eben wissen ob das Bitmuster welches man übergibt das ist was man benötigt, egal ob int oder long. Und wie ich schon schrieb wird z.B. eine 3.0 erwartet passt das Muster nicht mehr in einen int und man benötigt einen long.

Persönlich würde ich mich jedoch an die Schnittstelle halten und den int "bewusst" in einen long umschreiben bzw. eine Methode basteln die den int übernimmt und mir ein "korrektes" Bitmuster als long zurückliefert.

 

[lLycan]

Dann weiß ich bescheid. Super, vielen Dank

 

[InfectedBytes]

Bei positiven Zahlen ist die Darstellung im Grunde dieselbe. Ob dort also einen int oder long übergibst macht keinen Unterschied, aber bei negativen Zahlen wird das Problem deutlich:
Der int -1 ist: 11111111 11111111 11111111 11111111
Wenn du diesen int zu einem long machst, erhälst du aber:
11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111

 

[lLycan]

an diesen Punkt sind wir gerade auch angelangt. Bisher konnte ich das nicht nachvollziehen, jetzt klappt das aber :rtfm:

Nach weiteren Tests ist mir aufgefallen, dass es weiterhin keinen Unterschied zwischen int und long gibt.
wird int -1 eingelesen werden daraus 64 Einsen.
Wird long -1 eingelesen werden daraus 64 Einsen.

Umgewandelt zu double gibt das beidesmal NaN da der Exponent komplett gefüllt ist und in der Mantisse auch was steht (was natürlich nicht zwingend ist. Hier hab ich mit -1 einfach das richtige Beispiel )

	        double doubWert = -1.0;
		float floaWert = 1.0f;
		long doubBits = Double.doubleToLongBits(doubWert);
		int floaBits = Float.floatToIntBits(floaWert);
		System.out.println(doubWert);
		System.out.println(floaWert);
		System.out.println(Long.toBinaryString(doubBits));
		System.out.println(Integer.toBinaryString(floaBits));
		System.out.println(Double.longBitsToDouble(doubBits));
		System.out.println(Double.longBitsToDouble(floaBits));

Durch diesen kleinen Ausschnitt wandle ich den Wert -1.0 aus der Gleitkommadarstellung um.
Der Binärausschnitt sieht wie folgt aus:

long -> 1011111111110000000000000000000000000000000000000000000000000000
int -> 10111111100000000000000000000000

durch die Umwandlung von int zu long MÜSSTE ich ja jetzt
1111111111111111111111111111111110111111100000000000000000000000 bekommen was letztentlich wieder ein ungültiger Double Wert ist (NaN) da wieder mehr als die Exponent voll ist.

Da der longwert ja nie umgewandelt wurde bleibt dieser natürlich -1.0.


Habe ich nun mein volles Verständnis für meinen Fall erhalten und kann es mir selbstständig erklären oder fehlt noch was?

LG lLycan


Noch ein Nachtrag. Das mit dem NaN ist so, weil durch den vollen Exponenten der Wert die Grenze von Infinity bzw. -Infinity erreicht wurde und eine Erhöhung einen Wert zur Folge hätte der größer als Unendlich ist, was natürlich bescheuert wäre :lol: Zumindest wenn der Rechner keine Mächtigkeit kennt
Richtig ???:L