Unbegrenzt viele Nachkommastellen

[c113plpbr]

Ich weis nicht ob diese Frage schonmal gestellt wurde, aber ich stelle sie einfach:
Weis jemand wie ich (nahezu) unbegrenzt viele nachkommastellen in einer zahlen-variable haben kann (für die berchechnung von ein 'paar' stellen von z.B. Pi oder der Wurzel aus 2, usw.)? Und kann ich damit auch 'normal' rechnen?

Ich danke im vorraus!

[BungeeBug]

Hi,

du kannst für ein paar Stellen ne Real (5.0*10^-324 bis 1.7*10^308) oder ne Extended ( 3.4^-4932 bis 1.1^4932) Variable nehmen ... Real hat 15-16 signifikante Stellen, Extended hat 19-20. Das sollte alle mal reichen. Unendlich viele geht nich, da irgendwann deine Speicher zuende ist.

[axelf98]

Hmm, es gibt nur noch die Möglichkeit, die Nachkommastellen mit einem Algorithmus auszurechnen. Das Matheprogramm Derive kann pi auf 10.000 Stellen ausgeben.. Durch Berechnung der Stellen, was auch schon seine Zeit dauert. Aber fragt mich jetzt nicht nach solchen Rechenfunktionen á la function Wurzel(Zahl,Stellen:Extended): Sonstwas;...

[BungeeBug]

Hmm man könnte eigendlich nen String benutzen ... ein String ist in Delphi auf eine max. Größe von 2GB beschränkt was bedeuten würde 2*1024*1024*1024*8 Bit. Was immerhin eine beachtliche Menge an Nachkommer stellen geben würde, und die Berechnung geschieht dann nach dem Verfahren nach Hearon (ich weis nich ob er sich so schriebt). Aufjedenfall kann man so recht gut und genau die Wurzel bestimmen. Ich kann (wenn sich gleich Zeit ergibt) versuchen mal ne Procedure dafür zuschreiben ... aber verprechen tu ich nix :)

[himitsu]

Ich schreibe ab und zu mal an meinem Taschenrechner, der schaft theoretisch bist zu 2 Milliarden Stellen (Vor- & Nachkommastellen zusammen) wird zwar mit sicherheit nicht der schnellste Rechner, dafür aber Binär, Oktal, Dezimal, Hexadezimal ...

http://www.delphipraxis.net/images/common/divider.jpg
http://www.FrankNStein.de/Smiley-Kuss.gif * * http://www.FrankNStein.de/Smiley-Spinne.gif * * * http://www.FrankNStein.de/Smiley-Winken.gif

[c113plpbr]

Also eigentlich geht es bei dem ganzen nur um eine wette: Ein Lehrer hat gewettet, dass die Millionste Nachkommastelle der wurzel aus 2, 7 ist ... und ich will ihm irgendwie das gegenteil mit hilfe eines eigenen Programms beweisen ... die chancen stehen 1 zu 9 ... wie ich die wurzel ausrechnen kann ist mir klar, aber eben nur auf etwa 14 nachkommastellen ... ich brauche aber die millionste, und da ich mit strings nicht rechnen kann, stehen die chancen nicht gut. Wenn keiner ein gutes Verfahren dafür kennt, dann muss ich mir wohl oder übel ein Grundschulrechenverfahren mit strings überlegen ...

[czapie]

Hi,
aber prinzipiell ist es auf keinem Computer möglich unendlich viele Nachkommastellen zu bestimmen,
da ja z.b. pi nicht irgendwann "zu ende" ist, und wie gesagt jeder Computer irgendwann an seine Grenze kommt.
Czapie.

[Thorben86]

Er braucht ja auch nit unendlich viele, sonden nur die Millionste :-)

[X-Dragon]

Zitat:

Zitat von Thorben86

Er braucht ja auch nit unendlich viele, sonden nur die Millionste :-)

Vielleicht findest du hier was passendes:
http://www.programmersheaven.com/zone2/cat265/index.htm

[axelf98]

Hmm.. ALternativer Weg:

www.derive.com -> Download -> Installieren, Starten -> Wurzel 2 eingeben -> Approximate -> 1.000.000 Digits -> Warten -> Warten -> Warten -> ... -> Fertig

[nailor]

Zitat:

Zitat von axelf98

Hmm.. ALternativer Weg:

