I realize this is stating the obvious, but the loss of precision is the
result of 64 bit integer support. Previously "upgrading" a number from
integer to float was exact. Though the residue problem for very large
numbers still existed, at least it didn't involve loss of precision.
It's my personal opinion that one should always be careful when working
around the limits of a system. But what should be done when things go a
little crazy around those limits? It is unfortunate that IEEE only
implemented indeterminate (_.) when it could have set other flags in the
unused bit configuration to indicate things like underflow, but not
zero or
overflow but not infinity. But they didn't.
A while back J had an option for upgrade to go to rational instead of
float. It was useful in labs to more easily show interesting
properties of
numbers. Is that option still around? If so it could be used in mod
as an
option. But it cannot be always known that the number will eventually be
used in mod. And many transcendental verbs must go to float.
Current hardware now supports quad precision float, at least some do. If
quad float were used then the loss of precision goes away when
converting
64 bit integer to float. But that doubles the size of float, and even
though memory is getting huge it's still a concern for big problems.
Not to
mention that quad float is probably slower than double float. And it may
not be supported on all hardware, similar to the AVX problem.
IBM's PLI has an interesting approach to precision. You told it (in
decimal
digits) the largest numbers you will deal with and the number of digits
after the decimal. Then it picked the best way to store the numbers
given
available hardware. In J we have 64 bit integers and floats with
maybe 16
significant decimal digits and a tremendous range for exponents. Most
problems we deal with don't need such big numbers. An argument many use
against J in that it uses so much memory for small numbers. Perhaps a
global setting with Foreign Conjunction could give a similar choice
for J.
I would argue against it saying things like single/double/quad float or
16/32/64 bit integers, but specify what range and significance is
need and
let J choose how to handle it. Including totally ignoring it for some
implementations. Supporting this could make the J engine larger, but
nobody
seems too concerned with the monstrous size Qt.
Whatever happened with the idea bouncing around of defining a floating
point of arbitrary size and precision like with extended integers and
rationals?
And now IEEE has a decimal float standard. Right now it seems that
only IBM
has implemented it in hardware. But think of all the confusion we see
when
decimal numbers like 1.1 are not represented exactly in J.
Maybe I rambled a bit. But this all involves problems when, for one
reason
or another, the hardware can't handle needed precision.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
