![]() |
Re: Mage Zahlen!?!
Die Idee die du verfolgst hat leider bereits im Ansatz einen Haken.
Um eine große Zahl darzustellen willst Du eine Funktionsdarstellung finden, die schneller ansteigt als die normale Darstellung der binären Zahlen. Das Problem ist das Potzenzfunktionen jedoch die schnellste Steigung hat und diese hängt vom Exponenten ab. Im Normalfall ist das zwei und braucht somit lediglich 1 Bit. Wenn Du jetzt einen beliebigen Exponenten wählst zum Beispiel 17 taucht folgendes Problem auf: Um alle Stellen darstellen zu können brauchst Du 17 Zustände => in diesem Fall 5 Bit. Damit nutzt Du denn Platz denn Du für den schnelleren Anstieg nutzt für die größeren Zustandsbeschreibungen. Ein weiterer Beweis wäre, dass nach deiner Idee eine Datei als Funktion komprimierbar wäre. Jedoch müsste dann auch die Komprimierte Funktion wieder komprimierbart sein und so weiter... Damit lässt sich dann also theoretisch jede Datei beliebig verkleinern. Das ist nach der Infomationstheorie jedoch nicht möglich! Falls Du wissen willst woher ich das weiß?: Ich habe vor nem halben Jahr den selben Ansatz verfolgt und bin dabei drauf gestoßen. Hatte sogar mit Partialbruchzerlegung gearbeitet und andere Mischformen durchgespielt... KEIN ERFOLG :( Aber UNMÖGLICH ist auch nur eine MEINUNG... :mrgreen: |
Re: Mage Zahlen!?!
Danke für deine ausführliche Informationen! Aber die selber Meinung vertrett ich trotzdem nicht. 87^15 (4 Stellen) = 123819426824732821912024192743 (30 Stellen) und je größer die Zahl desto mehr spart man ein - in % gesehen. :thumb:
Das Problem mit dem Speicher von so großen Zahlen, tja hm viel RAM kaufen oder so, ist ja bis jetzt alles nur theoretisch. Das Größere Problem ist die passende Funktion zu finden... - wass passt schon auf 255000255 - :gruebel: - Ich glaub, dass daran alles scheitert. :cry: Und noch kurz zur Informationsregel. Die kenn ich zwar nicht aber wie will man 17 kleiner machen? 13+4, 15+2, 7+8, 1*17.... brauch alles mehr Platz! mfg |
Re: Mage Zahlen!?!
Ich würde sagen, dass die kleinste mögliche Komprimierung, die mit einem einfachen Algorhytmus errechnet werden kann, die Primfaktorzerlegung ist. Bei Primzahlen siehts da genz schlecht aus, aber da könntest insgesamt noch ein paar Byte anhängen um dadurch eine besser zerlegbare Zahl zu bekommen.
|
Re: Mage Zahlen!?!
Mein Ansatz war:
geg.: Sei A1 eine natürliche Zahl (stellvertretend für die komplette Datei) ges.: Bestimme ein B1 mit (b1-A1<<A1) und (B1 element der Potenzfunktionen) daraus folgt dann ein A2 das wesentlich kleiner als A1 ist und auf das wider der Algo angewandt werden kann! Meine Probleme waren a) Wie bestimme und berechne ich B1 so, dass es möglichst nahe an A1 liegt? b) Wie speichere ich den erhaltenen Wert am effektivsten(Record hab ich genommen=> is aber Speicherverbrauch)? P.S: Primfaktorzerlegung bringt meiner Meinung nach nichts, da Potenzen wesentlich schneller gegen unendlich streben als Faktoren... |
Re: Mage Zahlen!?!
So, jetzt sind wir der gleichen Meinung! Genau da hängt der Fisch am Hacken! :coder2: Und so wies bis jetzt aussieht ist es uns wohl nicht vergönnt ein Haufen Geld zu machen... Trotzdem nochmals Danke für eure Hilfe! :hi:
|
Re: Mage Zahlen!?!
Zitat:
Gibts denn was schön schnelles für Wurzeln??? :gruebel: |
Re: Mage Zahlen!?!
Meiner Meinung nach müsste man das mit Tabellen lösen.
Ich hatte versucht Tabellen zu erstellen die Potenzen mit möglichst gleichbleibenden Abständen enthalten. Aus diesen sollte es dann möglich sein per Abschätzverfahren die geeignetste Potenz zu berechnen. Dazu habe ich übrigens nicht die gesamte Datei als Zahl behandelt sondern mir feste Byte-Blöcke vorgegeben und diese dann einzeln behandelt(16 Byte hatte ich gewählt)! Eventuell ist es mit größeren Blöcken einfacher geeignete Potenzen zu finden, aber ich bin halt leider gescheitert... Aber vom Prinzip her würde ich das Konzept schon noch gerne weiterführen. Ein bisschen probieren gehört halt mit dazu... :wall: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz