From: Raymond Toy on
>>>>> "Raymond" == Raymond Wiker <raw(a)RAWMBP-2.local> writes:

Raymond> "Captain Obvious" <udodenko(a)users.sourceforge.net>
Raymond> writes:
RT> Well, the difference is way bigger than I would have expected.
RT> In fact, I know that sbcl computes (expt 2 #c(2d0 0d0)) as
RT> (exp (* #c(2d0 0d0) (log 2))). That (log 2) returns a
RT> single-float as expected and required. This is what causes
RT> the loss of accuracy.
>>
>> Well, if you want to work at double accuracy, why don't you
>> explicitly specify 2 as double-float?
>>
CL-USER> (expt 2 #c(2.0d0 0.0d0))
>> #C(4.000000015237235d0 0.0d0)
CL-USER> (expt 2.0d0 #c(2.0d0 0.0d0))
>> #C(4.0d0 0.0d0)
>>
>> So it is not a practical issue. If you want consistent
>> accuracy, make it consistent on your side.

RW> I'm guessing that he expects the rule of floating-point
RW> contagion to work with *all* standard Lisp numerical

If "he" means me, then yes, I do kind of expect that, but we the spec
doesn't say this is required (but neither does it say it's forbidden).

RW> functions... it makes just as much sense to treat the 10 in
RW> (log 10 10d0) as 10s0 as it does if you tried (+ 10 10d0)
RW> (i.e, not much).

I didn't follow this example. There is a slight difference since
(log 10 10d0) is (/ (log 10) (log 10d0)), so there's a "hidden"
computation here.

Ray




From: vanekl on
Raymond Toy wrote:
>>>>>> "Barry" == Barry Margolin <barmar(a)alum.mit.edu> writes:
>
> Barry> In article
> >> > What makes you think the origial 2.0 and 3.0 are exact? They
> >> > came from
> >>
> >> On the other hand, what makes you think they weren't exact?
> >> Any epsilon you want to ascribe is outside of the computation.
>
> Barry> When using transcendental functions, exact numbers are
> Barry> extremely rare. Except for special cases, all their
> Barry> results are irrational, so the floating point value will be
> Barry> an approximation.
>
> Certainly, but saying the result of a transcendental function is a
> floating-point approximation doesn't give you freedom to return any
> value. There's a certain expectation that some care is taken and the
> value is as close to the true value as reasonably possible.
>
> Perhaps I'm being unreasonable. :-)
>
> I agree that the spec doesn't explicitly say what the accuracy of
> (expt 2 #c(-2d0 -1d0)) should be. It would be nice if the more
> accurate value were returned, since that doesn't violate the spec,
> AFAICT.
>
> Ray

In its essence, this is a "Worse is Better" (unwinnable) debate.
http://www.jwz.org/doc/worse-is-better.html


From: Robert Dodier on
On May 11, 2:01 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote:

> Every floating point number is actually a representation
> of a range of numbers.

That's an interesting theory, but it doesn't have any support
in the CLHS, which says, "A float is a mathematical rational".

> What makes you think the origial 2.0 and 3.0 are exact? They came from
> another compuation, that may have had roundoff error of its own. You
> happen to know a priori that you typed "2.0d0", but it could just as
> easily have been "2.00000000000000000987", and the fraction got lost.
> If you start off with an approximation, you certainly can't expect to
> get the exact answer.

It seems silly for the implementation to throw away accuracy
that might have been present in the arguments, but, sadly,
the CLHS does indeed allow that. "Computations with floats are
only approximate", the spec says; in the absence of any
general or specific requirement on that approximation, pretty
much anything could be returned by a purportedly-conforming
implementation.

FWIW

Robert Dodier