On Sun, 19 Jun 2005, Aubrey Jaffer wrote:

> | It often happens in neural networks (read: my day job) that
> | being able to store a bunch of floats compactly (level-2
> | cache size) results in dramatic speedups, and in such cases
> | (in C) I use arrays of 32-bit floats rather than 64-bit
> | doubles.

> | But a couple of years ago, I had a (toy) project where I was
> | <clip>. And in that project, having 512-bit precise reals <clip>
> | was *NECESSARY*, since even with scaling, using "doubles" would
> | have lost crucial information in the underflow.

> Would weakening the "most precise" requirement to a recommendation
> improve Scheme as a platform for such arithmetics?

It's hard to know what to do.  No portable code relying on
particular float sizes can be written on the basis of R5RS.
The suggested change of weakening the requirement to a
recommendation would not enable such code, so the situation
for specialized calculations would not be improved.  But
I think maybe code like that *ought* to be the domain of
implementation-specific extensions rather than scheme
itself.

Because I don't think that scheme ought to concern
itself overmuch with the underlying hardware representations,
I wouldn't like the specification of an exact floating
point representation to become part of the language
standard.  But I would like to be able to tell the
system what minimum precision I need and let it decide
what underlying representation it can use to most
economically and effectively meet that requirement.

It is, and ought to remain, an error for code to
*rely* on a particular roundoff or wraparound error
resulting from a hardware operation on a limited-precision
number, and therefore specifying an exact size rather
than a minimum size for inexact numbers is not "the
right thing."

What I would *like* is to have a way to specify what
precision to use for inexact-number calculations in a
given (ideally dynamic, but given scheme's design more
properly lexical) scope.  I would like to be able to
say

(with-precision 512 220 expr)

in order to let the compiler know that if at least 512 bits
of mantissa and 220 bits of exponent are retained for inexact
calculations, expr (whether a single number, or a function
call) will not result in an intolerably erroneous result.
The system, if capable, may allocate and use inexact numbers
of that precision or higher, or evaluate the expr using only
exact numbers, or otherwise, must report a violation of an
implementation restriction.  And likewise, if I say

(with-precision 10 6 expr)

it would be a promise that 10 bits of mantissa and 6 of
exponent are enough to get results tolerable for my purposes
and the compiler could use 32-bit floats, or even 16-bit
floats of the suggested format, if the hardware and compiler
happen to support exactly that.  But if it happens to be
a martian architecture that uses words of 27 ternary trits
instead of 32 binary bits, that would be okay too as long
as it were capable of *at least* that precision.

In this system we wouldn't have to worry about comparisons
between inexact numbers of different precision, because
being in the same scope, all inexact numbers would have
the same precision.  But you could still use the precision
you actually need for your calculations and not have the
system wasting resources with too much precision where it's
not needed.  And it insulates code enough from the hardware
for future systems no matter how strange or unexpected, to
not be required to simulate the roundoff errors of older
systems nor use restricted representations where doing so
would slow them down.

That's what I'd like.  But is it reasonable to require it?
I dunno.  Maybe it's proper SRFI material, as long as
everything else under the sun in terms of numeric fixes is
being proposed.

				Bear