Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!howland.reston.ans.net!torn!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Substraction Problems :-(
Message-ID: <knight.794175511@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
References: <n1418055460.96701@smtpgwprod.ny.jpmorgan.com>
Date: Thu, 2 Mar 1995 20:18:31 GMT
Lines: 50

In <n1418055460.96701@smtpgwprod.ny.jpmorgan.com> "Alvarez, X." <alvarez_x@JPMORGAN.COM> writes:

>I'm afraid that you're taking the wrong approach here.  If any language that
>I'm working with, and when confronted with a very simple arithmetic problem
>gives me an incorrect answer, I'm in trouble, no matter the vendor.

>To make things more problematic, the applications that I develop deal with
>money, that even worsens it - maybe up to a point in which I just can't trust
>any more the language forcing me to go back to some other language :-(.

I'm afraid the problem runs depeer than this. This is NOT a Smalltalk
problem. This is a floating point arithmetic problem. It will happen
in C (although it may be hard to track down amidst all the automatic
conversions back and forth from doubles). It will happen in FORTRAN.
It will happen in BASIC. Floating point numbers cannot accurately
represent certain numbers. These types of errors _will_ occur. This is
basic, and this question recurs so often it's frightening. If people
are working in situations where this kind of thing is important they
need to either stop using floats or take some numerical analysis.

The simple solution is not to use floating point numbers for things
like money. 

>Getting back to the guts of the original problem is that FixedPoints are
>coerced when confronted against Floats or Doubles due to the higher
>generality of these LimitedPrecisionReals.  So my FixedPoint numbers aren't
>protected against being coerced to higher generalities and thus losing my so
>precarious semantics, and invalidating the "100.9f - 100.0f" approach because
>I can't be sure that any float or double sneaks in.

Try making an object for money which holds a fixed point
representation internally and whose methods that take numeric
arguments convert them to fixed point first.

>A crazy idea could be to raise the generality of FixedPoints to something
>greater than 90 so as to make the LimitedPrecisionReals to loose, but I
>suppose that PPS gave them 70 as their generality number with reasons I'm in
>no position to challenge.

I think you have to get over this assumption that Smalltalk vendors
necessarily know what they're doing, and what's right for your
circumstances. Changing basic system behaviour like that is something
whose consequences you want to consider carefullly before doing it,
but I'd certainly be tempetd to give it a try.

-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan_knight@mindlink.bc.ca | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2
