Well, then it seems that I have to wait until 128-bit pointer is common,
in which case VALUE is defined as "unsigned long long long" :).

Is it then correct if I say that the current Ruby will not work in a
16-bit system, where 'long' is only 16 bits?  (Not common at all, although
I am not sure about some embedded systems.  But probably no one will ever
use Ruby in an embedded system, although some people here use Java to do
embedded programming.)

Regarding the test suites, is it really that much more complicated than
the corresponding test suites for FixNum and BigNum?  For a first cut,
probably we can sacrifice exponent rather than mantissa and have the same
logic as the conversion between FixNum and BigNum when we have FixFloat
(31-bit 'float') and BigFloat (pure, native 64-bit 'double').  (People who
do numerical computations extensively and care about precision should have
used NArray, anyway.)

But in the end, I think you would be right; probably this complication is
not worthwhile.  Here I am just trying to draw analogy with Java (we don't
have to reinvent the wheel, and there is nothing wrong to take the good
things, right? :) )

Regards,

Bill
===========================================================================
Paul Brannan <pbrannan / atdesk.com> wrote:
> There is a standard (ieee 754), but not everyone uses it.  There are
> some systems out there that even use base-10 floating-point arithmetic
> instead of base-2 like the rest of us.

> Even if we assume that Ruby will only ever run on systems that use the
> ieee recommendations, manipulating the bits in a double really isn't a
> game we should play; it will probably give a lot of programmers
> surprising results.  It would also require writing a test suite so we
> can make sure we haven't broken anything (i.e. infinity/NaN are still
> representable, addition/subtraction/etc. work for all combinations of
> numbers, precision isn't lost except the precision we expect to lose by
> throwing out a bit, etc.).  In short, it's just not worth the trouble.

> Paul