Eigenen Datentyp Definieren

Hallo,

ich find leider nichts passendes in der Suche und bei Google.

Wie kann ich einen eigenen Datentyp als Struktur Erstellen so wie Int oder Byte es ist.

Ein beispiel.

Ein byte hat 8 Bit und kann 0-255 Darstellen.
Wie kann ich nun meinen eigenen MiniByte Datentyp erstellen der 0-127 Darstellen kann und eine größe von 7 Bit hat.

Danke fürs Lesen (und antworten^^)

Hallo Armitage,

kurz gesagt, würde ich sagen: gar nicht. Eigene primitive Typen kann man nicht schaffen. Nimm Byte.

herbivore

Du könntest aber einen Typen schaffen, der auf Byte basiert und die Einhaltung des Wertebereichs prüft.

Hallo Borg,

wie meinst du basiert? byte ist sealed.

herbivore

Nimm ein sbyte (signed byte)

Dann hast Du den Bereich von -127 bis + 127

Dann ignorierst Du alle negativen Werte.

Ein solcher Datentype mit nur 7 bit bringt eh keine Vorteile (der Speicherverbrauch eines 7 bit-Types kann nie kleine sein als 8 byte).

Welches Ziel verfolgst du denn mit der Erschaffung diesen Typs?

Kann mir mal jemand erklären warum ein 7Bit Typ niemals kleiner sein kann als ein 8Bit Type?

Hallo Armitage,

naja, du kannst eben selbst keine primitiven Typen definieren. Du kannst eigene Typen nur auf primitiven Typen aufbauen bzw. aus ihnen zusammenbauen. Der kleinste Typ, auf den du aufbauen kannst, ist byte.

herbivore

Weil kein Computer 7 Bit elementar verarbeiten kann.

Computer arbeiten ja mit Dualzahlen, sprich immer mit 2er Potenzen, bzw. deren Summanden. Deshalb wurden auch Prozessoren so entwickelt das sie Dualzahlen am effizientesten verarbeiten können. Deshalb war der erste Microprozessor von Intel ein 4 Bit Microprozessor, wobei 4 Bit die Busbreite angibt. Sprich wieviel Daten gleichzeitig an den Prozessor gesendet werden können damit der die verarbeitet. Die logische Weiterentwicklung war dann 8 Bit Prozessoren. Mit denen konnte man dann schon ein 8 Bit Wert, oder 2*4Bit gleichzeitig an den Prozessor schicken. Und so gings weiter. 16 Bit, 32 Bit und aktuell halt die 64 Bit bei Desktop CPUs. Wenn der Prozessor die Daten empfängt über den Datenbus, muss er sie ja auch irgendwo zwischenspeichern. Das tut er in Registern die sinnvollerweise genauso groß sind wie die Daten die er empfängt. 4 Bit Register gibts glaub ich nicht mehr in Desktop CPUs, aber auf jedenfall kann man Teile von großen Registern auch einzeln mit 8 Bit ansprechen.

Nun zu deinen 7 Bit. Klar kannst du die an den Prozessor schicken, nur wo packt er sie hin? Richtig, in ein 8 Bit Register, das ist das kleinste was er hat, und daher die Aussage das nen 7 Bit Wert nie kleiner ist als ein 8 Bit Wert in der Praxis.
Mit dem Arbeitsspeicher ists genauso, da kannst du auch nur 2er Potenzen addressieren, und somit würdest du auch dort immer 1 Bit zuviel haben.

Wo wir vielleicht grad dabei sind. Grob kann man sagen das ein Prozessor mit Ganzzahlen in seiner Prozessorbreite am effektivsten arbeitet. Deshalb macht es eigentlich wenig Sinn Datentypen wie short zu verwenden - außer man muss wirklich bei der Größe sparen, was dann wiederum auf die Laufzeit sich aufwirkt.

EDIT: Okay, meine Erklärung geht davon aus das man selbst kleinere Datentypen definieren könnte 😉

Gefällt mir zwar nicht aber muss ich wohl mit leben.
Danke für die Erklärungen.

Warum wolltest du denn ein 7 Bit Datentyp? Wegen dem Wertebereich oder dem Speicherverbrauch? Ersteres kann man erreichen indem man z.b. Programmierhans sein Vorschlag verfolgt, zweiteres geht technisch einfach nicht auf Desktop CPUs.

