BigIntegers zum Speichern umwandeln oder "komprimieren"?

[-horn-]

moien,

ich muss für ein programm mit bigintegers umgehen. es können sehr langezahlen werden und seitenweise lang werden, wenn ich die speichern will.
ich würde die gerne irgendwie umwandeln oder komprimieren. ich dacht da zb darum den biginteger als string zu nehmen, dort entlang jeder zahl das gegenstück im alphabet zu zu weisen und das dann zu speichern. aber es wäre ja "meine" lösung, und vielleicht gibt es da was bessere.
es soll erstmal nur kürzer in der speicherdatei stehen und es muss perfekt rückwandelbar sein, wenn ich die speicherdatei wieder einlese.

hat das jemand schonmal gemacht?

Andreas

 

[madboy]

ich dacht da zb darum den biginteger als string zu nehmen, dort entlang jeder zahl das gegenstück im alphabet zu zu weisen und das dann zu speichern. aber es wäre ja "meine" lösung, und vielleicht gibt es da was bessere.

Willst du die Zahl als String speichern? Falls ja, warum?

Unabhängig davon könntest du einen Komprimierungsalgorithmus verwenden: Compressing and Decompressing Data Using Java

 

[-horn-]

moien,

als string, damit ich an den zeichen entlang gehen kann um dann immer zwei stellen umzuwandeln und dann zu kürzen.

zb wird aus 10081517
10=j
08=h
15=o
17=q

=>jhoq

bei zahlen größer 26 muss ich dann schauen, wie ich das löse, aber wird gehen.

und echte kompression möchte ich nicht, weil die datei noch ohne dekompression augenlesbar sein soll.

grüße, Andreas

 

[madboy]

Gehen wird das bestimmt, aber wenn du als Basis 100 nimmst (wie ich das aus deinen Posts raus lese), wirst du Probleme bekommen. Irgendwann gehen dir entweder die Zeichen aus, du bekommst unter Umständen Encoding-Probleme und/oder die Datei wird nicht so "augenlesbar" wie sie wohl sein soll.

Was ich nicht ganz verstehe: warum überhaupt komprimieren? Mit deinem Ansatz komprimierst du auf 50% im Gegensatz zur Zahlendarstellung und machst das Lesen dazu noch kompliziert. Warum nicht ganz auf die Kompression verzichten, wenn die Datei menschenlesbar sein soll? Bei heutigen GB-Preisen für Festplatten sollten die 50% nicht ins Gewicht fallen.

 

[nrg]

also wenn dann würde ich immer 3 zahlen zu einem char casten. dadurch solltest zu 66% kompression kommen. Das wird dann aber kaum mehr lesbar sein und ob es wirklich so sinnvoll ist, dass die Datei 20kb statt 60 ist, mag ich grad auch irgendwie zu bezweifeln.

 

[Illuvatar]

Vielleicht versteh ich was nicht, aber warum speicherst du nicht einfach direkt die Zahl, anstatt irgendwas mit Strings im 10er oder von mir aus 100er System rumzumachen?
Also mit der Methode hier und dann einfach so schreiben?

Edit: Die Forensoftware kriegt den 2. Link nicht hin Gemeint ist die Methode OutputStream#write(byte[])
Edit2: Danke Buttons... Anführungszeichen in URL-Tags... neumodischer Kram

 

[eRaaaa]

Edit: Die Forensoftware kriegt den 2. Link nicht hin Gemeint ist die Methode OutputStream#write(byte[])

Immer den Link-Button nutzen!
so

 

[Marco13]

Es geht nur darum, das ganze in eine Datei zu schreiben? Warum nicht einfach einen ObjektOutputStream in einen ZipOutputStream flanschen und sich im Phil Katz gebührenden Ruhm sonnen? :bahnhof:

 

[-horn-]

moien,

wie gesagt, es kann eventuell leicht eine integerzahl mit mehr 10^30 stellen dabei rauskommen, und wenn ich das einfach so in die datei speichere wäre das immer ein mega platzbedarf rein von den ziffern her.
und wie erwähnt möchte ich nicht extra zippen, weil ich das als datei ohne dekompressionsaufwand haben möchte, da da noch andere dinge in der xml-datei drin stehen, die ich brauche.

