Re: Openstep Enterprise 4.2

[Christian Edward Gruber]

Time for a category NSDecimalNumberFix.[hm]. ;)
cg.

----- Original Message -----
From: <David.Ayers@brainag.com>
To: "Marcus Müller" <znek@mulle-kybernetik.com>; "Gregory Casamento"
<greg_casamento@yahoo.com>
Cc: <discuss-gnustep@gnu.org>
Sent: Tuesday, April 30, 2002 5:02 AM
Subject: Re: Openstep Enterprise 4.2


>
> Hi
>
> well actually it's not that simple. I'm not creating this decimal from a
string
> or a float. It is the result of concrete NSDecimalNumber calculations.
(Granted
> it seems odd that sending an NSDecimalNumber description results in a
string
> with seemingly higher precision than definded by OPENSTEP.) But even if I
did
> create it from a string, I would've been happy, as long as exceeding the
> precision would lead to a rounded NSDecimalNumber, which not only
compare:'s as
> NSOrderingSame, but also returns the same string from description. This is
the
> problem, that I have two NSDecimalNumbers which compare: as NSOrderingSame
yet
> return different NSStrings when sent description. Everything would be
dandy, if
> the precission were exceeded and  both numbers would return the same
string! But
> claiming they are NSOrderingSame while returning different strings is
(IMHO) a
> bug. Now I've also verified that the NSDecimal-structs are very different
(which
> is of no surprise since the produce different descriptions.) What I
concider the
> bug is to allow loss of percision whilst comparing, (and from checking the
> NSDecimalCompare() code of GNUstep, I'm not alone in this assumption :) )
This
> is why I would consider it a bug to call NSDecimalNormalize() from
> NSDecimalCompare(). Yet since I haven't quite understood the NSDecimal
structure
> of Openstep 4.2 and the NSDecimalCompact procedure/algorithem, I'm still
not
> sure whether or not NSDecimalNormalize() might be necessary in some form
which
> retains the precision.
>
> I've been experimenting with memcpy on function addresses but this is
SIGSEGV-
> segfautling at every approach so far. I guess all I can do is create an
> NSDecimalNumberPoser an either just verify isEqual: with the comparison of
the
> description or try to finish implementing a corrected
NSDecimalCompareBugFixed()
> and calling that in NSDecimalNumberPoser compare: and hope that the
original
> NSDecimalCompare() function isn't used very often. (yet I'm pretty sure it
is
> and I'm not sure whether that it is worth the effort of reimplementing
> NSDecimalCompare() from disassembled code.)
>
> But if it's done nothing else, this thread could be viewed as another
prime real
> world example of why one should only use free software! (what's the status
of
> gdl2?)
> Thanks for the feedback anyway.
>
> Dave
>
> PS: Please send any responses privatly, since this now really getting out
of the
> GNUstep realm. Consider it a last call for help from people who might know
how
> to manipulate the "function-dispatch-table" (if something like this
exists)
> Maybe I'll try to ask again on the gcc mailing list.
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>
>