Sprachen wie C bieten z.B. Bitfelder an wo man explizit festlegen kann das ne Struktur z.B. 12 Bit groß sein soll, das 1. Element von mir aus 5 Bit und das zweite von mir aus 7 Bit um auf die 12 zu kommen. Aber selbst dann unterliegst du den technologischen Beschränkungen der CPU und es werden bei Operationen größere Datenmengen benutzt als man angegeben hat. Sprich auch da hättest du keinen Vorteil.

Also ob die Cpu nun größere benutzt ist mir egal.
Mir geht es nur um den Speicherbedarf und wenn ich 12 ansatt 16 auf der Festplatte speichern könnte wäre mir das sehr recht.

Hallo Armitage,

natürlich kannst du einen Datentyp schreiben, der eine Folge von 7bit-Werten dicht an dicht gepackt in einem Byte-Array speichert. Dann bräuchte man für 8 Werte nur 7 Bytes statt 8 Bytes.

herbivore

Muss ich mal drüber nachdenken ob sich das gebrauchen lässt.

Also das mit dem Bit Feldern würde mich Interresieren.
Aber nach all den Erläuterungen verstehe ich es so.
Das ich zwar mit den Bitfeldern einen 15Bit Datentyp Künstlich Erzeugen kann.
Auf der festplatte aber wird dann ein 16Bit Datentyp liegen, korrekt?

Hallo Armitage,

auf der Festplatte liegen so gesehen immer Bytes. Aber du kannst natürlich in diesem Bytes alles speichern, was du willst. Zum Beispiel so wie Bild im Angang.

herbivore

Ok, also dann wäre ein 15 Bit Datentyp immer noch eine 4 Byte darstellung auf der Festplatte und damit genauso groß wie ein 16 Bit Datentyp.

Hallo Armitage,

16 bit wäre 2 Byte, nicht 4. Und ja, wenn du einen einzelnen 15 Bit Wert speichern willst, dann musst du das in 16 bit tun ...mal abgesehen davon, dass man Bytes auf der Festplatte nur clusterweise allokieren kann, wodurch normalerweise dann schon mindestens 4kb belegt sind.

Aber um wenige Werte kann es doch bei den heutigen Festplattengrößen doch gar nicht gehen. Wenn dann um richtig viele. Und da kannst du die Bits so zusammen schieben, wie auf dem Bild gezeigt.

Wenn es nun wiederum geht deutlich Platz zusparen, dann wäre wohl Kompression (z.B. ZIP) der Daten ohnehin besser.

So richtig klar, worüber wir reden, ist es mir immer noch nicht. Vielleicht hilft ja ein freundliches: Speicherplatz ist heutzutage vollkommen egal. Jedenfalls muss man eigentlich keine einzelnen Bits sparen.

herbivore

Ja 8Bit weiss ich eigentlich auch warum ich da ebend mit 4 Gerechnet habe weiss ich auch nicht sorecht.
Also Speicherplatz ist mir nicht egal ich kann auch nach ein paar Monaten ein 2 TB System voll machen mein Bedarf ist hoch.
Aber genauer erläutern werd ich das nicht.

Original von Armitage
Also das mit dem Bit Feldern würde mich Interresieren.

Naja, Bitfelder gibts in .Net eh nicht 😉

15 Bit wären eher 2 Byte 😉 Aber Herbivores Antwort will auf was anderes hinaus. Und zwar dass du zwar 8 Bit Typen benutzt aber nur immer 7 Bit verwendest. In Herbivores Bild sinds jetzt 6 Bit. Beim ersten Byte bleiben deshalb 2 Bit übrig, die werden für den nächsten Wert mitbenutzt, somit werden vom nächsten Byte nur 4 Bit benötigt usw. Damit kann man schon Platz sparen wenn sie hintereinander geschrieben werden. Aber, bei der Verarbeitung hast du immer den Overhead weil du den Wert erst aus dem Byte rausfummeln musst.

Wie Herbivore auch schon einen Beitrag vorher geschrieben hatte, sparst du bei 8 7Bit Werten 1 Byte gegenüber 8 Bit Werten. Ist nur die Frage ob sich das lohnt. Bei 80 Werten wären es 10 Byte, bei 800 Werten 1000 Byte, also noch net mal 1 kB - um 100 kB zu sparen bräuchte man schon 80000 Werte, usw...

