Unbegrenzt viele Nachkommastellen

[Dax]

Wo wir doch am Anfang bei Wurzeln waren...
Ich hab hier was:

Delphi-Quellcode:

procedure NSqrt(R: IInteger; Decimals: int64; var Root: IInteger); overload;
var r1: IInteger; i: int64; s: string;
begin
  NSet(r1, 10);
  if Decimals <= maxint then
  begin
    NPow(r1, decimals);
    NMul(r1, r1);
  end
  else
  begin
    i := 0;
    repeat;
      NPow(r1, maxint);
      dec(Decimals, maxint);
      inc(i);
    until i = decimals div maxint;
    if decimals = 1 then
      NMul(r1, 10)
    else
      NPow(r1, decimals);
  end;
  NMul(r1, R);
  NSqrt(Root, r1);
end;

[negaH]

Super, allerings gäbe es einige Verbesserungen:

1.) Decimals als Int64 ist utopisch groß, schon bei Decimals: Cardinal dürftest du die Speichergrenzen fast aller Rechner sprengen
2.) Alle Interfaces -> IInteger sollten entweder als const oder var übergeben werden, in deinem Falle ist R: IInteger wenig sinnvoll.
3.) Man kann NMul(R1, R1) benutzen, sauberer wäre aber NSqr(R1). Zum Glück überprüft NMul(R1, R1) ob beide Parameter identisch ist und nutzt intern sowieso NSqr(R1), es gibt also keinen Unterschied. Wäre dies NICHT so dann würde NSqr(R1) ca. 1.5 mal schneller sein als NMul(R1, R1).
4.) die Parameterreihenfolge sollte angepasst werden ans DEC, d.h. zuerst Ausgabeparameter dann readonly Eingabeparameter


Es sähe dann so aus:

Delphi-Quellcode:

procedure NRoot(var R: IInteger; const A: IInteger; Root,Digits: Integer; Base: TBase = 10); overload;
// R = A^(1/Root) * Base^Digits
resourcestring
  sNRoot1 = 'NRoot(), invalid paramater Root, must be >= 2';
  sNRoot2 = 'NRoot(), invalid paramater Digits, must be >= 0';
var
  T: IInteger;
begin
  if Root < 2 then NRaise(@sNRoot1);
  if Digits < 0 then NRaise(@sNRoot2);
  NPow(T, Base, Digits);
  NPow(T, Root);
  NMul(T, A);           // A ist verbaut worden, nun können wir sicher R überschreiben
  NRoot(R, T, Root);    // somit müssen R und A nicht distinct sein, ein Aufruf wie
end;                    // NRoot(R, R, 2, 1000) wäre legal. (Bullet proof)

Man muß sich nun vorstellen was es bedeutet wenn Digits/Decimals > MaxInt wäre.
Im besten Falle würde man 2^0.5 * 2^2^2^31 rechnen ! Alleine schon 2^2^31 = 2^MaxInt benötigte also 2 Gigabytes an Speicher. D.h. wenn Digits/Decimals größer MaxInt wird benötigt man weit weit mehr als Terabytes Rechner. Mal abgesehen von der nötigen Rechenzeit.

Es macht also keinen Sinn Digits/Decimals größer als Integer zu deklarieren.

Allerdings macht es dagegen Sinn die Zahlenbasis "Base", die Wurzel Root selber und den Wert A von dem man die Wurzel berechnen will zu übergeben.

Mit obigen Code würde man zB. mit NRoot(R, NInt(15), 2, 1000, 8); die 2'te Wurzel aus 15 zu 1000 Oktalen Nachkommastellen berechnen. Also 15^(1/2) * 8^1000.

Mit NRoot(R, NTwo, 2, 1000, 10); demzufolge 1000 Nachkommastellen von Quadratwurzel aus 2, und NRoot(R, NTwo, 3, 1000, 10); die 3'te Wurzel aus 2 mit 1000 Nachkommastellen.

Man wird bei Wurzeln > 2 feststellen das der Quadratwurzel Algorithmus um Längen schneller ist als zu höherwertigen Wurzelbasen.

Gruß Hagen

[negaH]

Da die Implementierung von NSqrt() im Vergleich zu NRoot() im DEC so enorme performance Unterschiede aufweist, sollte folgender Code wesentlich schneller sein als obiger Code.

Delphi-Quellcode:

procedure NRoot(var R: IInteger; const A: IInteger; Root,Digits: Integer; Base: TBase = 10); overload;
// R = A^(1/Root) * Base^Digits
resourcestring
  sNRoot1 = 'NRoot(), invalid paramater Root, must be >= 2';
  sNRoot2 = 'NRoot(), invalid paramater Digits, must be >= 0';
var
  T: IInteger;
