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
Received on Wed Nov 22 2006 - 15:05:50 UTC