David Farber <dfarber at numenor.com> wrote:
	Andreas - I think that keeping the precision of a fraction is
	the right thing to do (as has been well argued already) but I
	think it is also true, as Stephen pointed out, that most people
	really don't think in fractions.

Ah, be careful here.  MOST people are not computer programmers,
and are more likely to understand fractions than floating point numbers.
Let's face it, if most people were comfortable with floating-point
numbers, we wouldn't have any of this ISO prefix nonsense;
instead of papers talking about consumers wasting so many milliwatts
(mW) when they mean megawatts (MW) they'd talk about 2.5e6 W, and
there certainly would have been no point in inventing "yotto" and
"zeppo" or whatever the new prefixes are.

The problem with the readability of large fractions is three-fold.
(1) People don't normally write 7/2, they write 3 1/2.
(2) Numbers with lots of digits are inherently unreadable
    unless the digits are separated into groups.  As far as I'm
    concerned, one of the most brilliant innovations in Ada was
    letting people put underscores in numbers, so that an Ada
    programmer can write 1_234_456_789 and you can see at a
    glance (count the underscores) that it's about a milliard.
(3) Numbers with lots of digits are inherently incomprehensible
    to (most) people anyway.  There's a limit beyond which nothing
    but simplification helps.  If you want to write a number out
    so that you can read it back and get the same number,
    1_234_456_789/768_552_183 is perfect.  If you want someone
    to understand it, "1 3/5 and a bit" is hard to beat.

The fact that what counts as a good presentation depends on context,
on who is expected to read the presentation, is what makes any blanket
"convert to float for presentation" Preference unworkable.

	I've been thinking that there might be another way around this
	(and other shortcomings like inflexible control over precision and
	coercion) of Smalltalk's numeric model.  My insight (if it
	really is such) is that we need to get rid of the idea that the
	receiver controls the computation--there is just not enough context.
	
Ah.  Subject-oriented programming.  Or to put it another way, PL/I's
special functions for controlling the precision of operations make a
come-back.

	3/4.
	Calculator divide: 3 by: 4.
	
	In the first case, there is no way to add context to the
	computation; context that might say "I want integer division" or
	"I want the result as a fraction" or "I want the result as a
	float".  It is true that you could use different operators for
	each intended result, but what about situations where the
	context isn't known ahead of time?
	
Then you return the most precise answer you can, and let the caller
convert it to whatever the caller wants.  Which is what Smalltalk does.

	In the second case, you could add the context by telling the
	Calculator "Go into integer mode" or "Go into fraction mode" or
	"Go into floating point mode".  You could specify precision and
	coercion preferences in the same way.
	
Indeed you could.  Hey, I could have all the fun of programming bc(1)
in Squeak...

I think it would be a serious mistake to make the results of basic
arithmetic operations depend in any way on a context.  (PL/I programmers
have horror stories to tell about this, and I've had some nasty experiences
in APL, thanks to []CT.  I've also seen some really horrible things in an
IBM mainframe dialect of Prolog where two numbers might or might not
unify depending on whereabouts you asked.)

Oh my.  It appears that I've just committed lese majestie against
IEEE floating-point and am to be beheaded in the Numeric Tower.

In my defence, I'd like to point out that if you can't tell whether
x+y is going to round up, round down, truncate, or round to nearest,
you're in exactly the kind of swamp that IEEE arithmetic was supposed
to save us from.  While IEEE rounding and precision may be *implemented*
as a global mode in the FPU, the intent is that they should be *used*
locally; it's part of several ABIs that a function which alters any of
the IEEE modes should put them back the way they were before exiting.

There's nothing wrong with Calculator objects all having their own
private modes.  That would be an interesting addition to Squeak.  I wonder
how much use they would be, except for implementing desk calculators?