www.derive.com -> Download -> Installieren, Starten -> Wurzel 2 eingeben -> Approximate -> 1.000.000 Digits -> Warten -> Warten -> Warten -> ... -> Fertig

zwischen dem vorletzen und letzten warten kannst du wahrscheinlich noch [ende der welt] einfügen. Derive ist zwar gut, aber ob es SO schnell ist, dass sich das lohnen würd, will ich bezweifeln. Außerdem wirds leicht sch*** mit 1 Mio Ziffern und dem Speichern in einer Derive-Internen Methode. Die werden da auch irgendwo ein Limit haben (und imho unter 1 Mio).

Alternativ würde ich mal googlen!

Zum Rechnen mit unendlich vielen Zahlen: Ein Computer kann prinzipiell mit beliebig vielen Stellen rechnen!

[eddy]

Hallo c113plpbr,

wir hatten mal einen Intelligenztest. Der Lehrer sagte: Wer die erste Frage richtig beantwortet, brauch die zweite nicht mehr beantworten. Ich wurde gefragt: Wieviele Haare hat ein Esel?
Ich antwortete ohne zu zögern: 24 Billionen 635 Milliarden 197 Millionen 915 Tausend und 41.
Der Lehrer frage mich, woher ich das so genau wüßte. Ich antwortete ihm, daß dies die zweite Frage ist, und die brauche ich nicht zu beantworten.

Warte noch ein paar Jahre, dann haben die Standard-PC die nötige Rechenleistung (Speicherkapazität und Geschwindigkeit), um die Aufgabe in vernünftigen Zeiträumen zu lösen. Solltest Du doch ein Programm schreiben, daß die nötigen Zahlen ermittelt, kannst Du es ja schon mal starten und dann von einer PC-Generation auf die nächste übernehmen.

Und Deinem Lehrer kannst Du immer sagen: Mein PC rechnet noch .... :cheers:

mfg
eddy

[negaH]

Ich weis ja nicht wie dein Lehrer auf die 7 gekommen ist, mein Programm sagt es wäre eine 3. Hier mal die letzten 20 Nachkommastellen von Sqrt(2), wenn man 1 Million Nachkommastellen berechnet -> ..... 20441 93016 90484 12043.
Übrigens, mit der richtigen Software dauert die Berechnung ca. 2,5 Sekunden.
Anbei mal alle 1 Mio +1 Dezimalstellen.

Gruß Hagen

[negaH]

Allerdings :) hat dein Lehrer absolut recht ! Denn genaugenommen ist die 1 Millionste Nachkommastalle von Sqrt(2) eine 0, eh nein eine 1, oder 2 oder doch 15.
Die Frage ist: hat dein Lehrer gesagt das er die 1 Millionste DEZIMALE Nachkommastalle meinte, oder meinte er es im Oktalen Zahlensystem, oder zur Basis 15, oder 9 oder 7 ???
D.h. es wird sich immer ein Zahlensystem finden in dem die 1 Millionste Nachkommastelle eine 7 ist. Das Zahlensystem muß nur zwangsläufig > 7 sein.

Du kannst ihm aber antworten, das er sich um 1 Stelle girrt hat, denn die 999.999 Oktale Nachkommastelle ist eine 7 -> ....51550614 2720677 0.
Die 1 Millionste oktale Nachkommastelle ist also eine Null.

Gruß Hagen

[negaH]

Zitat:

hilfe eines eigenen Programms beweisen ... die chancen stehen 1 zu 9

Die Chancen stehen also (unendlich -7) zu 1 das du beweisen kannst das jede Ziffer zwischen 0 und (unendlich -1) an der Millionsten Nachkommastelle stehen kann. Man muß nur das richtige Zahlensystem finden.

Gruß Hagen

[Phoenix]

Hagen: ...bin Sprachlos... Bist Du Mathematik-professor oder sowas?

[Tyrael Y.]

Die Library ist in C, aber vielleicht nutzt sie dir ja trotzdem was.

http://www.onlinecomputersciencedegr...c-library-gmp/


Diese Library kann große Zahlen berechnen.
Vor- und Nachkommastellen können theoretisch unendlich groß sein.


Gruß

[negaH]

