Variablen Gleitkommazahlen - Kleineres float?

[Network]

Hi,

Ein float besteht in Java aus 4bytes = 32bit. Für meine Zwecke ist das zuviel... Gibt es in Java auch 16bit bytes?
Oder gibt es eine Möglichkeit, ein einzelnes byte für Nachkommarechnungen zu verwenden?
Das mag sich doof anhören, aber ich habe eine kleine Angewohnheit entwickelt alles möglichst komprimiert, klein und ohne Fußabdruck auf dem Rechner laufen zu lassen. Die Ergebnisse zeichnen sich aus und sind garnicht mal so gering.

Dabei sind mir floats jedoch schon zu groß, am besten shorts oder bytes.
Die Frage ist also, ob es kleinere floats (die 16bit Varianten) gibt oder ob man irgendwie regeln kann, dass eine Zahl (als byte) beim addieren als Nachkommazahl addiert wird?

 

[Gast2]

Wenn du byte verwendest hast du genau 256 Zahlen, bei short immerhin knapp 64k, die du repräsentieren kannst. Wie willst du denn damit genügend genau fließkommazahlen darstellen?

Um was für Zahlen gehts dir denn? Wenn du bspw. Euro Beträge hast könntest du die als cent in nem short abspeichern. Bei der Ausgabe durch 100 geteilt hast du dann nen kleinen Zahlenbereich mit 2 Nachkommastellen. So könnte man etwas rumtricksen.

 

[Network]

Wenn du byte verwendest hast du genau 256 Zahlen, bei short immerhin knapp 64k, die du repräsentieren kannst. Wie willst du denn damit genügend genau fließkommazahlen darstellen?

Um was für Zahlen gehts dir denn? Wenn du bspw. Euro Beträge hast könntest du die als cent in nem short abspeichern. Bei der Ausgabe durch 100 geteilt hast du dann nen kleinen Zahlenbereich mit 2 Nachkommastellen. So könnte man etwas rumtricksen.

Naja die Variablen dafür sollen kein Ergebniss einer Rechnung darstellen, sondern nur einen bestimmten Wert für eine Rechnung wie bspw. .125 oder .1. Mehr wird keinesfals benötigt.
Ich empfinde es als zu Schade dafür soviele bits rauszuwerfen.

Und um was für Zahlen es sich handelt... naja sie sind undefiniert. Es handelt sich einfach um Einflusswerte auf eine Rechnung.

Das mit dem Trick hatte ich nicht bedacht. So könnte ich Arbeitsspeicherzugriffszeit und Speicherplatz auf die CPU übertragen.
Zahlen zu Teilen ist ja auch nicht gerade das Wahre.
Das muss ich nachprüfen...
(Ich muss aufpassen nicht wie ein Verrückter zu klingen Aber selbst ein Sandkorn kann die Waage zum kippen bringen )

Ein float besteht ja eig. auch nur aus 2 shorts. Ich hatte gehofft irgendwie direkt auf das 2. short zugreifen zu können.

 

[pro2]

Auf einem aktuellen PC, der nicht gerade aus dem Jahre 1700 stammt, macht dieses herumspielen mit den nativen Datentypen übrigens absolut 0 Unterschied. Das ist meist nur Zeitverschwendung sich darüber groß Gedanken zu machen und wenn man seinen Quellcode optimieren will, sollte man an anderen Punkten ansetzen. Diese Diskussion gab darüber gab es hier aber meines Wissens schon öfter.

 

[Spacerat]

Da an Bits zu sparen ist keine Gute Idee. Bei der Verwaltung von Variablen kleiner als 32 Bit werden ohnehin volle 32 Bit verwendet. Kanns die ja mal 'ne Klasse bauen, die nur Byte-Konstanten besitzt, diese kompilieren und dir anschliessend mal den Constantpool des Bytecodes ansehen. Da findest du nur noch ints. Das ist mitunter einer der Gründe dafür, dass Decompiler keine booleans in Methoden dekompilieren können.

 

[Network]

Da an Bits zu sparen ist keine Gute Idee. Bei der Verwaltung von Variablen kleiner als 32 Bit werden ohnehin volle 32 Bit verwendet. Kanns die ja mal 'ne Klasse bauen, die nur Byte-Konstanten besitzt, diese kompilieren und dir anschliessend mal den Constantpool des Bytecodes ansehen. Da findest du nur noch ints. Das ist mitunter einer der Gründe dafür, dass Decompiler keine booleans in Methoden dekompilieren können.

Selbstverständlich, je nachdem ob man ein 64bit oder 32bit System verwendet, werden die Daten automatisch "aufgerundet". Jedoch ist es ja nunmal unter Java so, dass wenn man mehrere bytes erstellt, die alle im selben Integer gespeichert werden.
Genauso bei boolean, werden alle boolean bits im selben Integer gespeichert.

Naja ich denke dann muss ich mich mit 32 bit rumschlagen.
Btw. wer sagt dass ich das "Programm" für einen Heimrechner verwende.

Danke
Gruß
Network

 

[Spacerat]

