🚀 go-pugleaf

I wrote:
   |Eh?  Why would the numbers be rounded?

Stephen P Spackman:
   Because floating point numbers buy exponent at the expense of the
   mantissa.

Oh.  That's only true if they're stuffed into a word with the same set
of bits.  Many popular machines offer 32 bit integers and 64 bit
floats.  The floats have more bits of mantissa and have an exponent as
well.

   It's sort of the idea.... As soon as you kick over into float, 8 or
   16 lsb's go away. So suddenly you are computing in units of whole
   dollars. And then, every time the number doubles again, away goes
   another bit at the bottom.

I think you're confusing programming language keywords (e.g. C's
'float' and 'double') with a less precise but more generic english
usage.

   I don't understand how we can possibly be disagreeing here.

Probably because we've different backgrounds.  I'm used to APL where
_every_ implementation seems to have floats with more bits of mantissa
than exist in an integer.  The documentation will usually refer to one
as a floating point representation and the other as an integer
representation (if it's mentioned at all).

As an aside, I don't see how it would be safe to coerce back and forth
between float and integer if the float had fewer bits of mantissa than
an integer.  I think this is why bignums are not yet part of the
language.  Perhaps some sort of 'exponent for the whole array' hack
would make it possible to sort of skirt around this issue...

[I say 'hack' because unifying the exponent after a round of
calculations looks like it might be painful.  Also, unless we choose a
representation with an incredibly large number of bits, there are some
cases where floating point would have more precision than this
representation -- which means a partial order instead of a complete
order -- which means the conversion can not be made transparent for
arbitrary calculations.  On the other hand, if we did go to an
implementation with a thousand bits, or whatever, you couldn't trust
fractional numbers to floating point because you'd be getting answers
significantly depending on whether had an intermediate floating point
representation or an intermediate bugnum representation.

Similar problems for 'bigfloats': you can't use lesser floats because
you can't trust them.  I suppose being able to explicitly declare that
some operation is to use the less precise notation would solve this.
But it might be nicer to have a set of functions which (a) do
something algorithmicly useful and (b) limit the bits of mantissa
needed to hold the result...

Current implementations (of APL) just leave bignum implementations up
to the user, which means that decisions about when to use float and
when to use bignum are also left up to the user.  Maybe this is the
best decision?]

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>