@Phoenix, nein eher Hobbymathematiker, und dies nur auf dem engen Feld der Zahlentheorie. Die Berechnung von Sqrt(2) und ebenso Pi,e usw. ist sehr hilfreich wenn man seine eigene Library programieren will. Da diese "Konstanten" sehr weit erforscht sind kann man sie als Referenzen und Vergleichszwecken zum Austesten seiner eigene Library benutzen. Mit hilfe von der Berechnung von Pi habe ich zB. in meiner Library einen sehr sehr selten auftretenden Bitfehler gefunden. Im Falle von Pi trat dieser Fehler erst bei der Berechnung von über 100000 Stellen von Pi auf. D.h. die Wahrscheinlichkeit dieses kleinen Bitfehlers betrug ca. 1/10^100000. Dies ist enorm klein, denoch hat er dazu geführt das ALLE Berechnungen von Pi mit mehr als 100000 Stellen falsch waren. Man sieht also wie wichtig es ist auch solche "Konstanten" Berechnungen zu programmieren, auch wenn die Library ansich eher für kryptographische Zwecke gedacht ist.

Das eigentlich interessante ist eben eine solche Bibliothek wie GMP o.ä. zu programmieren, aus meiner Sicht :=)

GMP ist eine Blibliothek die sich ganz stark nur auf die Low-Low-Level Funktionen beschränkt. Diese sind dann aber in Assembler optimiert. Allerdings ist das in den meisten Fällen weniger hilfreich da eben die Low-Level + High-Level API's fehlen. D.h. man muß sich noch um alles selber kümmern, wie zB. Speicher anfordern und freigeben. GMP ist in C/C++.

Gruß Hagen

[eddy]

Hallo negaH,

!!! Wahnsinn !!!

Da kann man mal sehen, wie sehr man sich irren kann, wenn man zu Dingen seinen Senf abgibt, von denen man keine Ahnung hat (dafür aber einen festen Glauben, etwas zu wissen).

mfg
eddy

[Tyrael Y.]

Ich finde GMP super.

Kennt einer was besseres?
Oder eine Library, die schon in Delphi übersetzt wurde?

Gruß

[OregonGhost]

Ich habe ganz gute Erfahrungen mit apfloat gemacht (http://www.apfloat.org).
Ich glaube, irgendwann gab es da auch mal einen Link zu einer Pascal-Variante, aber den finde ich nicht mehr...
Unter hfloat sind auch noch ein paar andere entsprechende Bibliotheken zu finden.

GMP hatte ich mal ausprobiert, bin damit aber nicht auf Anhieb klargekommen ;c)

CLN scheint auch ganz gut zu sein, beispielsweise wurde die Bibliothek für GiNaC (... is Not a CAS) ausgewählt.

[negaH]

apfloat und CLN sind um Längen besser zu benutzen als GMP. Aber all diesen Libraries ist eines gemeinsam, es sind Bibliotheken die sehr stark an das Denkkonzept von C/C++ anlehenen und darauf aufbauen. Aus meiner Sicht also unmodern und kompleziert.

Zitat:

Kennt einer was besseres?
Oder eine Library, die schon in Delphi übersetzt wurde?

Ja ich. Da ich selber eine solche Library von Grund auf entwickelt habe, in Delphi, finde ich naürlich meine Library wesentlich besser :)
Ich kann aber auch Fakten sprechen lassen.
- automatische Referenze Counting der Zahlenobjecte
- automatische Garbarge Colllection
- Typsicherheit
- Copy on Write Demand, also so wie es bei LongStrings der Fall ist
- völlig transparent für den benutzer, nicht wie bei GMP wo man sich um jeden Kleinktram selber kümmern muß
- super schnell, in weiten Teilen schneller als GMP, apfloat, CLN usw. Meine Implementation zur Berechnung von Pi ist auf Rang 3 der Weltliste.
- das GUI bleibt über interne Idle-Cacllbacks bedienbar und jede langandauerende Berechnung kann ohne Problem abgebrochen werden
- Speichermanagement ist vollständig Threadsafe und jeder Thread benutzt interen seine eigene Speicherverwaltung, dies bedeutet das mehrere Threads absolut voneineander abgespaltet sind bis runter zur Speicherverwaltung (also kein Blocking und Konsorten nötig)
- die Gesamtperformance aller Operationen ist über einen weiten Zahlenbereich optimiert. D.h. egal ob man mit Zahlen ca. 4096 Bit groß in der Kryptographie üblich arbeitet oder ob man Pi auf Millionen Stellen berechnen will, die Berechnung sind alle hoch optimiert weil die besten bekannten Verfahren benutzt wurden.


