On Mon, 14 Nov 2005, Andrew Wilcox wrote:

>Here's an idea that I hope will help unify the competing alternatives
>of R5RS-style Generic Arithmetic and Generic Exact Arithmetic.
>
>My proposal has contagious inexactness, while also offering generic
>procedures that perform the same operation across different types.

Proposal consists of 'fast' operations which are guaranteed to not
spend a lot of time but which are likely to give inexact results
on exact arguments, and 'accurate' arguments which are guaranteed
not to cause a further loss of precision but still give exact
results only when arguments whose exactness may affect the outcome
of the operation are exact.

This is a more principled approach than we now have.  And yes,
it does make things expressible that aren't expressible in R5RS.

I think most implementors are going to dislike it because it
means they have to treat exactness as a bit independent from
the representation format.  "inexact" would no longer mean
"float format" if it had to be possible to provide accurate ops
on inexact numbers and have them give arbitrarily precise
inexact results.  I think that this would be a step forward
in terms of letting programmers say what they mean, but it
would almost certainly slow mathematics down (even so-called
"fast" operations) in every scheme where it was implemented.

But honestly, I think that we're not really going to have an
adequate solution for this problem until the precision to
which each number is known is part of the semantics of the
language.  Not just a bit to say whether that precision is
"infinite" or not.

The idea of inexact booleans keeps coming up, because they are
the correct result of a comparison of inexact numbers. But as
others here have said, you can't really have inexact control
flow, which inexact booleans imply.  One response is to keep
track of where control flow is based on an inexact expression,
and coerce results from such expressions to inexact, thus
enforcing a more complete contagion of inexactness across
expressions.  And this is a more consistent and disciplined
approach to inexactness than we have now.

But this has disturbing implications that I think most people
aren't ready to embrace; namely, inexact strings and symbols.
These entities are part of a rigorous theory of exactness,
but I don't think people are willing to have such entities
in their computing languages at this time.  There seem to be
no pressing engineering problem that they solve in a way
that people find satisfactory.

				Bear