[gnucash-de] Re: Monetary data types
Gerhard Gappmeier
gerhard.gappmeier at ascolab.com
Mon Nov 15 04:28:31 EST 2004
Danke für die ausführliche Info.
Da bleibt mir halt nichts anderes übrig, als die Windows-Typen
nachzuimplementieren.
Eingentlich geht's mir auch gar nicht so um die Brechnungen als um die
verlustfreie Übertragung von Daten.
Ich implementiere zur Zeit einen platformunabhängigen VARIANT, der unter
anderem auch die Typen CY und DECIMAL aufnehmen muss.
Dabei Müssen Arrays von Werten (Prozessdaten) verschiedener Typen, die
als VARIANT bei DCOM oder als anyType bei SOAP übertragen werden
auch auf Linux entsprechend in einen eigenen VARIANT aus unserer C++ API
gewandelt werden.
Interpretieren muss ich die Strukturieren nur soweit, dass ich die Typen
bei einem VariantChangeType-Aufruf in anderen Typen umwandeln kann.
Zum Beispiel bei der Darstellung als String.
Andere arithmetische Funktionen brauche ich zum Glück nicht.
Z.Info die Windows-Definitionen aus wtypes.h.
DECIMAL: hier beträgt der Wert Lo64 * 10 ^ -scale
Über das sign in signscale bin ich mir noch nicht klar, da der Wert nur
in eine Richtung skaliert werden kann soweit ich gesehen habe.
typedef struct tagDEC {
USHORT wReserved;
union {
struct {
BYTE scale;
BYTE sign;
};
USHORT signscale;
};
ULONG Hi32;
union {
struct {
#ifdef _MAC
ULONG Mid32;
ULONG Lo32;
#else
ULONG Lo32;
ULONG Mid32;
#endif
};
ULONGLONG Lo64;
};
} DECIMAL;
CY: hier ist die Precision konstant
z.B.: Wert = int64 * 10 ^ -4
typedef union tagCY {
struct {
#ifdef _MAC
long Hi;
long Lo;
#else
unsigned long Lo;
long Hi;
#endif
};
LONGLONG int64;
} CY;
Christian Stimming wrote:
>Am Freitag, 12. November 2004 11:03 schrieben Sie:
>
>
>>ich habe da mal eine Frage zu fixed precision data types unter Linux.
>>Unter Windows gibt es da den DECIMAL type, der eben speziell für
>>finanzielle Berechnungen eingesetzt wird, damit man im Gegensatz zu
>>Floating-Points immer die gleiche Precision hat.
>>Was gibt es da vergleichbares unter Linux?
>>Bei GnuCash wird so was ja auch bestimmt eingesetzt.
>>
>>
>
>Es gibt unter Linux/Posix-Unix keinen allgemein verwendeten Typen, der sowas
>macht!!!
>
>Man muß sich also in jeder Software selber aus den Basistypen eine passende
>structure zusammenbauen und die dann verwenden. Die Frage ist also völlig
>berechtigt und ich habe kurzerhand mal nachgesehen, was die ganzen
>OpenSource-Programme so haben:
>
>GnuCash
>-----------
>In Gnucash war seinerzeit (Mitte 2000) die Entscheidung getroffen worden, daß
>man "rationale Zahlen" benutzt, also einen ganzzahligen Zähler und Nenner,
>siehe src/engine/gnc-numeric.h:
>
>struct _gnc_numeric {
> gint64 num;
> gint64 denom;
>};
>
>siehe auch https://cvs.gnucash.org/cgi-bin/cvsweb.cgi/gnucash/src/engine/
>gnc-numeric.h?rev=1.23 -- unbedingt den CVS-HEAD branch verwenden und nicht
>die Version im 1.8.x-Branch, da in HEAD sehr viel mehr Dokumentation drin
>ist.
>
>[Der Typ "gint64" kommt aus der glib (der glib von Gnome, nicht zu verwecheln
>mit der glibc), weil innerhalb der glib für die unterschiedlichen Plattformen
>die passenden typedefs gesetzt werden, so daß die Applikation sich bei gint64
>darauf verlassen kann, daß das überall 64 bits sind. Aber das nur am Rande.]
>
>In Gnucash sind wir also zu rationalen Zahlen gegangen (und der code darf
>gemäß GPL gerne woanders weiterverwendet werden), aber wahrscheinlich war das
>ein overkill. Fix-Point Zahlen, also etwas Ganzzahliges mit fester
>Komma-Position, wären wahrscheinlich in der Implementierung wesentlich
>einfacher gewesen. Nichtsdestotrotz müsste man auch dabei eben alle
>arithmetischen Operationen für den neuen Typ einbauen und dabei für alle
>Möglichkeiten bei Rundungen sich die Auswahlmöglichkeiten überlegen (also ob
>die zusätzlichen Nachkommastellen beim Multiplizieren nachher gerundet werden
>oder nicht etc). Und in der Implementierung wäre ich nicht auf Anhieb so
>sicher, wie genau man das machen würde -- da man ja Binärzahlen hat, wäre es
>mit der einfachen Angabe "Nachkommastellen zur Basis 10" ja nicht erledigt,
>denn die gespeicherte Ganzzahl ist ja eine Ganzzahl zur Basis 2. Wie auch
>immer. In Gnucash gibts halt die Brüche mit einer hoffentlich vollständig
>richtigen Implementierung und die verwenden wir nun mal.
>
>KMyMoney
>-------------
>Tja, offensichtlich haben die Kollegen dort das mit der GPL bereits ganz
>richtig verstanden :-) . Im Februar 2004 haben die nämlich ihrerseits den
>Umstieg von "double"-Werte zu ganzzahligen Werten gemacht, und sie haben dazu
>genau den GnuCash-Code aus gnc-numeric.h/c rüberkopiert und in eine C+
>+-Klasse umgeschrieben. Wenn du also so eine Implementation mit rationalen
>Zahlen in C++ suchst, dann findest du die in kmymoney2, Klasse MyMoneyMoney
>in mymoneymoney.h.
>
>Grisbi
>------
>Die Herren von der Gtk2-Konkurrenz dagegen sind noch dabei stehengeblieben,
>daß die Finanz-Werte als "double" gespeichert werden. Denen steht der Umstieg
>also noch bevor -- aber vorher müssten die sich eh noch von der französischen
>Sprache im Quelltext lösen...
>
>QBankManager
>
>Die einfache Applikation QBankManager, die ja nur zum schnellen Verwalten des
>HBCI-Zugangs dienen soll, benutzt intern ebenfalls nur "double"-Werte (aus
>AB_VALUE). Für den Import/Export von Daten sind "double"s wohl auch ok, denn
>Rundungsfehler bekommt man ja erst bei arithmetischen Operationen mit vielen
>dieser Werte (also z.B. beim laufenden Saldo eines Kontos).
>
>Gruß
>
>Christian Stimming
>
>
>
>
>
--
mit freundlichen Grüßen / best regards
*Gerhard Gappmeier*
ascolab GmbH - automation system communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-Key: http://www.ascolab.com/pgp/gerhard.asc
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.gnucash.org/pipermail/gnucash-de/attachments/20041115/81454f3d/attachment.htm