Und hier mal der komplette Pi Berechnungs-Source, einmal die Methode der Chudnovski Brüder und einmal nach dem Arithmetischen Mittel.

Delphi-Quellcode:

procedure NPi_Fast_Chudnovsky(var R: IInteger; Decimals: Cardinal);
// Chudnovsky's brothers Ramanujan with binary splitting
// this code is most only 2-3 Times slower as the fastests special PI-programs
// Some optimizations can be done, but here i wanted a readable code.
// One way to made it faster (~2 times) could be to avoid NBinarySplitting() and its
// callback.
{
1      12   inf  (-1)^n (6n)! (A+nB)
-- = ------ SUM: -------------------
pi   C^1.5  n=0  (3n)! (n!)^3 C^(3n)


A=13591409 B=545140134 C=640320

a(n) = (A+nB)
p(n) = -1(6n-5)(6n-4)(6n-3)(6n-2)(n6-1)(6n)
b(n) = 1
q(n) = (3n-2)(3n-1)(3n)(n^3)(C^3)
}
const
  k_A = 163096908;          // 12 *  13591409
  k_B = 6541681608;         // 12 * 545140134
  k_C = 53360;              // 640320 / 12
  k_D = 1728;               // 12^3 = 24 * 72
  k_E = 262537412640768000; // 1727 * k_C^3

  procedure DoPI(N: Integer; var D: TIIntegerSplitData); register;
  // the callback for binary splitting
  // max. n < ~306783379 then 6n << MaxInt
  // B[1] = 1, P[0] = 1, Q[0] = 1
  // don't touch B,P[0],Q[0] because NIL interfaces are here assumed to value +1
  begin
    if N > 0 then
    begin
      NSet(D.A, k_B);                  // a = k_A + n * k_B
      NMul(D.A, N);
      NAdd(D.A, k_A);

      NSet(D.P,   2 * N -1 );
      NMul(D.P,   6 * N -1 );
      NMul(D.P, -(6 * N -5));          // p = - (6*n -5) * (6*n -1)* (2*n -1)

      NSet(D.Q, k_C);                  // q = 72(n * k_C)^3      // 72 * n^3 * k_C^3
      NMul(D.Q, N);
      NPow(D.Q, 3);
      NMul(D.Q, 72);
    end else
      NSet(D.A, k_A); // A[0] = k_A
  end;

var
  P,Q: IInteger;
  S: Cardinal;
begin
  S := NBinarySplitting(P, Q, Trunc(Decimals / 14.181) +2, @DoPI, False);  // decimal approximation is very roughly !!

  NPow(R, 100, Decimals);
  NMul(R, NInt(k_E));
  NSqrt(R);           // R = (k_C^3 * 12^3 * 100^Decimals)^(1/2) * Q / P

  NMul(R, Q);
  NShl(R, S);
  NDiv(R, P);         // R = R * Q / P = R / S

end;

procedure NPi_AGM(var R: IInteger; Decimals: Cardinal);
{ computation of Pi with Arithmetic-Geometric Mean 

 AGM start with:
   a = 1, b = 1/Sqrt(2), t = 1/2, k = 1

 iteration:

   s = (a + b) / 2
   d = a - s
   d = d^2
   a = s
   s = s^2
   t = t - d * 2^k
   b = Sqrt(s - d)
   k = k +1

 final:
   pi ~ (a + b)^2 / 2t }

var
  A,B,D,T: IInteger;
  W: Integer;
begin
  Inc(Decimals, 3);           // +3 digits reserve
  NPow(R, 5, Decimals);       // R =  5^Decimals
  NShl(A, R, Decimals);       // A = 10^Decimals
  NShl(D, R, Decimals -1);    // D = 10^(Decimals -1)^2
  NSqr(D);
  NSqr(B, A);                 // B = (10^Decimals^2 * 2)^0.5 div 2
  NShl(B, 1);
  NSqrt(B);
  NShr(B, 1);
  W := 0;
  repeat
    NAdd(T, A, B);            // T = (A + B) div 2, new A
    NShr(T, 1);
    NMul(B, A);               // B = (B * A)^0.5
    NSqrt(B);
    NSub(A, T);               // A = (A - T)^2 * 2^W
    NSqr(A);
    NShl(A, W);
    Inc(W);
    NSub(D, A);               // D = D - A
    NSwp(A, T);
  until NCmp(B, A) = 0;
  NShr(D, Decimals);
  NDiv(D, R);
  NMul(D, 1000);
  NSqr(R, A);
  NDiv(R, D);
