Mage Zahlen!?!

[Tabak]

Hi,
Ich bräuchte einen Integer oder sowas in die Richtung, was ca 200 Mio. Stellen fassen kann. Gibt es sowas in Delphi? Das höchste, das ich bis jetzt gefunden hab war der Int64.
thx!

[LeoDD]

Früher hat man sowas mit Strings nachgebildet. Vielleicht is das einfacher.

[Markus]

Für was brauchst du 200 Mio, stellen :?: :?: :?: :?: :?: :?:

[sakura]

Suche mal nach HugeInt Delphi, da gibt es Bibliotheken für.

...:cat:...

[Tabak]

Vielen Dank für die schnellen Antworten! Hab das mit dem HugeInt gleich mal ausprobiert, aber als totaler noob hab ich ein neues Problem. Es wird eine SInteger.pas benötigt, die nicht beiligt sondern nur eine SInteger.dcu.
Was tun??? mfg

[Markus]

DCU ist die kompilierte Version der .pas. Du musst schauen, ob der Pfad der SInteger.dcu in deiner Bibliothke (Tools -> Umgebungsoptionen-> Bibliothek) mit eingebunden ist. Wenn nicht, musst du das nachholen. Dann müsste es gehen.

[Tabak]

Hm, hab das gemacht was du mir gesagt hast, die dcu scheint er auch gefunden zu haben, er sagt jedoch weiterhin: " [Fataler Fehler] Datei nicht gefunden: 'c:\programme\borland\delphi5\Projects\Bpl\Sintege r.pas' "
- so ganz vertseh ich das nicht.... :roll:

[Luckie]

Mal was anderes: Was sind "Mage Zahlen"? Das Wort "Mage" ist mir gänzlich unbekannt. :gruebel:

[GuenterS]

Du verwendest nicht zufällig eine Trial Version von Delphi?


Ich hatte mit meiner Trial Version mal probleme eine Komponente ohne Source zu verwenden bis ich draufgekommen bin, dass dies mit den Delphi7 Trials einfach nicht möglich ist.

[Tabak]

Oh! Mage ist kein Fachausdruck oderso - ein Rechtschreib fehler, "Mega" wäre besser *g*. Ich hab die Delphi5 Version und bis jetzt (zwar noch nicht sehr lange) auch keine Probleme mit der Bibliothek....
Gruß

[Tubos]

200 Millionen Stellen ist eine Zahl, die man nicht verwenden kann weil es keine Entsprechungen in der realen Welt gibt.
Obwohl ein Computer damit rechnen könnte, ist das völlig sinnlos.

Habe das mal grob durchgerechnet:
Eine 1 mit 200 Millionen Nullen îst seeeeehr viel mehr als die Anzahl der Atome in unserem Universum.
Das ist nämlich eine 1 mit 116 Nullen, also nur 117 Stellen.
Und großzügigerweise habe ich zur Sternmasse nochmal 10.000 multipliziert ;)

Vergiss es, du brauchst solche Zahlen nicht.

[obbschtkuche]

Für jede Zahl gibt es Verwendung. Vielleicht will er ja errechnen wie viele Möglichkeiten es gibt ein paar Tausend Sehenswürdigkeiten zu besuchen?

Zitat:

...weil es keine Entsprechungen in der realen Welt gibt.

Da fällt mir aber gleich noch mehr ein: Gewicht des Universums in... ähm... Yoctogramm oder die Zahl der Quarks im Universum... :hi:

[phXql]

Zitat:

...weil es keine Entsprechungen in der realen Welt gibt.

anzahl der möglichen querverbindungen von allen sternen zueinander :mrgreen:

[ripper8472]

Zitat:

Zitat von Tubos

...weil es keine Entsprechungen in der realen Welt gibt.

alle möglichen chemischen Verbindungen aller Atomarten und deren Isotopen bis zur Kernladungszahl 200, maximal so komplex wie es mit allen Atomen im All geht *g*
vielleicht kommen ja gute Medikamente oder neues Semtex raus...

