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.

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.

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?

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.

Further (and this is the tricky bit) if you could give Calculator dynamic scope, then you could set your preferences and all subsequent computations (whether in your code or code that you call) would conform to your preferences.

Getting back to your original question, with the ability to set preferences like this, then you could let the programmer/user decide where and/or where to use fractions or floats (or integers or decimals). 

Note that you could still have the convienience of infix notation by having the method forward the compuation to the Calculator.

/ aNumber
    ^Calculator divide: self by: aNumber.

If my idea could be made to work, you would wind up with a much more flexible numerical model.

david

--
David Farber
dfarber at numenor.com