Par Sachen sind mir aufgefallen (habe ja selber so'ne Library programmiert
http://www.michael-puff.de/Developer...agen_Reddmann/
1.) TBigInt.Trim; sollte umbenannt werden in TBIgInt.Normalize;
2.) Ein TBigInt der 0 ist wird bei dir mit FDigit[0] := 0; initialisiert. Das führt dazu das Length(FDigit) = 1 ist. Du solltest die 0 intern mit FDigit = nil = Lenght(FDigit) = 0 definieren. Das vereinfacht alle nachfolgenden Operationen.
TBigInt.IsZero := FDigits = nil;
3.) Es ist clever FDigits in Schritten von zb. 16 TDigits zu erhöhen. Parallel dazu ein neues Feld FCount das die Anzahl der real benutzten TDIgits in FDigits speichert. So verhindert du die vielen Reallokationen des dynam. Arrays FDigits. Das bringt ne ganze Menge mehr Performance
4.) Deine Konvertierungsfunktionen eines TBigInt von/nach String zu einer beliebigen Basis sind ineffizient Das geht bei weitem schneller, bzw. dein Algorithmus ist ineffizient.
5.) Die ganzen Funktionen wie .IsGreater, .IsEqual usw. sind überflüssig. Das ist "Programmiererdenken" und nicht Denken eines Mathematikers. In meiner Lib gibts nur eine Funktion .NCmp(A, B): Integer; vergleiche A mit B und gebe -1 zurück wenn A < B, +1 wenn A > B und 0 wenn A = B.
6.) Zur Überprüfung einer Zahl auf Prime gibt es bessere Algos. als Rabin Miller. Zb. Test nach Selfridge-Wagstaff-Pomerance.
7.) Add() und Sub() sind die gleiche Operation nur mit inversen Vorzeichen, warum zwei getrennte Funktionen
8.) Warum subtrahisert du im 2'Complement, die vorherige Konvertierung macht deine Sub/Add unnötig langsam.
9.) die Funktionen für Add()/Sub()/Mul() etc. sollten in Assembler codiert werden. Besonders weil du als Basis 2^32 benutzt. Das hat primär nichts mit Peformance zu tuen, sondern als erstes mit der Fähigkeit in Assembler die speziellen Features der CPU besser benutzen zu können. Dh. in Assembler haben wir Möglichkeiten die Opcode für ADD/SUB/MUL/DIV chained zu benutzen. Deine jetzge Konvertierung und Rechnung mit Int64 macht deine Funktionen mindestens 3 mal so langsame wie sie sei könnten. Int64 ist in der Delphi
RTL absolut miserable implementiert, soll heisen ineffizient. Fast alle meiner eigenen Int64 Routinen sind 2-5 mal schneller als die von Borland.
10.) deine Division geht weit besser. Schau mal bei D.Knuth rein, Absatz "Arithmetics".
11.) die Barret Reduction ist im Vergleich zum Montgomery Trick ineffizienter
Gruß Hagen