[Tubos]

Zitat:

Da fällt mir aber gleich noch mehr ein: Gewicht des Universums in... ähm... Yoctogramm oder die Zahl der Quarks im Universum...

Anzahl der Quarks ist nicht viel mehr.
Ich habe keine Ahnung wie groß die Dinger sind, aber selbst wenn ein Atom aus einer Million Quarks besteht, ändert sich kaum was am Ergebnis ;)

[dizzy]

[ot]Ein Proton/Neutron besteht je aus 3 Quarks: 2 Up + 1 Down bzw. 2 Down + 1 Up -Quark. Elektronen sind im wesentlichen schon soetwas wie Quarks :zwinker:[/ot]

[Tabak]

Hi Leute,
erstmal sorry, dass ich nimmer geschrieben hab, aber mein Router..... :wall:
Is echt cool was ihr da über 200 Millionenstellenzahlen philosophiert!! Bin beeindruckt! Deshalb lüfte ich auch das Geheimnis (etwas sehr durchgeknallt):
Ich hab mir überlegt, dass wenn man einfach den Farbwert von jedem Pixel in eine lange Zahl schreibt, müsste man doch mit Exponent-Funktionen die Zahl auch hinbekommen. - Sone Art Komprimierung.
Zur Verdeutlichung: Mal angenommen wir nehmen alle 3 Farben mit(000-255) bei einer Auflösung von 1024 * 768. So müsste man immer 9 Ziffern für einen Pixel reserviren (Z.B 255255255000000000255255255 wäre dann ein weißer, ein schwarzer und ein weißer Pixel )bei der Auflöung von 1024*768 wären das also 9*1024*768 = 7077888.
Bei 30 Bildern ca 212336640 Ziffern - ein Zahl die unglaublich viel Speicher bräuchte... Eine Lösung wären Exponenten: 10 hoch 10
= 100000000000 (12 Ziffern), 10.000^10.000 = noch viel größer. Man speicher einfach die Exponentfunktion, wandelt es wieder in 200 Mio.Ziffern um und freut sich jedes mal über den Rechner Absturz :zwinker:
- Ich wollt eigentlich nur wissen ob das mal abgesehen von der Rechenleistung machbar wäre...

[gmarts]

...wäre schon toll, wenn deine Ziffernfolge ne glatte Zehnerpotenz wäre.
Das wäre bei deiner Methode wohl nur bei vollkommen schwarzen Bildern so, deren erster Pixel dunkelrot ist. :mrgreen:

Sonst ist die Schreibweise in Zehnerpotenzen alles andere als praktisch:

• 1234 = 1*10^3 + 2*10^2 + 3*10^1 + 4*10^0 = 12*10^2 + 34*10^0 = 1234*10^0

Wie du es auch machst....du sparst nichts ein.

[Tabak]

Ja hast recht, wenn man es mit 10 Potzenzen machen würde wäre wohl ziemlich viel schwarz dabei 8) .
War aber auch nur ein Beispiel. bei 3^17 = 129140163 müsste ein grau mit leichtem blaustich rauskommen. Wenn sichs um große Zahlen handelt kann man ja auch mit Komma Zahlen arbeiten und es lohnt sich trotzdem, oder einfach sagen er soll noch 12345 dazuadieren - falls es halt benötigt wird. Mehrfachexponenten wären auch möglich (3^7^13,654 - was immer da für eine Farbe rauskommen würde). Nur eine Frage der Funktionen...

[Stevie]

Zitat:

Zitat von LeoDD

Früher hat man sowas mit Strings nachgebildet. Vielleicht is das einfacher.

Bei 200 Millionen Stellen hätte eine Variable dieses Datentyps einen Speicherbedarf von ca. 190 MB !!!

[atreju2oo0]

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]

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]

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]

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]

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]

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]

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: