Setting errno to EDOM required when -0.0 returned from sqrt(-0.0)?
Jun Woong
given argument and sets errno to EDOM if a negative value is given as
the argument. For this, the rationale says that an implementation
which wants to conform to IEC 60559 so to return -0.0 for sqrt(-0.0)
can exploit the escape hatch named "the domain error."
My question is: is an implementation required to cause the domain
error when it'd like to return the negative zero for sqrt(-0.0)? I
see nothing stopping doing the same thing with no domain error
occurred if the implementation treats -0.0 as equal to (positive)
zero or does it inconsistently depending on the context.
Is the wording in the rationale given to allow for an implementation
where the negative zero is treated as "negative" for other math
functions consistently (if appropriate)?
Thanks in advance.
--
Jun, Woong (woong at icu.ac.kr)
Samsung Electronics Co., Ltd.
``All opinions expressed are mine, and do not represent
the official opinions of any organization.''
Jun Woong
> The sqrt() function calculates the non-negative square root of the
> given argument and sets errno to EDOM if a negative value is given as
> the argument. For this, the rationale says that an implementation
> which wants to conform to IEC 60559 so to return -0.0 for sqrt(-0.0)
> can exploit the escape hatch named "the domain error."
>
After reading my past question on the negative zero and the answers
for it,
http://groups.google.com/group/comp.std.c/browse_frm/thread/eeaa6c7d4bdbd2f1
I think that the wording given in the Rationale for sqrt(-0) is
inappropriate and thus should have been dropped. As I stated in my
previous posting, it says that an implementation that wants to
return -0.0 for sqrt(-0.0) can take advantage of the domain error
as the escape hatch, since setting errno to EDOM allows sqrt() to
return an i-d result.
Because an implementation is not required to treat the negative
zero consistently in every context, it is not impossible to make
the domain error occurred for sqrt(-0.0), which implies -0.0 is
treated as negative but why? On the contrary, it seems more
consistent to treat -0.0 equal to 0 (except for some cases like
copysign), so return the negative zero as the result with no error
reported.
Douglas A. Gwyn
news:8677d967-ef73-4239...@c19g2000prf.googlegroups.com...
> I think that the wording given in the Rationale for sqrt(-0) is
> inappropriate and thus should have been dropped. As I stated in my
> previous posting, it says that an implementation that wants to
> return -0.0 for sqrt(-0.0) can take advantage of the domain error
> as the escape hatch, since setting errno to EDOM allows sqrt() to
> return an i-d result.
I think the Rationale is correct, since any value can be returned
along with errno==EDOM (as one form of undefined behavior,
perhaps); however, this "escape hatch" should not be
recommended practice.
> Because an implementation is not required to treat the negative
> zero consistently in every context, it is not impossible to make
> the domain error occurred for sqrt(-0.0), which implies -0.0 is
> treated as negative but why? On the contrary, it seems more
> consistent to treat -0.0 equal to 0 (except for some cases like
> copysign), so return the negative zero as the result with no error
> reported.
Are you sure that unary minus applied to the double constant zero
produces a "minus zero" representation? For non-IEEE/IEC f.p.
platforms it normally produces a plain ("plus") zero. As to what
"should" happen, if the implementation claims IEEE/IEC f.p.
conformance then there are IEEE/IEC specifications for the
behavior. Since I don't have a copy of the IEEE/IEC f.p. spec
at hand, I don't know what they say about sqrt(MINUS_ZERO)
where the sign is taken into account; but I think mathematically it
would be silly to require the result to be MINUS_ZERO.
Jun Woong
> "Jun Woong" <wo...@icu.ac.kr> wrote in message
>
> news:8677d967-ef73-4239...@c19g2000prf.googlegroups.com...
>
> > I think that the wording given in the Rationale for sqrt(-0) is
> > inappropriate and thus should have been dropped. As I stated in my
> > previous posting, it says that an implementation that wants to
> > return -0.0 for sqrt(-0.0) can take advantage of the domain error
> > as the escape hatch, since setting errno to EDOM allows sqrt() to
> > return an i-d result.
>
> I think the Rationale is correct, since any value can be returned
> along with errno==EDOM (as one form of undefined behavior,
> perhaps); however, this "escape hatch" should not be
> recommended practice.
>
I doubt you got my point correctly. I wasn't talking about its
correctness. My point is:
Because the C Standard does not prohibit the negative zero from
behaving in an inconsistent way, it is not necessary for the
Rationale to give such an ill advice; a conforming implementation
can, if it wants, return the negative zero for sqrt(negative zero)
without setting errno to EDOM.
> > Because an implementation is not required to treat the negative
> > zero consistently in every context, it is not impossible to make
> > the domain error occurred for sqrt(-0.0), which implies -0.0 is
> > treated as negative but why? On the contrary, it seems more
> > consistent to treat -0.0 equal to 0 (except for some cases like
> > copysign), so return the negative zero as the result with no error
> > reported.
>
> Are you sure that unary minus applied to the double constant zero
> produces a "minus zero" representation?
I didn't mean the C notation by sqrt(-0.0). Maybe I should have
written "sqrt(x) where x contains the negative zero."
> For non-IEEE/IEC f.p.
> platforms it normally produces a plain ("plus") zero. As to what
> "should" happen, if the implementation claims IEEE/IEC f.p.
> conformance then there are IEEE/IEC specifications for the
> behavior. Since I don't have a copy of the IEEE/IEC f.p. spec
> at hand, I don't know what they say about sqrt(MINUS_ZERO)
> where the sign is taken into account; but I think mathematically it
> would be silly to require the result to be MINUS_ZERO.
Agreed. IIRC, IEEE 754 requires it be a normal (positive) zero. The
arithmetic operations which show a different behavior when the
negative zero given include dividing a non-zero value by a zero and
the copysign function.
Fred J. Tydeman
> Agreed. IIRC, IEEE 754 requires it be a normal (positive) zero. The
> arithmetic operations which show a different behavior when the
> negative zero given include dividing a non-zero value by a zero and
> the copysign function.
Wrong. IEEE-754 in section 5.2 Square Root requires sqrt(-0.) to be -0.
---
Fred J. Tydeman Tydeman Consulting
tyd...@tybor.com Testing, numerics, programming
+1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.
santosh
> "Fred J. Tydeman" <tyde...@tybor.com> wrote:
>> On Mon, 7 Jul 2008 01:18:34 UTC, Jun Woong <wo...@icu.ac.kr> wrote:
>> > Agreed. IIRC, IEEE 754 requires it be a normal (positive) zero. The
>> > arithmetic operations which show a different behavior when the
>> > negative zero given include dividing a non-zero value by a zero and
>> > the copysign function.
>>
>> Wrong. IEEE-754 in section 5.2 Square Root requires sqrt(-0.) to be
>> -0.
>>
>
> You're right. I should have been more cautious. I forgot Prof.
> Kahan said the sqrt function is one of the important places where
> keeping the sign of zero is important even though I don't know how
> much it's worth compared to complexity it adds.
>
> That does not, however, makes the point of the wording in the
> Rationale meaningful. The negative zero is not negative. No reason
> for the sqrt function to be required to set errno to EDOM in order
> to return it.
>
> BTW, moving to C99, I don't see any techinical or editorial
> reason to change "negative" to "less than zero" in the description
> for the sqrt function, keeping the same wording in the description
> for the log function.
The beauty of Google Groups (TM) Beta. Five identical posts. :-)
Jun Woong
>
> Wrong. IEEE-754 in section 5.2 Square Root requires sqrt(-0.) to be -0.
>
You're right. I forgot Prof. Kahan said the sqrt function is one of
the important places where keeping the sign of zero is important even
though I don't know how much it's worth compared to complexity it
adds.
That does not, however, makes the point of the wording in the
Rationale meaningful. The negative zero is not negative. No reason
for the sqrt function to be required to set errno to EDOM in order
to return it.
BTW, moving to C99, I don't see any techinical or editorial
reason to change "negative" to "less than zero" in the description
for the sqrt function, keeping the same wording in the description
for the log function.
santosh
> "Fred J. Tydeman" <tyde...@tybor.com> wrote:
> [...]
>>
>> Wrong. IEEE-754 in section 5.2 Square Root requires sqrt(-0.) to be
>> -0.
>>
>
> You're right. [ ... ]
We get it, we get it!
Jun Woong
submitted several times. I've asked Google to delete them except the
recent one, which might not work for all usenet servers. My apologies
if my duplicated messages bother you.