Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Mage Zahlen!?! (https://www.delphipraxis.net/27445-mage-zahlen.html)

atreju2oo0 16. Aug 2004 08:49

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:

Tabak 16. Aug 2004 10:07

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

Nikolas 16. Aug 2004 10:25

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.

atreju2oo0 16. Aug 2004 15:54

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...

Tabak 16. Aug 2004 20:03

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:

Nikolas 16. Aug 2004 20:38

Re: Mage Zahlen!?!
 
Zitat:

P.S:
Primfaktorzerlegung bringt meiner Meinung nach nichts, da Potenzen wesentlich schneller gegen unendlich streben als Faktoren...
Haste eigentlich auch recht. Bis jetzt ist die Faktorisierung noch ein Problem zu dem es keinen (schnellen) Algo gibt. Also für größere Zahlen nicht so toll geeignet.
Gibts denn was schön schnelles für Wurzeln??? :gruebel:

atreju2oo0 16. Aug 2004 21:01

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.
Seite 3 von 3     123   

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