Bei Speichergröße im GB Bereich wären mir selbst nen paar MB scheiß egal 🙂

Ich hoffe du siehst das diese Überlegungen für PCs eigentlich müßig ist weil es nicht wirklich nen Vorteil bringt.

EDIT: Ach verdammt, zu langsam geschrieben

Hallo Borg,

wie meinst du basiert? byte ist sealed.

herbivore

Mit auf "Byte basiert" meinte ich natürlich nicht Vererbung sondern Aggregation in einen eigenen Datentyp, der dann auch eigene Operatoren und implizite und explizite Konvertierungen definiert.

Original von herbivore
Hallo Armitage,

auf der Festplatte liegen so gesehen immer Bytes. Aber du kannst natürlich in diesem Bytes alles speichern, was du willst. Zum Beispiel so wie Bild im Angang.

herbivore

Hallo nochmal,

ich verstehe noch nicht ganz und für meine Weiteren überlegungen ist das schon wichtig. Wie das umsetzt was du da meinst.
Ich sehe du Ordnest dem Byte einfach ein Zeichen zu was 6Bit größe hat.
Und danach werden die Ergebnisse dicht nacheinander zusammengepackt.
Aber wie speichert man den dann solche "6bit Zeichen" dicht zusammengepackt und Speicherplatz sparend ab so das sie noch auseinander gehalten werden können.
Den irgendwo müssen sie ja gespeichert werden und Direkt gespeichert hätten sie 8 Bit größe.
Wenn ich sie in ein Array packe dann müsste ich sie ja irgendwie voneinander Trennen würde dann nicht die ganze Einsparung wieder verloren gehn?

Hallo Armitage,

du schreibst einen Indexer, der aus dem Index erst die Position der Bits im Byte-Array ausrechnet und dann die entsprechenden Bits setzt bzw. liest.

Also

Index 0 => Byte 0, Bits 0-5
Index 1 => Byte 0, Bits 6-7 und Byte 1 Bit 0-3
Index 2 => Byte 1, Bits 4-7 und Byte 2 Bit 0-1
Index 3 => Byte 2, Bits 2-7

usw.

Für die Bitoperationen benutzt du die Bitoperatoren <<, >>, |, &, siehe :rtfm: Doku.

Von Platte liest bzw. auf die Platte schreibst du einfach das Byte-Array.

herbivore

Hi Armitage,

alle Werte die wir erfassen, haben es an sich, eine gewisse Regelmässigkeit zu haben.
Wenn wir diese Regelmässigkeit erkennen und entsprechende Mittel finden sie zu packen, sparren wir jede Menge Platz. Und wenn die Reduzierung auf 7 Bit, das Einzige ist, das wir tun können, ist es zwar nicht die beste Möglichkeit, aber immerhin.
Zu schade, lassen sich die Daten nicht irgendwie zippen, oder die Differenz ausnutzen die zwischen Wert 1 und 2 liegt!
Bei Wellenformen kann man ja einfach sagen: Die Welle geht jetzt 6 Werte geringfügig nach oben, und speichert die Aufsteigenden Werte mit Bit[0..2] also 0-3
Geht die Welle jedoch sehr heftig nach oben, speichert man die aufsteigenden Werte mit Bit[0..4] 0..15.
Oder man erstellt eine Tabelle von der Häufigkeit der Zahlen in einem gewissen Zeitraum und behilft sich mit dieser Tabelle die Daten zu minimieren. Da du das jedoch, wie ich befürchte, auf deine anfallenden Daten nicht anwenden kannst, bleibt dir immerhin die 7 Bit Methode. Ich könnte dir zwar eine schreiben, aber herbievore hat dir schon so gut wie alle gezeigt.

nun, vielleicht konnte ich ja helfen, und wenn nicht, war es zwar nicht die beste Möglichkeit dir zu antworten, aber immerhin 🙂

Gruss TEry

Ich mag die 7Bit Methode dieser Art nicht daher hab ich sie gar nicht probiert.
Eine Funktion die auf häufigkeit prüft und das ganze dann packt hab ich gestern geschrieben aber das war mehr eine Spielerei das hat nicht viel gebracht.
Mein nächster Ansatz von dem ich erstmal nichts sagen möchte dürfte länger dauern der wird irgendwie schweinisch kompliziert^^.

Der Preis um dieserart 1/8 des Speichers zu sparen beträgt mindesten eine Verzehnfachung der Latenzzeit und eine deutliche Verringerung des Durchsatz.
Das ist kontraproduktiv, da Rechenzeit teurer als Speicherplatz ist.
Speicher einfach ein Byte (eventuell in einen eigenen Datentyp mit Wertebereichsprüfung verpackt) und gut ist.

Also ich bin mir eigentlich sicher das die Frage unnötig ist aber ich frag mal zur Sicherheit^^.
Jedenfalls nachdem was ich weiss und alledem was ich so bisher gelesen habe an verschiedenen Kompressions Allgos.
So die eigentliche Frage^^:

Gibt es einen Allgo der fast unendlich Komprimiert ohne Verlust?
Das er zum beispiel mit 100 Gig startet und nach 10 durchläufen hat man 5 gig übrig oder sowas in der Art.
Und dann kann ich aus den 5 Gig wieder die 100Gig herstellen ohne Verlust von Daten.

Ich glaube nicht das es sowas gibt aber naja zur Sicherheit frag ich einfach mal Leute vom Fach.

MFG

Original von Armitage
Ich glaube nicht das es sowas gibt aber naja zur Sicherheit frag ich einfach mal Leute vom Fach.

Gibt es nicht, kann es auch nicht geben.

Aus Mathematischen Gründen?

Hallo,

Ja aus mathematischen Gründen. Grundsätzlich gilt: es gibt keine Möglichkeit, eine beliebige Datei auch nur um 1 bit zu komprimieren. Die Ursache hierfür ist das sogenannte Pigeon-Hole-Prinzip: wenn ich eine Taubenschlag habe mit 10 Löchern (Eingänge) und 11 Tauben wollen in den Taubenschlag hinein, so muss mindestens ein Eingang zweimal verwendet werden.

Ähnlich ist es mit der "Komprimierung": ein byte kann potenziell 256 verschiedene Zustände speichern. Würde ich diese 8 bits auf irgendeine Art und Weise in 7 bits speichern wollen, habe ich ein Problem: 7 bits können nur 128 Zustände speichern. Da heißt, das mindestens 128 der 256 Zustände eines Bytes keine eindeutige Kodierung in den 7 bits erhalten (die "Löcher des Taubenschlags" werden mehrfach verwendet). Im Umkehrschluss ist es dadurch nicht möglich, aus den 7 bits wieder alle 256 möglichen Zustände des bytes zu "dekomprimieren".

Wäre es möglich, eine beliebige Datei auch nur um 1 bit zu komprimieren, könnte man das Ergebnis rekursiv wieder um ein bit verkleiner bis am ende 0 bits überblieben. Es dürfte einleuchten, dass das unmöglich ist.

Warum funktionieren dann Formate wie Zip oder MP3? Ersterem (ZIP) gelingt die Platzsparende Kodierung der Daten, indem von Redundanz und Wiederholung in den Daten gebraucht gemacht wird. Zum einen kann man bytes platzsparend kodieren, indem man häufig vorkommende Datenworte mit einem kurzen Code versieht und seltene Worte mit einem langen Code (Entropiekodierung). Zum anderen gibt es Techniken wie Runlength-Encoding, bei der man sich wiederholende Bytesequenzen als eine Art Formel aufschreibt (statt 00000000 z.B. "8x0"). Diese Techniken funktionieren, weil (und wenn) die zu komprimierenden eben nicht "beliebige" Daten sind, sondern die nötige Redundanz aufweisen. So lässt sich Text gut zippen, während z.B. Fotos schlechte Kandidaten sind (auf Grund der niedrigen Redundanz und hohen Entropie). Formate wie MP3 oder JPEG erreichen die Reduzierung des benötigten Speicherplatz zusätzlich dadurch, dass nicht sicht- oder hörbare Teile aus den Daten entfernt werden, etwa durch die Entfernung hoher Frequenzen (sehr einfach ausgedrückt, diese Formate bedienen sich einer Vielzahl mathematischer Tricks) .

Grüße,
Andre

Was sind das eigentlich für Daten, die du speichern willst, und wie groß sind die Datenmengen? Das würd mich schon sehr interessieren...

