Delphi-PRAXiS
Seite 5 von 5   « Erste     345   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi 2 Integerwerte in einem Integerwert reversibel speichern? (https://www.delphipraxis.net/97453-2-integerwerte-einem-integerwert-reversibel-speichern.html)

Apollonius 12. Aug 2007 12:50

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Aber auch mit echter Teilmenge gilt Phoenix' Aussage nicht, siehe letzten Post von mir.

Polynom 12. Aug 2007 13:28

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Hallo,

Wenn ich mich nicht täusche, dann liegt die Obergrenze des Integer-Zahlenraumes in Delphi bei 2147483647.
Die Quadratwurzel daraus ist etwa 46340. Das bedeutet, dass wenn keine der beiden Primzahlen 46340 überschreitet alles im grünen Bereich ist. Die 46337 ist die 4792. Primzahl (Wenn ich mich nicht verrechnet/verzählt habe).
Wenn eine der Zahlen besonders klein ist, dann kann die zweite Zahl dafür umso größer sein. Wenn die erste Zahl z.B. 1 wäre, dann dürfte die zweite resultierende Primzahl bis zu 1073741821 groß werden - Ich hab nur leider keine so große Liste und kann daher nicht herausfinden welcher "normalen" Zahl dies entsprechen würde.

Bei Hagens Methode liegt die Grenze (wenn ich das System verstanden habe und beide Zahlen etwa gleich groß sind) bei ca. 46339. (korrigiert mich, falls ich falsch liege).

Zitat:

Falls zb. |A| und |B| kleiner 128 wären dann multiplizierst du A mit 128 und addierst B drauf.
An diesem Punkt bin ich etwas verwirrt: Angenommen eine der beiden Zahlen sei enorm klein. Wenn ich die Aussage von Hagen genau so auffasse, wie sie dasteht, dann würde das bedeuten, dass die andere Zahl nur geringfügig größer werden kann. Dies würde dann bei weit auseinander liegenden Zahlen fast schon für die Primzahl-Methode sprechen.
Aber ich nehme an, dass (in dem von Hagen genannten Beispiel) nur |B| kleiner 128 sein muss.

Zum Zeitaufwand bei der Primzahl-Methode: Ich gebe zu, dass der Zeitaufwand für eine Primfaktorzerlegung recht hoch ist, aber ich weiß leider nicht für welches Anwendungsgebiet dies verwendet werden soll. Programme zur Zerlegung in Primfaktoren brauchen bei mir etwa 350 ms für Zahlen im Bereich von 46337*46337. Falls dies auf mehreren Zahlen angewendet wird, so sehe ich es ein, dass der Zeitaufwand nicht akzeptabel wäre.

Mit freundlichen Grüßen, Michael

Phoenix 12. Aug 2007 14:02

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Zitat:

Zitat von Apollonius
Aber auch mit echter Teilmenge gilt Phoenix' Aussage nicht, siehe letzten Post von mir.

Ja ja ist ja gut ... die Identität ist ein Sonderfall der echten Teilmenge...

Jedes Quadrat ist ein Viereck aber nicht jedes Viereck ist ein Quadrat. Jede Identität ist eine Teilmenge aber nicht jede Teilmenge eine Identität. Ich wollte nur auf den Sonderfall hinweisen den wir hier haben, nicht die Teilmenge in Abrede stellen :zwinker:

Apollonius 12. Aug 2007 14:29

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Zitat:

Ja ja ist ja gut ... die Identität ist ein Sonderfall der echten Teilmenge...
Nein! Die Identität ist ein Sonderfall der "unechten" Teilmenge!

3_of_8 12. Aug 2007 15:51

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Zitat:

Zitat von Polynom
Wenn ich mich nicht täusche, dann liegt die Obergrenze des Integer-Zahlenraumes in Delphi bei 2147483647.

Richtig. Da es aber keine negativen Primzahlen gibt, wäre ein Cardinal hier effizienter.

Zitat:

Zitat von Polynom
Wenn eine der Zahlen besonders klein ist, dann kann die zweite Zahl dafür umso größer sein. Wenn die erste Zahl z.B. 1 wäre, dann dürfte die zweite resultierende Primzahl bis zu 1073741821 groß werden - Ich hab nur leider keine so große Liste und kann daher nicht herausfinden welcher "normalen" Zahl dies entsprechen würde.

1 ist keine Primzahl. Ich hab mal eine Liste der ersten paar hunderttausend Primzahlen, ich könnte mal nachschauen...

Zitat:

Zitat von Polynom
Bei Hagens Methode liegt die Grenze (wenn ich das System verstanden habe und beide Zahlen etwa gleich groß sind) bei ca. 46339. (korrigiert mich, falls ich falsch liege).

Hagens Methode ist allgemein formuliert. Wenn man es im speziellen Fall für einen 32-Bit-Cardinal betrachtet, hat liegt die Grenze bei 2^16=65536.

Zitat:

Zitat von Polynom
An diesem Punkt bin ich etwas verwirrt: Angenommen eine der beiden Zahlen sei enorm klein. Wenn ich die Aussage von Hagen genau so auffasse, wie sie dasteht, dann würde das bedeuten, dass die andere Zahl nur geringfügig größer werden kann. Dies würde dann bei weit auseinander liegenden Zahlen fast schon für die Primzahl-Methode sprechen.

Wie gesagt - Hagens Methode war allgemein. Bei sehr weit auseinanderliegenden Zahlen kann eine Zahl bei der Primzahlmethode tatsächlich größer sein. Dafür ist die Primzahlmethode äußerst ineffizient.

Zitat:

Zitat von Polynom
Zum Zeitaufwand bei der Primzahl-Methode: Ich gebe zu, dass der Zeitaufwand für eine Primfaktorzerlegung recht hoch ist, aber ich weiß leider nicht für welches Anwendungsgebiet dies verwendet werden soll. Programme zur Zerlegung in Primfaktoren brauchen bei mir etwa 350 ms für Zahlen im Bereich von 46337*46337. Falls dies auf mehreren Zahlen angewendet wird, so sehe ich es ein, dass der Zeitaufwand nicht akzeptabel wäre.

Die Angabe einer Zeit ist bei Algorithmen nicht aussagekräftig, da sie vom Compiler, dem Betriebssystem, den laufenden Prozessen/Threads und dem Rechner abhängt. Wie bereits gesagt, ein Primzahltest der Zahl n geht in der Zeit O(sqrt(n)), was für kleinere Zahlen keine wirklich schlechte Laufzeit ist, aber Hagens Methode geht in konstanter Zeit und ist damit selbstverständlich zu bevorzugen.

negaH 12. Aug 2007 20:59

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Also "meine" Methode ist die normale Methode mit der man ein Zahlensystem konstruiert.

Wenn also alle unsere zu kodierende Zahlen kleine X sind so wird X zu unserer Basis. Wenn wir nun 4 Zahlen damit kodieren wollen und diese Zahlen nur im Bereich vopn 0 bis 9 liegen dann gilt

Resulat := 10^3 * D + 10^2 * C + 10^1 * B + 10^0 * A

10 ist unsere Basis da alle unsere Zahlen immer nur zwischen 0 bis 9 liegen.

Nun gesetzt der Fall das

A = 1
B = 2
C = 3
D = 4

dann ist Resulat = 4321 als Dezimalzahl.

Das ist ganz simple Methematik der Zahlensysteme. Ob die Basis nun 2, binär, oder 8 oktal, oder 10 deuimal oder 16 hexadezimal, oder eben 128 oder 256 (Byte) ist ist doch brust. Die logik dahinter sollte eigentlich klar sein.

Zur anderen Diskussion. Leider habe ich immer wieder die Probleme mit der Unendlichkeit, denke mir das ich nicht alleine damit bin ;)
Ich verstehe Assarbads Einwurf jetzt. Wenn ich's richtig kapiert habe dann heist dies das eine Menge A mit unendlich vielen Elementen denoch unendlich mal mehr Elemente haben kann als eine Menge B die ebenfalls unendlich groß ist. Beide Mengen sind unendlich groß und denoch gibt es eine Differenz zwischen beiden die unendlich groß ist. Ist das richtig so ? Denn dann würde es tatsächlich so sein das es eine Menge A aller natürlichen Zahlen gibt die so viele Primzahlen enthält das denoch alle Nicht-Primzahlen damit kodiert werden obwohl deren statistische Verteilung großer ist als es Primzahlen gibt.

Gruß Hagen

3_of_8 12. Aug 2007 22:26

Re: 2 Integerwerte in einem Integerwert reversibel speichern
 
Wie gesagt: Zwei Mengen sind gleichmächtig, wenn es eine Bijektion zwischen ihnen gibt. Dass es eine gibt, habe ich gezeigt.

Und ja, so könnte man es formulieren.

Die Mengen Z und N sind beispielsweise gleichmächtig, obwohl Z (salopp gesagt) "unendlich mal mehr Elemente hat als N". (nämlich die negativen Zahlen, die ja auch unendlich sind. Auch Q ist gleichmächtig zu Z und N (siehe Cantorsches Diagonalverfahren). Mit R sieht es dann wieder anders aus, da R ja überabzählbar ist. C ist dann wieder gleichmächtig mit R.

(Man sagt, |N|=|Z|=|Q|=aleph0 und |R|=|C|=c, das nur so nebenbei)


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:30 Uhr.
Seite 5 von 5   « Erste     345   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz