Kero van Gelder wrote:

> 
> 12345678901234567890 / 1.0  => 1.23456789e+19
> 
> which actually looses accuracy, by automatically converting to float,
> instead of BigNum. This would be an argument to drop automatic
> conversion for floats. You could still convert automatically with
> Numerics and Rationals, since you loose nothing (and should expect a
> Rational anyway).
> 

Of course, the number 1.0 is imprecise so you don't loose accuracy. What 
you seem to propose is rather than to convert '12345678901234567890'
to a float is to convert '1.0' to a Fixnum or Bignum, making the result 
look more accurate than it really is (The 1.0 could of course be the 
result of some float, i.e. inaccurate, computation). Of course, you 
could make several Rational classes for Fixnum/Fixnum, Float/Fixnum and 
Fixnum/Float. In my opinion Rational results should be an option rather 
than glued into the language, as many computations involve irrational 
numbers, too. How often do you need to do non-natural number 
computations without having to use pi, sqrt(2), ln(2) or e somewhere. 
True, a Rational 1/5 is more accurate than 0.2 (which actually is 
something like 0.20000000000000001 on  a PC using doubles), but I don't 
think it's the task of a *generic* programming language to do symbolic 
computation by default.

Some people want to use Rationals, other applications might prefer 
Floats or just plain integer arithmetic. You can achieve this result by 
requiring some module. Getting rid of all immediate values might be 
needed to bring consistency across the different numeric types in that case.

Bas