begin
  if Root < 2 then NRaise(@sNRoot1);
  if Digits < 0 then NRaise(@sNRoot2);
  NPow(T, Base, Digits);
  NPow(T, Root);
  NMul(R, T, A);              //  R = T * A
  while not Odd(Root) do
  begin
    NSqrt(R);
    Root := Root shr 1;
  end;
  if Root > 1 then NRoot(R, Root);
end;

Gruß Hagen

[c113plpbr]

Hi NegaH!

Also, ich weis ja nicht ob das absicht is aber ich kann das bpl - Package nicht installieren. Zuerst kommt folgender Fehler (Der eigentlich bei Installiertem DEC zu erwarten ist):

Zitat:

---------------------------
Delphi 7
---------------------------
Cannot load package 'DECMath.' It contains unit 'DECUtil,'which is also
contained in package 'DEC'
---------------------------
OK
---------------------------

Is eigentlich zu erwarten, also, deinstalliere ich das angegebene package bzw. mache den haken davor weg, und probiere es nochmals:

Zitat:

---------------------------
Delphi 7
---------------------------
Package K:\Delphi\DECMathD7\DECMath.bpl can't be installed because it is not a
design time package.
---------------------------
OK
---------------------------

Liegt das nun an meinem Delphi oder an deinem Package?

Thx, c113plpbr

Noch was:
Du wolltest doch kritik o.ä. hier hast du was ...

[Mario]

Hagen hatte hier nur die Packages für D5 und D6, nicht aber für D7 veröffentlicht (wenn ich nichts übersehen habe). Die kannst Du dann natürlich nicht verwenden, da sie schon teilweise fertig compiliert sind.

Nachtrag:
Ich nehme alles zurück, das D7 Package ist natürlich hier dabei, also ist es was anderes.

[c113plpbr]

Hi Mario!

Schau nochmal genau hin: im 7. Beitrag auf der 3. Seite is nen Anhang ... Für Delphi 7 (D7).

Nichts für ungut ...

[Mario]

Zitat von c113plpbr:

Hi Mario!

Schau nochmal genau hin: im 7. Beitrag auf der 3. Seite is nen Anhang ... Für Delphi 7 (D7).

Nichts für ungut ...

Darum ja mein Nachtrag

[negaH]

Nichts wird installiert. Ihr entpackt die ZIP's mit Ordnern. Dann öffnet ihr direkt z.B. das Test Projekt. In den Compileroptionen mit Packages compilieren abhacken, und im Editfeld sollte nur DECmath stehen. Im Searchpath des Projectes sollte "..\" stehen. Fertig, es sollte dann alles glatt laufen. Rein theoretisch kann man sogar die *.DCU Files alle löschen, wenn man mit Laufzeitpackage DECMath compiliert. Um dann aber die EXE starten zu können muß entweder DECMath.bpl ins selbe Verzeichniss wie die EXE kopiert werden, oder aber Pfad zu DECMath.bpl gelegt werden, oder DECMath.bpl wird ins System kopiert. Ich persönlich bevorzuge den Weg die Packages immer zur EXE zu kopieren.

Gruß hagen

[negaH]

Ach eines noch. Im DECMath Package sind andere Versionen der Units aus dem DEC Package enthalten. Es kann also je nach Compiler-Suchpfaden zu kleineren Problemen kommen. Am besten ist es temporär einfach den Ordner in dem sich DEC Part I Version 3.0 befindet umzubenennen. Dadurch findet der Delphi Compiler diese Sourcen nicht mehr und wird auch nicht mehr versuchen sie neu zu compilieren. Stattdessen wird er, so wie vorgesehen, ausgehend vom Projekt den Unterordner durchsuchen, und dort die von mir mitgelieferten DCU's finden. Dieses "Problem" hat man immer schon mit Borland Produkten gehabt. Sein Borland Pascal 4 bis Version 7, dann BPW1 und 1.5, weiter mit Delphi 16 bis Delphi 7 und wahrscheinlich auch im Delphi 8, bei allen Versionen ist das einstellen der Suchpfade fürs Projekt, bis hin zur Speicherung dieser Pfade in den Projektoptionen, schon immer schlecht gelösst.


Also:
1.) Die ZIP's mit Pfaden entpacken
2.) den Ordner der DEC Part I Installation x:\DEC\Source umbenennen in x:\DEC_\Source
3.) Test Projekt in x:\DEC_D?\Test\ öffnen
4.) in den Compileroptinen ohne Packages compilieren einstellen
5.) F9

wenn man DECMath.bpl nutzen möchte und die DCU's löschen will, dann
4.) DECMath.bpl nach x:\DEC_D?\Test\DECMath.bpl kopieren
5.) in den Compielroptionen mit Packages compilieren einstellen, DECMath im Editfeld eingeben
6.) F9

Gruß Hagen

[Dax]

@negaH: Du hast im Quelltext der nint_1 geschrieben, es könne wömiglich schneller gehen(die Pi-Berechnung). Aber wie?