On Thu, 20 Oct 2005, Marcin 'Qrczak' Kowalczyk wrote:

> I disagree. The problem is that R5RS tries to describe it as one of
> two fields of a number, the other being its value - while in reality
> it's a predicate about the representation of the value, not
> independently settable.

Well, as you said, you disagree.  I don't think there's a non-repetitive
argument to be made, but I consider it to be different than you.

> Suppose we have two flonums tagged as exact. You divide them, and the
> result is not a finite binary fraction, so the implementation can't
> use the same representation for the result. What should it do?
>
> a) Represent it in a flonum tagged as inexact.
> b) Represent it as an exact ratio of two integers.

c) consult settings or dynamic variables to see what the program
   or user wants it to do.
d) give an exact result if the representation width needed for
   it is allowed, otherwise give an inexact result with the
   maximum representation width allowed by the current settings.
e) store a promise rather than an explicit numeric representation,
   allowing the user to decide later how much precision they want
   and propagating demands for precision into the branches of the
   promise as necessary.
f) ... something else you haven't thought of.
g) ... something else *I* haven't thought of.

Don't present a false dilemma, when there are many many possible
choices.

> I claim that the practical utility of numbers represented as fixnums,
> bignums or ratios but tagged as inexact is close to zero, and similarly
> for flonums tagged as exact.

I claim that this is not so.

> And that's good, it's not orthogonal. If it was, using different
> representations for numbers of the same value and the same precision
> would be redundant. R5RS even specifies that such numbers would be
> indistinguishable (even more: the precision is not compared but the
> exactness only, which is wrong if there are several possible amounts
> of inexact precision, and SRFI-77 fixes that).

Yes.  They *should* be indistinguishable.  The abstraction R5RS
describes is numbers, not representations.   SRFI-77 messes that up
and breaks a proper abstraction barrier.

> I presume then that since (factorial 100) preserves all 158 digits,
> you want (factorial 100.0) to produce a result with 158 digits but
> tagged as inexact, right?

If there is a presumption in effect that inexact numbers in source
whose precision isn't given explicitly are known to 158 digits or more,
then yes, I'd want the result to 158 digits.  If the presumption is
that inexact numbers in source whose precision isn't given explicitly
are known to just 20 digits, then I'd want the first 20 digits and
the magnitude.

Remember that R5RS' full numeric syntax, which virtually nobody takes
full advantage of, allows explicitly *telling* the system how much
precision a number has.  When we write 2.00000# we're telling our
scheme that we know this value to only 6 significant figures; it
could save time and increase cache hits by using single-precision
floats for subsequent calculations.  When we tell it we know something
to 36 decimals, say by typing 100.000000000000000000000000000000000#,
I think it is best to use a flonum format that preserves at least
36-decimal accuracy until some calculation gives a less-known result,
or else report an implementation limitation if flonum representation
of at least that accuracy is not supported.

>> should exactness remain part of the standard?

> It should be described as a property which can be inferred from the
> representation, not as an independently settable field.

Well, as you said -- we disagree.  If that were all it was, I'd
be in favor of just chucking it entirely because if that's all
it is, then it's plainly useless (or redundant).

> Are there any implementations where it is?

MITScheme, for one.  There are probably a few others.

> Indeed. If everybody ignores something in the standard, it's should
> raise suspections that the standard has made an unfortunate decision.

Or at the very least a sign that many implementors have different
aims and goals and purposes than the members of the standards
committee. Which may be the same thing.

Sigh.  Numeric issues, and the ubiquity and limitations of this
representation-type shortcut, were one of several reasons I started
working on my own lisp (the other big ones were character and string
handling and first-order functions).  If R6RS adopts the proposals
of SRFI-77, that will just be another point of divergence.

					Bear