Re: Openstep Enterprise 4.2

[Gregory Casamento]

The problem is one of precision and not specfic to OpenStep/GNUstep in any way.

See below:

[heron@genoa heron]$ gcc precision.c
[heron@genoa heron]$ a.out
values are the same
[heron@genoa heron]$ cat precision.c
#include <stdio.h>

int main()
{
  float 
    v1 = 12.5, 
    v2 = 12.5000000000000000000000000000000000121;

  if(v1 == v2)
    {
      puts("values are the same");
    }
  else
    {
      puts("values are different");
    }

  return 0;
}
[heron@genoa heron]$ 

GJC
--- David.Ayers@brainag.com wrote:
> Hi all,
> 
> Ok I still owe some of you some replies, and they are in the making. (Trying
> to
> be rather concrete.) But my "day time" job has got me spining at the moment.
> I
> figured, since a lot of ex-Opensteppers are on this list maybe someone could
> help me. (I hope no one fells that I'm abusing this list.) Here's my problem.
> 
> It actually is problem of Openstep 4.2 Enterprise (i.e. NT/W2K) (+/- Y2k
> Patch)
> (maybe other Versions of Openstep also ?)
> 
> The short Version:
> NSDecimalCompare(12.5, 12.5000000000000000000000000000000000121)
> evaluates to NSOrderingSame !!!
> 
> Does any one know of a patch? Disassembling NSDecimalCompare reveals that it
> actually calls NSDecimalNormalize() in this case. I figure  it deletes
> trailing
> digits in the mantissa enough to make them equal! Right now I'm attempting to
> "reengineer" the function NSDecimalCompare (and it seems rather time
> consuming)
> to write a replacement, and then I was wondering whether I could redirect the
> NSDecimalCompare symbol to my new function. Has anyone done something like
> this
> before? Does anyone know that this can't be done?
> 
> The long Version
> In an EOF Application some intesive calculations lead to values with minor
> rounding errors. During the processing of [EOEditingContext commitChanges]
> the
> EODatabaseContext executes a private method called
> processSnapshotForDatabaseOperation:(EODatabaseOperation*). During this
> processing the adaptor is asked to provide a value which can be put in the
> datase through fetchedValueForValue:attribute:. This returns the correctly
> rounden value. yet before actually replacing the old value with the returned
> value in the row dictionary the processSnapshotForDatabaseOperation:
> implementation checks whether the to are equal by invoking isEqual: which
> invokes compare: which in turn calls NSDecimalCompare which falsely claims
> yes!
> So the value isn't replaced, and the adaptor send description to the
> NSDecimalNumber to create the c-string
> '12.5000000000000000000000000000000000121' for the database API and the
> database
> sais "I don't think so" and rolls back.
> 
> Ok I've been able to rewrite processSnapshotForDatabaseOperation: skipping
> the
> isEqual: and always replacing the object. But the real bummer is that one
> can't
> count on correct decimal comparisons in other cases and that gives me a
> slight
> headache. (I've even have a college mention an actual error in devisions, but
> I
> haven't been able to reproduce it and track it down, But if someone has an
> example for that, I'd be glad for the hint.)
> 
> 
> Thanx 4 your time.
> Dave
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep


=====
Gregory John Casamento
------------------------------------------------------
Please sign the petition against software patents at:
http://www.petitiononline.com/pasp01/petition.html
------------------------------------------------------

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/