Here's another question about the standard...
According to the page for IMAGPART:
realpart and imagpart return the real and imaginary parts of number
respectively. If number is real, then realpart returns number and
imagpart returns (* 0 number), which has the effect that the imaginary
part of a rational is 0 and that of a float is a floating-point
zero of the same format.
This multiply by zero trick is cute, but what if the implementation
has a negative zero? Is it the intent that
(imagpart -17.0) ==> -0.0
even though
(complex -17.0) ==> #c(-17.0 0.0) ?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Here's another question about the standard...
>
> According to the page for IMAGPART:
>
> realpart and imagpart return the real and imaginary parts of number
> respectively. If number is real, then realpart returns number and
> imagpart returns (* 0 number), which has the effect that the imaginary
> part of a rational is 0 and that of a float is a floating-point
> zero of the same format.
>
> This multiply by zero trick is cute, but what if the implementation
> has a negative zero? Is it the intent that
>
> (imagpart -17.0) ==> -0.0
>
> even though
>
> (complex -17.0) ==> #c(-17.0 0.0) ?
I tend to steer clear of floats because I know just enough about them
to fear them, so take my question with more than the usual level of
doubt you might give my questions/comments, but is it in fact the case
that (* 0 -17.0) is supposed to yield -0.0? I thought -0.0 was only
supposed to come back in limit situations where the magnitude has
become unrepresentably small but the sign is still known to be
negative rather than 0 [none] or positive... I didn't think it was
something that would just appear in garden variety situations like
your example. If what I'm thinking is right, then imagpart should
be returning 0.0, not -0.0. Then again, as I said, I'm most definitely
NOT a floating point expert. I just take what the hardware gives me.
Kent M Pitman wrote:
> I tend to steer clear of floats because I know just enough about them
> to fear them, so take my question with more than the usual level of
> doubt you might give my questions/comments, but is it in fact the case
> that (* 0 -17.0) is supposed to yield -0.0?
If I understand the IEEE FP spec correctly, multiplication is supposed
to produce a value whose sign is the xor of the signs of the arguments.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Kent M Pitman wrote:
>
> > I tend to steer clear of floats because I know just enough about them
> > to fear them, so take my question with more than the usual level of
> > doubt you might give my questions/comments, but is it in fact the case
> > that (* 0 -17.0) is supposed to yield -0.0?
>
> If I understand the IEEE FP spec correctly, multiplication is supposed
> to produce a value whose sign is the xor of the signs of the arguments.
If I were you, then, I would ask Steele. He has access to the people
who really understand floating point and could resolve this both from
a CL spec point of view and an IEEE point of view. If you don't know
how to reach him, I can put you in touch.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>"Paul F. Dietz" <·····@dls.net> writes:
>
>> Kent M Pitman wrote:
>>
>> > I tend to steer clear of floats because I know just enough about them
>> > to fear them, so take my question with more than the usual level of
>> > doubt you might give my questions/comments, but is it in fact the case
>> > that (* 0 -17.0) is supposed to yield -0.0?
>>
>> If I understand the IEEE FP spec correctly, multiplication is supposed
>> to produce a value whose sign is the xor of the signs of the arguments.
This is what multiplication is supposed to do in IEEE arithmetic, but the
current sbcl on darwin doesn't follow it:
* (imagpart 5)
0
* (imagpart 5.0)
0.0
* (imagpart -5.0)
0.0
* (imagpart #c(5.0 -0.0))
-0.0
Perhaps the spec needs to be clarified if the intent were just to have a zero
of the same type as the real number instead of actually computing that zero
by multiplication.
I hadn't realized that CL didn't allow complex numbers with one component
a float and the other a rational.
I had put together a rather haphazard document that suggests how R*RS Scheme
may be reconciled with IEEE 754 arithmetic, it's now available via Google at
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&selm=bhes52%24nq0%40arthur.cs.purdue.edu
Among other things, this document argues in the Scheme context that
(* 0 anything) => 0
where 0 here means exact 0 (rational 0 in CL terminology). The
recommendations in this document will be followed by the next version of
Gambit-C.
Brad Lucier