grüße, Andreas

 

[Illuvatar]

Ok, also in dem Fall ist wohl Marco13s Lösung auf jeden Fall zu bevorzugen.

Was du genau willst, ist mir aber immernoch ein Rätsel: Du willst die Zahl komprimieren, aber komprimieren willst du sie nicht???:L

ich würde die gerne irgendwie umwandeln oder komprimieren

weil ich das als datei ohne dekompressionsaufwand haben möchte

 

[bone2]

warum schreibst du das ganze nicht als byte in die datei?

wenn es unbedingt ein string werden soll kann man das toString mit Basis benutzen, das höchste mögliche ist 36

        byte[] ar = "ijhfohjgdsgheiouökaöshijhg3684394436ljaghdsajghdsaiuhpeaw853z83wopauw3tlo85z205ue".getBytes();
        BigInteger i = new BigInteger(ar);
        System.out.println(i);
        System.out.println(i.toString(36));

 

[Illuvatar]

warum schreibst du das ganze nicht als byte in die datei?

Das dachte ich ja auch erst - aber ich muss zugeben, dass etwas in der Größenordnung von 10^300 Bit die meisten Festplatten doch ziemlich gut auslastet

 

[Andi_CH]

wie gesagt, es kann eventuell leicht eine Integerzahl mit mehr 10^30 Stellen dabei rauskommen und wenn ich das einfach so in die Datei speichere, wäre das immer ein mega Platzbedarf rein von den Ziffern her.
Und wie erwähnt möchte ich nicht extra zippen, weil ich das als Datei ohne Dekompressionsaufwand haben möchte, da da noch andere dinge in der xml-datei drin stehen, die ich brauche.

Irgendwie denke ich es braucht einige klärende Worte, denn irgendwie läuft da einiges aneinander vorbei Illuvatar vermischt IMHO zwei Dinge.

Ich interpretiere das so, dass die XML Datei nicht gezippt werden soll weil sie ohne Aufwand gelesen werden soll, dass es aber einen Aufwand bedeuten darf, die bigint-Werte zu rekonstruieren.

Auf human readabililty der Bigint-Werte musst allerdings definitv verzichtet werden, wenn wirklich Platz gespart werden soll.
Ist readability ein Muss, würde ich auf ein kleines Programm setzen das die Daten dekomprimiert und anzeigt.

10^30 Stellen als 10^300 sind 996.6 Bit ;-) ~125Byte -> Es ist also möglich sein, den Wert in dieser Grössenordnung zu speichern, aber ob und wie das in XML der Fall ist, weiss ich nicht.

Gesucht ist als ein Algorithums der den Bigint-Wert z.B. in einen byte[] umwandelt
Dann diesen in die Datei schreibt
Den byte[] zurücklist
Den byte[] in bigint zurück wandelt

Ist das strukturiert genug?

 

[swp]

Ich würde das ganz krude machen:

ByteArrayOutputStream bOut = new ByteArrayOutputStream();
ObjectOutputStream oOut = new ObjectOutputStream(new GZIPOutputStream(bOut));
oOut.writeObject(myBigInteger);
oOut.flush();
oOut.close();
byte[] compressed = bOut.toByteArray();

Und zum zurücklesen:

ObjectInputStream oIn = new ObjectInputStream(new GZIPInputStream(new ByteArrayInputStream(compressed)));
BigInteger myBigInteger = (BigInteger) oIn.readObject();
oIn.close();

Statt ByteArrayOutputStream kannst du natürlich auch FileOutputStream nehmen oder woimmer du hin ausgeben willst. Und du kannst mit writeObject bzw. readObject auch mehrere Objekte hintereinander abspeichern. Um die korrekte Trennung und die richtige Behandlung der Daten kümmert sich Java. Du musst nur aufpassen, dass du die geworfenen Exceptions richtig fängst. IOExceptions sind klar, aber es können auch ClassCastExceptions und ClassNotFoundExceptions auftreten. Wenn du mit Java-eigenen Klassen arbeitest, sind letztere eher unwahrscheinlich - hier sollte fangen und als RuntimeException neu werfen reichen - aber ClassCastExceptions solltest du explizit behandeln.