[r6rs-discuss] Re: r6rs-discuss Digest, Vol 3, Issue 70

[Jason Orendorff]

On 11/22/06, "Peter Gavin" <pgavin at gmail.com> wrote:
> On 11/20/06, William D Clinger <will at ccs.neu.edu> wrote:
> > Sounds good to me.  If anyone wants to object to dropping
> > that notation, now (i.e. before the next draft comes out)
> > might be a good time.
>
> I think it should be kept.  I always figured that it was possible to
> keep a precision field with inexact numbers, which could be used in
> later computations.  [...]

It is possible, but you can't have it all...

The most common approach I've heard of is "interval arithmetic".
Haven't tried it myself; I hear some people like it and some don't.
It's possible to get a false positive--the error terms can pile up and
you get a result with a very large error, even though your algorithm
is not actually that sloppy.  This happens because interval arithmetic
is pessimistic.  Two examples: (+ x (- x)) is not an exact zero; and
(* x (+ y z)) is different from (+ (* x y) (* x z)) when negative
numbers are involved.  Another problem is that division by zero is a
lot easier to stumble upon than in floating-point math.

The concept of "significant figures" might be less prone to false
positives, but I don't think it provides any strong numerical
guarantees at all.  That is, I think it's vulnerable to false
negatives.  I have a feeling numerical experts would see it as rather
naive.  (Personally I've had only good experiences with significant
figures, but then I've only used them on paper, where--on a good
day--common sense is never further away than arm's length.)

I wouldn't bet on either of these making it into Scheme any time soon.

> I think its also important to note that (IMO, anyway) the correct way
> to interpret an inexact number with no hashes should be with hashes
> extending following the last digit, to infinity.

(Nitpick:  only one hash would be necessary.)

Now it sounds like you're arguing that the default interpretation of
5.25 should be something other than IEEE floating-point.  I definitely
disagree with that.

What you're saying here requires, for example, that 1.0 be treated as
very inexact indeed:  (* 1.0 3.14159) => 3.1#.  But I think constants
are very often used in programs to mean "I want a flonum result", as
in (- (expt b 2.0) (* 4.0 a c)).  Should I write 4.0000000000000000
instead?  Perhaps (real->flonum 4) is the right thing here; anyway
this kind of change would break a lot of code.

> One last thing,  I think the reason the syntax isn't being found in
> the public code repositories is because people try not to store data
> in code; it's usually stored in external files.

I imagine an even more important factor is that this syntax doesn't
actually *do* anything.  You won't see it used until it does something
useful, right?

I think the 15## syntax should be dropped.

-j