Vergleich von Real-Werten ---> klappt nicht

[alex517]

nach dem man die Theorie verstanden hat,
kann man es sich auch leichter machen und auf vorhandene
Funktionen zugreifen wie z.B.:

Delphi-Quellcode:

uses Math;

function SameValue(..)
function IsZero(..)
function CompareValue(..)

...

alex


Edit:

Delphi-Quellcode:

function SameValue(const A, B: Single; Epsilon: Single = 0): Boolean; overload;
function SameValue(const A, B: Double; Epsilon: Double = 0): Boolean; overload;
function SameValue(const A, B: Extended; Epsilon: Extended = 0): Boolean; overload;

function IsZero(const A: Single; Epsilon: Single = 0): Boolean; overload;
function IsZero(const A: Double; Epsilon: Double = 0): Boolean; overload;
function IsZero(const A: Extended; Epsilon: Extended = 0): Boolean; overload;

function CompareValue(const A, B: Integer): TValueRelationship; overload;
function CompareValue(const A, B: Int64): TValueRelationship; overload;
function CompareValue(const A, B: Single; Epsilon: Single = 0): TValueRelationship; overload;
function CompareValue(const A, B: Double; Epsilon: Double = 0): TValueRelationship; overload;
function CompareValue(const A, B: Extended; Epsilon: Extended = 0): TValueRelationship; overload;

@Medium, #12: so besser?

[Medium]

Wobei diese Funktionen durchaus mit Vorsicht zu genießen sind, wenn mit den Werten zuvor sehr viel herumgerechnet wird. Wenn es meinetwegen um die Nte (groooßes N) Iteration einer konvergierenden Reihe geht, und das Ergbnis mit dem erwarteten Grenzwert werglichen werden soll, kann es sein dass das in diesen Funktionen verwendete Epsilon (IMHO ist es das sog. Maschinen-Epsilon) zu klein wird.
Der Vergleich hinkt, da eine Reihe ja per Definition schon nur eine Näherungsfunktion ist, das ganze trifft aber generell zu. Je mehr Operationen ich verwendet habe um zu einem Wert zu kommen, desto heftiger haben sich dabei diese Darstellungfehler aufsummiert, -potenziert, -wasauchimmer-iert. Ich meine aber auch, dass von denen überladene Versionen existieren, bei denen man das Epsilon selbst übergeben kann. Im Grunde sehen die intern auch nicht viel anders aus als das händische abs(wert-vergleichswert)<epsilon, ist im Code nur hübscher leserlich.

[marcibaer]

Hallo zusammen!

Wenn es doch IMMER nur um max. 2 Nachkomma-Stellen geht, kann man doch das Ganze einfach mit 100 multiplizieren.
Die Konstanten wären dann also z.B. 102 , 576 oder 805 - und die Ungenauigkeiten sind weg!
So rechne ich immer, wenn ich mit Geld-Beträgen zu tun habe - also in Cent und nicht in Euro!

Hoffe, das macht es einfacher!?

Marcibaer

[markus5766h]

Zitat von marcibaer:

Hallo zusammen!

Wenn es doch IMMER nur um max. 2 Nachkomma-Stellen geht, kann man doch das Ganze einfach mit 100 multiplizieren.
Die Konstanten wären dann also z.B. 102 , 576 oder 805 - und die Ungenauigkeiten sind weg!
So rechne ich immer, wenn ich mit Geld-Beträgen zu tun habe - also in Cent und nicht in Euro!

Hoffe, das macht es einfacher!?

Marcibaer

leider nicht ganz :
bei den Konstanten gebe ich Dir recht, diese könnten dann Integer-Werte werden.
Beim Ergebnis "Rv" nützt das allerdings nicht viel, wenn die Ungenauigkeit erst
an vierter, fünfter (oder weiß wo ..) Stelle nach dem Komma auftritt:
102 ist eben nicht gleich 102,0000000012

wie Daniel schon geschrieben hat, nützt da auch das Casten nach Integer nichts.

[himitsu]

Für Geldbeträge nimmt man Currency, denn dieses rechnet auf 4-Nachkommastellen genau
und ist intern ein skalierter Int64.