GNURZ - Arithmetik-Unit für große Zahlen

[mschnell]

Wahrscheinlich wird innerhalb eines halben Jahres die Unterstützung von Gleitkommazahlen anfallen, die dann auch der GNURZ zugute kommen wird. Mal schaun, wie sich das entwickelt.

Vielleicht sollte man sich NX 'mal genauer ansehen und dessen interne Verarbeitung mit dem anwenderfreundlichen Interface von GNURZ kombinieren.

Noch schöne wäre natürlich Operator-Overload...

-Michael

[Euklid]

Da stimme ich dir zu. Es muss natürlich noch jemanden geben, der die Zeit hat, Entsprechendes umzusetzen - was denke ich unser eigentliches Problem ist

Viele Grüße, Euklid

[Euklid]

Oft wurde gefordert, dass die GNURZ auch negative rationale Zahlen unterstützen soll. Die zugehörigen Routinen wurden von mir die vergangene Woche erstellt und angepasst - ich werde sie demnächst veröffentlichen. Der erstellte Code soll aber abwärtskompatibel sein, und da habe ich eine Frage an Euch:

Es existiert bereits der Typ GRaZTyp, der momentan wie folgt definiert ist:

Code: Alles auswählen

GRaZTyp = record                              
    nenner, zaehler: GNZTyp;
  end;

Durch die Angabe von Zähler und Nenner lässt sich jede beliebige POSITIVE rationale Zahl darstellen. Die Erweiterung für den negativen Zahlenraum wurde durch ein einfaches Boolean realisiert:

Code: Alles auswählen

GRaZTyp = record                           
    nenner, zaehler: GNZTyp;
    Negativ: boolean;                           //Negative Zahlen werden unterstützt!
  end;

Damit diese neue Definition des GRaZTyps abwärtskompatibel ist, muss das Boolean Negativ von vornherein auf false gesetzt sein - denn dann verhalten sich die Arithmetikroutinen wie früher. Nur wie erreiche ich das?

Kurz: Wie kann ich bereits in der Definition des oben angegebenen Records der Variablen Negativ den Wert false zuweisen?

Viele Grüße, Euklid

[mschnell]

Sind denn negative ganze Zahlen inzwischen "technisch richtig" gelöst ? (bei Addieren und Subtrahieren braucht das Vorzeichen nicht berücksichtigt werden, weil die "eins-Komplement" Zahlendarstellung das automatisch regelt <es sei denn man erlaubt beim Addieren und Subtrahieren eine automatische Vergrößerung der Bitlänge>, zum Multiplizieren und Dividieren gibt es "Cardinal" und "Integer" Varianten).

Somit sollte es keine solche boolean-Variable geben und das angesprochene Problem würde nicht auftreten.

-Michael

[Euklid]

Sind denn negative ganze Zahlen inzwischen "technisch richtig" gelöst ? (bei Addieren und Subtrahieren braucht das Vorzeichen nicht berücksichtigt werden, weil die "eins-Komplement" Zahlendarstellung das automatisch regelt <es sei denn man erlaubt beim Addieren und Subtrahieren eine automatische Vergrößerung der Bitlänge>, zum Multiplizieren und Dividieren gibt es "Cardinal" und "Integer" Varianten).

Somit sollte es keine solche boolean-Variable geben und das angesprochene Problem würde nicht auftreten.

Die Vorzeichenlösung, wie du sie vorschlägst, mag zwar auf Assemblerbasis die eleganteste Lösung zu sein. Jedoch wird der Code dadurch schwer wartbar, zumal ich Assembler nur ansatzweise nachvollziehen kann. Daher kannst du diese Lösung in der GNURZ-ASM gerne umsetzen.

Ich bevorzuge übersichtlichen, leicht überschaubaren Code, den man leicht nachvollziehen und debuggen kann. Kannst du mir bei meiner Frage weiterhelfen?

-Euklid

[pluto]

Kurz: Wie kann ich bereits in der Definition des oben angegebenen Records der Variablen Negativ den Wert false zuweisen?

Per Record garnicht, aufjedenfall nicht Automatisch.

Eine Andere Lösung währe Compiler Schalter zu nutzen. Weißt du wie ich meine ?
Dann hättest du das Problem nicht mehr, in älteren Versionen ist per Default der ältere Record Aktiv und bei neueren der neue record.

Bei Klassen währe es einfacher gewesen. Unterstützen record das "Default" schlüsselwort ? das kann man in Klassen nutzen bei Eigenschaften, das währe eventuell eine andere Lösung noch: Erstelle innerhalb des records eine Eigenschaft. Könnte gehen. In Verbindung mit Default währe das Problem dann gelöst.

[Hitman]

Bei Klassen währe es einfacher gewesen. Unterstützen record das "Default" schlüsselwort ? das kann man in Klassen nutzen bei Eigenschaften, das währe eventuell eine andere Lösung noch: Erstelle innerhalb des records eine Eigenschaft. Könnte gehen. In Verbindung mit Default währe das Problem dann gelöst.

Das stimmt nicht. Default ist für RTTI und primär fürs Streaming gedacht - mit der Variableninitialisierung hat das überhaupt nichts zu tun. Siehe auch http://community.freepascal.org:10000/d ... 1-790006.4 (ganz unten).

[pluto]

ach so ! Hatte schon seltsame Probleme in dieser Hinsicht. Eigentlich schade.

[mschnell]

Die Vorzeichenlösung, wie du sie vorschlägst, mag zwar auf Assemblerbasis die eleganteste Lösung zu sein. Jedoch wird der Code dadurch schwer wartbar,...