end;

IInteger ist der große Ganzzahl Typ, keine Allozierungen oder Deallozierungen sind nötig. Man arbeitet also mit IInteger'n so als wären es normale Integer Datentypen, obwohl sie enorm große Speicherbereiche dynamisch verwalten.
Ein Manko gibt es allerdings, bisher habe ich nicht die Zeit gefunden auch Fließkommazahlen zu implementieren. Es gibt also Vorzeichenbehaftete Ganzzahlen -> IInteger, Gebrochene Zahlen -> IRational, Modulare Polynome -> IPoly und alle nötigen Berchnungen in Elliptischen Kurven.

Gruß Hagen

[Dagon]

@ Hagen: Ich bin fast ein bisschen neidisch! So eine slebst geschriebene Bibliothek hätte ich auch gerne *träum*!

[Tyrael Y.]

@Hagen

hört sich super an.
Ist das ganze in einer Library gepackt oder kann man auch den Source haben?
Wo kann ich mir deinen Source bzw. deine Library runterladen?

Möchte es gerne mal testen.

Wenn noch die Fließkommaimplementierung dazu kommt und alles so ist wie du erklärt hast bin ich gespannt auf das Resultat.

Gruß

[negaH]

@the_master: mir ging es bei der Library nicht um besitzen, sondern um den Spaß die komlizierten math. Verfahren zu implementieren.

@Tyrael Y.: tja das ist so'ne Sache. Eigentlich liegt die Library bei mir auf'm rechner rum, ohne das sie weiterverwendet wird, heul. Momentan finde ich nicht die Zeit sie weiter zu entwickeln, geschweige denn überhaupt was daran zu machen. Andererseits habe ich über 3 Jahre daran gebastelt, und ganz nebenbei ca. 5 Gigabyte an mathematischen Dokumenten, Dissertationen, Sourcen usw. gesammelt. Im gesammten sind ca. 150.000 Zeilen Source in der Bibliothek davon ca. 75% in Assembler.
Nun, dies erklärt vielleicht warum ich so dran hänge und eigentlich noch nicht bereit bin sie frei in Netz zu stellen, könnt ja sein das ich als Freelancer noch Brötchen damit verdienen kann.

Ich habe aber in letzter Zeit einigen Leuten eine Version zur Verfügung gestellt. Sie ist für Delphi 5-7 verfügbar, und enthält alle DCU + Packages und ausgewählte Sourcen. So zB. die vollen Sourcen zur Berechnung von transzendente Konstanten wie Pi,Sqrt(2),ArcSin,e. Desweiteren meine Sourcen zur Berechnung der Fakultät einer Zahl, sprich N!, denn es gibt dafür ca. 7 verschiedene Algorithmen.

Leider ist das bisherige Feedback doch ziemlich gering, d.h. für mich persönlich ist dabei nicht viel rüber gekommen (sprich Bugs, Handling, verbesserungen usw.).

Gruß Hagen

[Tyrael Y.]

@Hagen
danke dir.

Ich werde es mal am Wochenende bissel testen, in der Woche bin ich
mit Projekten von der Arbeit beschäftigt.

Falls mir etwas auffallen sollte, melde ich mich auf jeden Fall.
(auch für positive Kritik ;) )


Gruß

[negaH]

Selbst über negative Kritik würde ich mich freuen :)
Ach übrigens, obiges Packages ist für D5, ich liebe D5. Ich habe aber auch noch D6 und D7 Versionen.

Am besten du fängst mit dem Testproject im Ordner ..\Test\ an. (entpacken MIT Ornder !).
Das Wesentliche findest du in TestUnit.pas inkulsive Remarks.
Die Units NCombi.pas und NInt_1.pas liegen als vollständiger Source vor. Im Ordner ..\libint\ findest du die Header aller Units.

Gruß Hagen

[Unwissender]

