Zahlendarstellung
-
SeppJs 256-er-System spart am meisten Platz.
-
jedes System mit 2^x Ziffern, bei dem die Ziffern-Bitlänge x die Wortlänge der Speicherzellen teilt, ist gleich gut, nämlich verschnittfrei - egal ob das nun Oktalsystem (x=3) auf 18- oder 36-Bit-Maschinen ist, Hex (x=4) auf 4-, 8-, 16-,32- oder 64-Bit-Maschinen ist usw ...
-
Mann, ihr erzaehlt ein Quatsch...
-
TGGC schrieb:
Mann, ihr erzaehlt ein Quatsch...
Immer diese hilfreichen Kommentare die einen völlig unbefriedigt zurücklassen
. Weder weiß man auf welche Aussage sie sich beziehen, noch was der Quatsch sein soll, noch was angeblich richtig wäre.
-
!rr!rr_. schrieb:
jedes System mit 2^x Ziffern, bei dem die Ziffern-Bitlänge x die Wortlänge der Speicherzellen teilt, ist gleich gut, nämlich verschnittfrei - egal ob das nun Oktalsystem (x=3) auf 18- oder 36-Bit-Maschinen ist, Hex (x=4) auf 4-, 8-, 16-,32- oder 64-Bit-Maschinen ist usw ...
Ja, das ist sicherlich richtig.
Aber unter Hex versteht er "d34db33f", sind 8 Zeichen, sind in der Datei 8 Byte. Oktal wäre diese Zahl sogar als "32323331477" mit 11 Bytes dabei. Im 256-er-System würden 4 Bytes reichen.
-
ok danke
damit wäre meine frage beantwortet
-
also wenn ich auf kompakte Speicherung wert lege, dann codiere ich doch nicht eine Hexziffer in ein Byte, sondern in ein Nibble. Allgemein ist es latte, wie viele Ziffern man hernimmt, solange
a) |Ziffernvorrat| = 2^x
und
b) x teilt Wortbreite der Maschineerfüllt sind - die Speicherausnutzung ist dann immer die selbe, nämlich optimal.
-
wenn du mir das jetzt noch an einen beispiel zeigst und mir sagen kannst, wie ám was als nibble speichert wäre ich sehr glücklich
-
ein Nibble sind 4 Bit.
Beispiel:
Hex:
|Ziffernvorrat| = 2^4 => Speicherung mit 4 Bit pro Ziffer funktioniert verschnittfrei auf jeder Maschine mit 4-, 8-, 12-, 16-, ... 4n-Bit-Wörtern
Oktal:
|Ziffernvorrat| = 2^3 => Speicherung mit 3 Bit pro Ziffer funktioniert verschnittfrei auf 3-, 6-, 9-, 12-, ... 3n-Bit-Wörtern.
Auf einer alten 18-Bit-Maschine wäre Hex (im Ggs zu Oktal) nicht optimal, weil man in einem 18-Bit-Wort genau 6 Oktalziffern unterbringt, aber nur 4.5 Hexziffern (d.h. 4 Hexziffern mit zusammen 4 x 4 = 16 Bits, und 2 Bits bleiben übrig)
-
wenn du mir das jetzt noch an einen beispiel zeigst und mir sagen kannst, wie ám was als nibble speichert wäre ich sehr glücklich
-
Oder man wählt einfach beim Schreiben der Dateien einfach den Binärmodus und spart sich den ganzen Quatsch..
-
volkard schrieb:
wenn du mir das jetzt noch an einen beispiel zeigst und mir sagen kannst, wie ám was als nibble speichert wäre ich sehr glücklich
der einfachste Weg führt sicherlich über den Aufbau eines 4-Bit-Einplatinensystems mit einer CPU wie der 4004 (notfalls selbst löten, es sind nur rund 2300 Transistoren) - die rechnet nativ mit Nibbles.
Der kompliziertere Weg führt über Ausdrücke wie (0xf0 & H | 0x0f & L), die man in manchen Programmiersprachen findet.
-
!rr!rr_. schrieb:
Der kompliziertere Weg führt über Ausdrücke wie (0xf0 & H | 0x0f & L), die man in manchen Programmiersprachen findet.
Um damit die Zahl ins 256-er System zu überführen vor dem Speichern?
-
richtiiich
-
gibs das auch in c++?
errinnern tut es mich ja an hexadezimalschreibweise, aber mit dem H und L ist das leicht verwirrend
-
SeppJ schrieb:
TGGC schrieb:
Mann, ihr erzaehlt ein Quatsch...
Immer diese hilfreichen Kommentare die einen völlig unbefriedigt zurücklassen
. Weder weiß man auf welche Aussage sie sich beziehen, noch was der Quatsch sein soll, noch was angeblich richtig wäre.Die ganze Diskussion haette nach der ersten Antwort zu Ende sein sollen, danach kam doch komplett nur noch Quatsch.
Informationstheoretisch ist es schonmal Unsinn, denn der Informationsgehalt hat mit der Darstellung nichts zu tun, sondern nur mit der Wahrscheinlichkeit. Etwa eine beliebige Zahl aus dem Vorrat von 2^64 hat eine Information, da sie mit einer Wahrscheinlichkeit auftaucht. Ob das nun die ersten 2^64 natuerlichen Zahlen sind, oder die ersten Primzahlen, oder irgendwie ungleichmaessig auf dem Zahlenstrahl verteilte doubles ist egal, und wie ich die Zahl notiere auch.
Und auch praktisch ist es unsinnig, so Speicher sparen zu wollen. Das sieht vielleicht auf den ersten Blick so aus. Liegt aber letztendlich nur an der Codierung. Unwahrscheinliche Symbole sollten mit mehr Bits, wahrscheinliche Symbole mit weniger Bits codiert werden. Demzufolge stimmt !rr!rr_ Aussage "Allgemein ist es latte, wie viele Ziffern man hernimmt" grundsaetzlich fuer alle denkbaren Darstellungsmoeglichkeiten.
-
TGGC schrieb:
SeppJ schrieb:
TGGC schrieb:
Mann, ihr erzaehlt ein Quatsch...
Immer diese hilfreichen Kommentare die einen völlig unbefriedigt zurücklassen
. Weder weiß man auf welche Aussage sie sich beziehen, noch was der Quatsch sein soll, noch was angeblich richtig wäre.Die ganze Diskussion haette nach der ersten Antwort zu Ende sein sollen, danach kam doch komplett nur noch Quatsch.
Informationstheoretisch ist es schonmal Unsinn, denn der Informationsgehalt hat mit der Darstellung nichts zu tun, sondern nur mit der Wahrscheinlichkeit. Etwa eine beliebige Zahl aus dem Vorrat von 2^64 hat eine Information, da sie mit einer Wahrscheinlichkeit auftaucht. Ob das nun die ersten 2^64 natuerlichen Zahlen sind, oder die ersten Primzahlen, oder irgendwie ungleichmaessig auf dem Zahlenstrahl verteilte doubles ist egal, und wie ich die Zahl notiere auch.
Und auch praktisch ist es unsinnig, so Speicher sparen zu wollen. Das sieht vielleicht auf den ersten Blick so aus. Liegt aber letztendlich nur an der Codierung. Unwahrscheinliche Symbole sollten mit mehr Bits, wahrscheinliche Symbole mit weniger Bits codiert werden. Demzufolge stimmt !rr!rr_ Aussage "Allgemein ist es latte, wie viele Ziffern man hernimmt" grundsaetzlich fuer alle denkbaren Darstellungsmoeglichkeiten.
Dennoch ist dies nicht das was der Threadersteller wollte. Er wollte das 256er System. Man muss eben zwischen den Zeilen lesen können. Bei Gucky weiß ich eben schon, dass er sich nicht so gut ausdrückt und auch ganz bestimmt keine Fragen zur Entropie von Zahlensystemen stellt, auch wenn es auf den ersten Blick so aussieht.
-
Meine Basis = CHAR_BIT * sizeof( native_register_size ) * faktorBtw: ist "unsigned int" oder std::size_t oder irgend einer dieser typen als "native register size" durch den standard definiert?