Nicht wegen Assembler, sonder wegen Informatik . Ist mir aber klar, deshalb habe ich ja auch aufgegeben. Außerdem wäre ohnehin die bessere Lösung, etwas auf Basis von NX zu bauen, das ist seit langem schon viel weiter als GNURZ.

-Michael

[Euklid]

Du vergleichst zwei Projekte mit unterschiedlicher Zielsetzung. NX ist noch alpha. Die GNURZ-Arithmetik ist fertig entwickelt.

[Euklid]

Version 1.0 der GNURZ-Arithmetik veröffentlicht

Die GNURZ hat nun ein stabiles Stadium erreicht.

Neuerungen:
* Unterstützung von negativen rationalen Zahlen
* Eine eigene Projekt-Homepage auf LazForge

Weitere Informationen zur Handhabung befinden sich auf der Projektseite: http://forge.lazarusforum.de/projects/show/gnurz

Viele Grüße, Euklid

[indianer-frank]

Version 1.0 der GNURZ-Arithmetik veröffentlicht
Die GNURZ hat nun ein stabiles Stadium erreicht.

Von einem stabilen Stadium erwarte ich eigentlich, daß man ohne Warnungen kompilieren kann und offensichtliche Bugs beseitigt sind. Beides ist nicht der Fall. Für das fast minimale Demopromamm

Code: Alles auswählen

program t_g1;
{$mode objfpc}{$H+}
uses gnurz;
 
var
  GO: TGnurz;
  a, b, c: GNZTyp;
 
begin
  GO := TGnurz.create;
  a := GO.StrToGNZTyp('2');
  b := GO.StrToGNZTyp('3');
  c := GO.GNZadd(a,b);
  writeln('a=',GO.GNZTypToStr(a), ', prim: ', GO.GNZIstPrim(a));
  writeln('b=',GO.GNZTypToStr(b), ', prim: ', GO.GNZIstPrim(b));
  writeln('c=a+b=',GO.GNZTypToStr(c), ', prim: ', GO.GNZIstPrim(c));
end.

erhält man während des Kompilierens:

Code: Alles auswählen

Free Pascal Compiler version 2.2.4 [2009/04/10] for i386
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Win32 for i386
Compiling t_g1.pas
Compiling gnurz.pas
gnurz.pas(223,5) Note: Local variable "laenge" not used
gnurz.pas(854,13) Note: Local variable "Ueberschlag" not used
gnurz.pas(991,27) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1002,30) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1003,36) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1052,27) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1063,30) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1064,36) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(919,10) Note: Local variable "testt3" not used
gnurz.pas(921,20) Note: Local variable "testt" not used
gnurz.pas(921,26) Note: Local variable "testt2" not used
gnurz.pas(921,33) Note: Local variable "testt4" not used
gnurz.pas(921,40) Note: Local variable "testt5" not used
gnurz.pas(1145,67) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1156,27) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1167,30) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1168,36) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1210,27) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1221,30) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1222,36) Warning: Mixing signed expressions and longwords gives a 64bit result
gnurz.pas(1093,10) Note: Local variable "testt3" not used
gnurz.pas(1094,36) Note: Local variable "LaengeErg" not used
gnurz.pas(1096,20) Note: Local variable "n_erg" not used
gnurz.pas(1097,5) Note: Local variable "Erg" not used
Linking t_g1.exe
1627 lines compiled, 1.3 sec , 52336 bytes code, 1688 bytes data
13 warning(s) issued
11 note(s) issued

und folgende Ergebnisse (d.h. schon bei den ersten beiden Primzahlen versagt die Library):

Code: Alles auswählen

a=2, prim: FALSE
b=3, prim: FALSE
c=a+b=5, prim: TRUE

Gruß Frank

[indianer-frank]

Noch ein paar elementare Fehler auf die Schnelle:

a := GO.StrToGNZTyp('2147483647');
ergibt a=1!!!

a := GO.StrToGNZTyp('1');
ergibt a = 1 = prim

a := GO.WordToGNZTyp(2);
GO.GNZMillerRabin(a,20));
ergibt a = 2 = NICHT prim

Gruß Frank

[knight]

Von einem stabilen Stadium erwarte ich eigentlich, daß man ohne Warnungen kompilieren kann

Gruß Frank

Die Warnungen kannst du ignorieren. Wenn du Lazarus kompilierst, dann erhälst du auch zahlreiche solcher Warnungen. Solange du keine Fehlermeldung erhälst (welche die Kompilierung unterbrechen würde), ist eigentlich alles in Ordnung.

knight

[indianer-frank]

Von einem stabilen Stadium erwarte ich eigentlich, daß man ohne Warnungen kompilieren kann

Gruß Frank

Die Warnungen kannst du ignorieren. Wenn du Lazarus kompilierst, dann erhälst du auch zahlreiche solcher Warnungen. Solange du keine Fehlermeldung erhälst (welche die Kompilierung unterbrechen würde), ist eigentlich alles in Ordnung.

knight

Trivial ist, daß man ein Produkt mit Compilerfehler nicht als fertig bezeichnen kann. Deine Bemerkungen würde ich für Hints/Notes gelten lassen, aber nicht für Warnungen. Selbst eine 'Note: Local variable "xxx" not used' zeigt doch, daß der Programmierer seinen Quellcode noch nicht fertig überarbeitet hat (da gab's mal die benutzte Variable "xxx", der Code wurde geändert, und jetzt ist die Deklarationsleiche noch da).

Warnungen zeigen potentielle Probleme auf, die beseitigt werden sollten (und sei es nur durch einen Typecast). Ohne näher den Code zu analysieren, könnte es zB sein, daß der Bug MaxLongint = 2147483647 -> 1 angewarnt wurde.

Gruß Frank