Also, dass eine Million stellen mit einem Programm in 2,5 sek. berechnet werden ist lustig. Leider ist das Ergebnis dann aber falsch. Liegt allerdings an der Hardware. Ich gehe zumindest mal davon aus, dass du eine normale CPU (x86 oder irgendein Motorola oder Alpha) benutzt hast.
Und da diese CPU's mit Mantissen rechnen, entsteht der so beliebte Rundungsfehler der bei 1 mio. Stellen schon relevant ist. Um ein wirklich mathematisch korrektes Ergebnis zu bekommen, musst du diesen Fehler berücksichtigen und kannst einfach nicht mit der GPU deiner CPU arbeiten. Und alles andere schafft es nicht, in 2,5 sek. eine Gleitkommazahl zu berechnen, die > 1 mio signifikante Stellen hat.

[negaH]

Zitat:

Leider ist das Ergebnis dann aber falsch. Liegt allerdings an der Hardware.

Ich weiß ja nicht wovon du redest, aber ich kann dir garantieren, auch unabhänig von der hardware, das das letzenliche Resultat bis auf's letzte Bit absolut exakt sein muss. Zumindestens bei meinen obigen Berechnungen.

Das liegt eben daran das per Software die Fähigkeiten der CPU exakte Berechnungen durchzuführen, stark erweitert wurde. Statt nun nur auf 32Bit/48Bit exakt zu rechnen, rechnet die CPU nun auf Millionen Bits absolut exakt. Im grunde werden alle Berechnungen der CPU die Millionen Bits benötigen auf viele kleine Berechnungen von 32 Bit größe per Software runtergebrochen. D.h. sollen zB. zwei Zahlen a 64 Bit Multipliziert werden, was ja eine 32 Bit CPU nicht von Hause aus kann, wird die zusätzliche Sofware die CPU insgesamt 3 mal eine 32 Bit Multiplikation ausführen lassen. Am Schluß werden diese 3 kleinen Multiplikationen wieder zusammen geführt und flux ensteht ein 128 Bit Resultat das absolut exakt das Produkt der beiden 64 Bit Zahlen ist.

Angenommen eine CPU kann nur Zahlen bis 100 exakt berechnen. Wir wollen aber 123 * 456 ausrechnen. So wie DU es logischerweise machst geht nun auch di Software vor. Sie zerlegt 123 in 1*100 + 2*10 + 3, und 456 in 4*100 + 5*10 + 6. Nun lässt die Software die CPU die Teilprodukte ausrechnen, also 1*4, 1*5, 1*6, 2*4, 2*5, 2*6, 3*4,3*5,3*6 und baut alle diese Produkte im Speicher unter berücksichtigung derer Potenzen zu basis 10 wieder zusammen. So kann man auf jeder beliebigen Hardware auch deren Grenzen exakte Berechnungen durchzuführen, auf's fast unendliche erweitern (abgesehen vom nötigen Speicher und Zeitaufwand).

Zitat:

Also, dass eine Million stellen mit einem Programm in 2,5 sek. berechnet werden ist lustig.

Nein, nicht lustig, sondern Schweißtreibende Denkarbeit !

Gruß Hagen

[c113plpbr]

Erstmal Danke für die vielen Antworten (ob hilfreich oder nicht ;-))
Um alles nochmals richtig zu stellen:
Er wettete (d.h. er wusste/weis es nicht), das die Millionste (Dezimale) Nachkommastelle (also ohne die Stellen vor dem komma ;-)) 7 wäre/ist.
Und ich (bzw. wir Schüler) wetteten dagegen ... und er meinte, dass es an uns liegt dies zu beweisen, was heißt, dass ich ein Programm brauche das (möglichst) vor ihm die richtige (soweit nachvollziehbar) Wurzel ausrechnet, was wiederum heißt, dass ich einen code brauche (er soll es ja nachvollziehen können), den ich ihm zeigen kann ...
Trotzdem danke ich allen für die Mühe, denn ich möchte ja keine Ansprüche stellen ...

[nailor]

Zitat:

Zitat von negaH

D.h. es wird sich immer ein Zahlensystem finden in dem die 1 Millionste Nachkommastelle eine 7 ist. Das Zahlensystem muß nur zwangsläufig > 7 sein.

was zu beweisen wäre ;)

[negaH]