Selbstverständlich, je nachdem ob man ein 64bit oder 32bit System verwendet, werden die Daten automatisch "aufgerundet". Jedoch ist es ja nunmal unter Java so, dass wenn man mehrere bytes erstellt, die alle im selben Integer gespeichert werden.
Genauso bei boolean, werden alle boolean bits im selben Integer gespeichert.

Da muss ich dich leider enttäuschen. Alles unter 32 Bit wird unabhängig von seinem Typ als 32 Bit gespeichert. Der Constantpool einer Java-Klasse kennt neben Stringliteralen (UTF8 / Unicode) nur Integer, Float, Long und Double. Die JVM wird solche Werte anschliessend kaum anders verwalten können. Alles was im Quelltext als boolean, byte, char bis rauf zum (ausschliesslich) int verwendet wird, dient dem Programmierer sozusagen nur als Hilfsmittel, damit booleans nicht plötzlich den Wert 2 bekommen können. Ein boolean "verwurstet" also glatte 31 Bits und man kann nur sehr wenig dagegen tun.

 

[Nardian]

[...] Ein boolean "verwurstet" also glatte 31 Bits und man kann nur sehr wenig dagegen tun.

Möcht nur kurz ergänzen dass man durchaus mit "wenig" Arbeitsspeicher arbeiten kann, indem man bei sehr vielen boolean variablen (ich red grad von > tausenden / millionen booleans) kann man sich schon überlegen ein int / long herzunehmen und auf bit-ebene selber 0 und 1 zu setzten / zu lesen.

Aber wie schon am Anfang des threads erwähnt, bei so kleinen programmen lohnt es sich nicht sich um sowas Gedanken zu machen.


Der Vollständigkeitshalber: Die Idee mit long und Bits einzeln setzten ist bereits als BitSet implementiert in Java.

 

[Spacerat]

Ja, das wollte ich eigentlich zuvor auch noch erwähnen. Zumal die Zahl dieser Abermillionen Booleans ja relativ bekannt ist, bzw sich zumindest errechnen lässt. Diese "komprimierten" Booleans wollen nämlich auch addressiert werden. Daraus folgt, dass ich für 32 Booleans, die in ein Int gepackt wurden, mindestens 5 (Adress-) Bits benötige, für 64, 6, für 128, 7 usw. Schliesst man das Negativ-Bit eines ints (als Adresserweiterung) aus, so wäre eine Staffel komprimierter Booleans erst bei [c](2 hoch 31)[/c] (=2147483648) ausgeschöpft. Aber wofür würde man so viele Booleans benötigen?

 

[Network]

Möcht nur kurz ergänzen dass man durchaus mit "wenig" Arbeitsspeicher arbeiten kann, indem man bei sehr vielen boolean variablen (ich red grad von > tausenden / millionen booleans) kann man sich schon überlegen ein int / long herzunehmen und auf bit-ebene selber 0 und 1 zu setzten / zu lesen.

Aber wie schon am Anfang des threads erwähnt, bei so kleinen programmen lohnt es sich nicht sich um sowas Gedanken zu machen.


Der Vollständigkeitshalber: Die Idee mit long und Bits einzeln setzten ist bereits als BitSet implementiert in Java.

Es gibt echt eine Klasse BitSet dafür? Ähm... wie wäre es einfach mit "<< >> & | ^ "?
Wenn man das auf die konventionelle Weise macht, dann funktioniert das auch ohne Addressierung indem man im Quelltext einfach mal schnell den gewüschten Wert heraus "cpu"ed. (<- Wusste kein anderes passenderes Wort im Moment.)

Aber ich denke die Geschichte ist damit gegessen.

Gruß
Net

 

[Nardian]

Es gibt echt eine Klasse BitSet dafür? Ähm... wie wäre es einfach mit "<< >> & | ^ "?

[...]

Jupp gibts ist halt oft um einiges bequemer als sich immer mit den bit-operationen selber zu beschäftigen und immer darauf zu achten dass man alles richtig macht. Die BitSet kümmert sich eben auch darum dass er selber intern ein long[] hat, wo er beliebig weitere longs anlegt falls du mehr platz brauchst
ist also echt nett

 

[Spacerat]

Wenn man das auf die konventionelle Weise macht, dann funktioniert das auch ohne Addressierung indem man im Quelltext einfach mal schnell den gewüschten Wert heraus "cpu"ed,

Nenn' es doch einfach Filtern, Verknüpfen oder Verschieben.
Aber auch wenn das Thema durch ist, ohne Addressierung funktioniert es auch auf die konventionelle Art nicht, selbst wenn es so aussieht. Bei ">>" und "<<" muss stets die Anzahl der Bits um die verschoben werden soll mit angegeben werden und bei Verknüpfungen muss man die Wertigkeiten der Bitstellen, die man verknüpfen will, kennen.
Vllt. nennt man diese Art der Adressierung auch anders, weil die Adressen, die man damit erreicht um eine bestimmte Anzahl Bits genauer sind, als es jemals ein Adressbus sein kann. Bitadressierung muss also auf dem Datenbus erfolgen und das geht nur mit zusätzlichem Aufwand. In der Regel spart man sich diesen Aufwand und gibt sich mit dem zufrieden, was der Adressbus der CPU hergibt.