Gute Erklärung VizOne.

Rein Theoretisch wenn ich das wollte dann wären das natürlich rein Theoretisch mehrere Tbs an .avi, mkv, ogm, mpg.
Das ist natürlich nur rein Theoretisch und heisst nicht das es bei mir so ist.

MFG

Ich frage mich jetzt ehrlich gesagt, was die Speicherung von "mehreren TB" Videos mit deinen obigen Fragen (vor allem der ersten) zu tun hat???

Aber um es kurz zu sagen: Videos kannst du nicht mit einer der allgemeinen Packer (ZIP, RAR etc.) weiter komprimieren. Dabei kommen höchstens 1% bis 3% Verkleinerung heraus, dafür muss die Datei aber ewig gepackt und entpackt werden (wieder Latenz/Durchsatz in Relation zum Speicher).
Die einzige Möglichkeit Videos zu verkleinern ist deren Bitrate zu reduzieren. Um den damit einhergehenden Qualitätsverlust so gering wie möglich zu halten, sollte man dazu aber formatspezifische Requantisierer einsetzen...

Ausserdem bekommst du momentan interne 500GB Festplatten für locker 120€.
Besorg dir nen alten Rechner (400MHz reichen locker, ideal wäre ein älterer Server mit PCI-X) mit LAN (Gigabit, wenn Netz-Infrastruktur und PCI-X vorhanden) und zusätzlichen IDE-Controllern, knall dort Linux rauf und immer wenn du Bedarf hast, baust du eine neue Platte ein..

Ok, aber wenn du solche Sachen wie Videos speichern willst, wie kommst du dann an die 7 Bit, die du speichern willst? Es werden doch alle 8 Bits benötigt. Du hast die ganze Zeit so überzeugt, davon geredet, dass du 7 Bits speichern willst, dass ich davon ausgegangen bin, dass es sich um eine Art wissenschaftliche Auswertung handelt, die sehr viele Messdaten erzeugt, die in 7 Bit reinpassen. Und ich versteh auch nicht ganz, wie das gemeint hast, dass du TBs an Videos speichern willst, sind sie nicht schon irgendwo gespeichert?

Ach das war eine idee zum Komprimieren ohne Verlust deswegen hab ich nach den 7 Bit gefragt. Wissenschaftlich wäre schön wenns so wäre aber da habe ich wohl keine Begabung für^^.

Wenn du est schafst 8 bit in 7 zu kompremieren investiere ich mein ganzes Geld in deine Idee xD 😁

Und ich bastele dann eine rekursive Methode, die es schafft, alle Information des gesamten Universums in nur 7 Bit zu speichern...

EDIT: Dann dürfte Beamen auch kein Problem mehr sein...

Gut, dann werd ich dran arbeiten euch nicht zu enttäuschen^^.
Für Gott und Vaterland^^

Original von Nopileos
Wenn du est schafst 8 bit in 7 zu kompremieren

Das komprimieren ist doch gar kein Problem.... also her mit der Kohle 🙂... das Problem entsteht ja erst bei der dekomprimierung 😉

Mal sehn ich hab so ne fixe Idee mal schaun was da rauskommt aber nicht sobald hab nen Heiden arbeit wie Brennholz, Steintreppe auf 30m länge, Scheune zu Ende ausbauen, 2 Häuser streichen usw... Unendlich fortsetzbar.

Alles Ausreden! ggg

Aber das mit der Komprimierung ist wirklich interessant, wer sich mal näher damit beschäftigen will, bei Wikipedia gibt es die Erklärung, Pseudocodes zum Komprimieren und Dekomprimieren sowie Beispiele für den LZW-Algorithmus: http://de.wikipedia.org/wiki/LZW

Viele Grüße,
Christian

Hallo Armitage,

Mal sehn ich hab so ne fixe Idee mal schaun was da rauskommt

nichts. Kann ich dir - nach dem ich die ganze Diskussion gelesen habe - jetzt schon verbindlich bestätigen. 🙂 Du kannst dir die Arbeit sparen.

herbivore

Hast recht (wie immer) aber versuchen musste ich es trotzdem.
Jetzt fällt mir allerdings nichts mehr ein wie man das lösen könnte dann muss ich mir wohl was anderes suchen an Beschäftigung mit C#.

MFG