der math. Beweis dürfte garnicht mal so schwierig sein, man müsste sich nur richtig reinknien.
Von der Wahrscheinlichkeitsabschätzung her ist meine Aussage aber sehr wahrscheinlich. Es gibt (unendlich -7) mögliche Zahlensysteme, und wir benötigen nur EINES das für unsere Zahl eine 7 als Ziffer liefert.

Gruß Hagen

[nailor]

Zitat:

Zitat von negaH

der math. Beweis dürfte garnicht mal so schwierig sein

Zitat:

Zitat von negaH

man müsste sich nur richtig reinknien.

häh? Wie jetzt?

[Luckie]

Er meint, es ist beweisbar und gar nicht mal so schwer, nur wohl etwas aufwendig.

[c113plpbr]

Zwei Fragen an negaH:
- Könntest du noch eine Delphi 7 Version deiner Library anhängen? Wäre sehr nett ...
- Kann es sein dass deine Library (wegen des DEC im namen der datei) irgendwas mit dem Delphi Encryption Compedium zu tun hat?

danke im vorraus ...

[nailor]

wenn man bedenkt, dass das DEC von ihm ist, ist das garnicht mal so unwahrscheinlich!

[negaH]

Ja, es sollte sogar nur ein Part des DEC's werden. Was nützt DEC part I so wie es im WEB zu finden ist, wenn es nicht auch erweitert wird, um Public key Kryptographie. Part I enthält also nur die symmetrischen Algorithmen. Part II sollte alles enthalten was für die asymmetrische Kryptographie notwendig ist. Also Large Integer + PK Algos. Part III wiederum sollte nun alles kombinieren und darauf aufsetzend die fehlenden Protokolle implementieren. Also OpenPGP, PKCS#, PEM, SRP uvm.
Aber wie es nunmal so ist, im Leben fehlt einem oft die Zeit und vielleicht auch der Überblick und die Muse alles wie geplant fertigzustellen. Davon abgesehen würde ich als Alleinkämpfer nie wieder so ein Projekt anfassen wollen, es ist also nur Hobby geblieben.

Anbei D7 Version, ich perönlich rate aber von D7 ab. Nicht weil es nicht funktioniert, sondern weil der Compiler ca. 10% langsammeren Code erzeugt, dafür aber die EXE's ca. 20% aufbläht und die IDE zäher und instabiler als D5 ist. Dagegengesetzt bietet D7 eigendlich keine neuen und besseren Features als D5.

Gruß Hagen

[Dax]

Hi negaH!

Ich bin von der Lib total begeistert...
Allerdings laüft sie bei mir nicht(vcl50->vcl60 inkompatibel)..
Die Pi-Berechnung hab ich auch mal it ner BigInt-Lib gebaut, und für 1000 Stellen hat es 10 Minuten gebraucht(1,8 GHz P4).

Würdest du bitte die D6-Version noch anhängen oder die Web-Adressen verraten?
Würde mich freuen...

[negaH]

Ok, dann will ich die DP mal zumüllen :) Hier noch die D6 Version, wie gesagt ich bervorzuge immer noch D5.

Zitat:

und für 1000 Stellen hat es 10 Minuten gebraucht(1,8 GHz P4).

Dies unterscheidet eben die verschiedenen Bibliotheken. Die darin enthaltenen Algorithmen und deren korrekte und denoch effiziente Umsetzung machen die Qualität der Library aus. Auch in meiner Lib hatte ich eigentlich vor nur für den Zahlenbereich bis ca. 2^4096 effizient zu unterstützen. Allerdings hat es mich dann mitgerissen, und ich musste unbedingt auch eine super-schnelle Multiplikation/Division/Wurzel Berechnung per Fast Fourier Transformation haben. Asymptotisch sind die Algorithmen in meiner Lib die schnellsten die es theoretisch gibt, d.h. mathematisch gesehen kann man nicht schneller Multiplizieren oder Dividieren als mit meiner Lib. Jede Verbesserung kann nur noch eine Optimierung per besserem Assembler sein. Alleine die Multiplikation zweier Zahlen sind ungefähr 60% der Sourcen, ca. 100.000 Zeilen. Aber! wer braucht das schon ?

Gruß Hagen

[negaH]

Zitat:

und für 1000 Stellen hat es 10 Minuten gebraucht(1,8 GHz P4).

Auf meinem P4 1,5 GHz benötige ich für 1000 Dezimalstellen 0,4 ms :)

Gruß Hagen