[JW] negative zero is negative?
Jun Woong
And when it says "zero," does it include the negative zero?
I surmise the answer to both questions is "yes." But some
implementations do not agree with me.
Suppose that an implementation supports the representation for the
fp negative zero and the unary minus operator applied to 0.0 on the
implementation produces it.
#include <math.h>
#include <errno.h>
#include <assert.h>
#include <stdio.h>
int main(void)
{
double d = 0;
d = -d; /* assumes the negative zero assigned */
if (d == 0.0)
puts("same"); /* should prints out "same" */
errno = 0;
log(d);
assert(errno == EDOM); /* should success? */
errno = 0;
sqrt(d);
assert(errno != EDOM); /* should success? */
return 0;
}
The negative zero compares equal to the normal zero, so this program
should print out "same". And if the negative zero is considered
negative, the call to log() above should set errno to EDOM due to the
specification:
5.12.6.7p2
A domain error occurs if the argument is negative.
while the call to sqrt() should not if the negative zero is considered
zero:
5.12.7.5
A domain error occurs if the argument is less than zero.
Note that C90 has the same wording mentioning "negative" for both and
C99 has changed it for sqrt() as you see above. I think this change
means to allow the negative zero as a sqrt()'s argument with
disallowing as a log()'s argument.
Is this interpretation correct? And any implementation which meets the
above assumptions but fails when encountering one of the above calls
to assert() non-conforming? Or the difference on the wording for log()
and sqrt() is not a requirement, but just a intent?
Thanks in advance.
--
Jun, Woong (woong at icu.ac.kr)
Information and Communications Univ.
Fred J. Tydeman
>
> When the standard says "negative," does it include the negative zero?
In general, no.
> And when it says "zero," does it include the negative zero?
In general, yes.
C99 7.12.6.7p2 has the above sentence, along with:
A range error may occur is the argument is zero.
A negative zero is treated as zero, not negative, for log(x).
See also F.9.3.7 which cover both negative zero and x < 0.
> while the call to sqrt() should not if the negative zero is considered
> zero:
>
> 5.12.7.5
> A domain error occurs if the argument is less than zero.
>
> Note that C90 has the same wording mentioning "negative" for both and
> C99 has changed it for sqrt() as you see above. I think this change
> means to allow the negative zero as a sqrt()'s argument with
> disallowing as a log()'s argument.
>
> Is this interpretation correct?
No.
> And any implementation which meets the
> above assumptions but fails when encountering one of the above calls
> to assert() non-conforming? Or the difference on the wording for log()
> and sqrt() is not a requirement, but just a intent?
One of the "exceptions" on 'negative zero' is for signbit().
Here, it is negative, while 'positive zero' is positive.
This is called out in footnote 200 (C99+TC1 numbering).
---
Fred J. Tydeman Tydeman Consulting
tyd...@tybor.com Testing, numerics, programming
+1 (775) 358-9748 Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.
pete
>
> When the standard says "negative," does it include the negative zero?
I don't think so.
"negative zero" refers to the sign of the representation.
In all other contexts that I can think of right now,
"negative" means "less than zero", which negative zero isn't.
--
pete
Jun Woong
"Fred J. Tydeman" <tyd...@tybor.com> wrote in message news:41C6392D...@tybor.com...
> >
> > When the standard says "negative," does it include the negative zero?
>
> In general, no.
>
> > And when it says "zero," does it include the negative zero?
>
> In general, yes.
So the principle is that the negative zero is zero except when the
text treats it explicitly in a distinguishable way from the positive
zero.
[...]
> > while the call to sqrt() should not if the negative zero is considered
> > zero:
> >
> > 5.12.7.5
> > A domain error occurs if the argument is less than zero.
> >
> > Note that C90 has the same wording mentioning "negative" for both and
> > C99 has changed it for sqrt() as you see above. I think this change
> > means to allow the negative zero as a sqrt()'s argument with
> > disallowing as a log()'s argument.
> >
> > Is this interpretation correct?
>
> No.
>
Then what is the difference the specifications for log() and sqrt()
show for? It has nothing to do with the negative zero; "negative" just
has the same meaning with "less than zero" as an ordinary English
dictionary says, doesn't it? Why did the wording for sqrt() change
from C90? After my previous posting I found that log()/log10 and
log2() has different wordings to specify the same behavior:
log(): A domain error occurs if the argument is negative.
log10(): A domain error occurs if the argument is negative.
log2(): A domain error occurs if the argument is less than zero.
What's benefit? In the fp area, the standard uses many different terms
for the same notion or behavior (e.g., rounding mode), which sometimes
can cause unnecessary confusion (like what I had) and makes search for
the text difficult.
> > And any implementation which meets the
> > above assumptions but fails when encountering one of the above calls
> > to assert() non-conforming? Or the difference on the wording for log()
> > and sqrt() is not a requirement, but just a intent?
>
> One of the "exceptions" on 'negative zero' is for signbit().
And copysign(). These two seem to be only the exceptional cases where
the negative zero treated differently from the positive zero.
Jun Woong
"pete" <pfi...@mindspring.com> wrote in message news:41C6C8...@mindspring.com...
Yes, you are right and it agrees with the ordinary English dictionary.
What confused me was that the wording for log() changed from C90. I
thought it had a reason and guessed it was what I asked in my previous
posting, which was wrong.
Thanks.
Jun Woong
"Jun Woong" <wo...@icu.ac.kr> wrote in message news:cq8eq7$s59$1...@news1.kornet.net...
[...]
> What confused me was that the wording for log() changed from C90.
sqrt()'s wording changed, not log()'s. Sorry.
Francis Glassborow
writes
>So the principle is that the negative zero is zero except when the
>text treats it explicitly in a distinguishable way from the positive
>zero.
Which means that if you test the sign bit, it will test as negative.
However, I think this is one of the cases where the process is allowed
to arbitrarily change the representation on no more than a whim.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
James Kuyper
...
> Then what is the difference the specifications for log() and sqrt()
> show for? It has nothing to do with the negative zero; "negative" just
> has the same meaning with "less than zero" as an ordinary English
No, the phrase "negative zero" would never occur in ordinary English,
being apparently a contradiction in terms. It is a piece of specialized
jargon, referring to one of the two representations of 0 that can be
made in sign-magnitude systems. Both representations represent the same
value, 0, and -0<0 is false, just as +0>0 is false.
> ... Why did the wording for sqrt() change
> from C90? After my previous posting I found that log()/log10 and
> log2() has different wordings to specify the same behavior:
>
> log(): A domain error occurs if the argument is negative.
> log10(): A domain error occurs if the argument is negative.
> log2(): A domain error occurs if the argument is less than zero.
I doubt that the difference in phrasing was intended to convey a
difference in meaning.
Jun Woong
"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message news:cApYOZaA...@robinton.demon.co.uk...
> In article <cq8eh2$s3q$1...@news1.kornet.net>, Jun Woong <wo...@icu.ac.kr>
> writes
> >So the principle is that the negative zero is zero except when the
> >text treats it explicitly in a distinguishable way from the positive
> >zero.
>
> Which means that if you test the sign bit, it will test as negative.
> However, I think this is one of the cases where the process is allowed
> to arbitrarily change the representation on no more than a whim.
>
Each byte which constitutes the object of the fp type is an object and
has the *value* we call "object representation". The standard does not
impose much restriction on an implementation's dealing with the
negative zero. But I don't think liberty of an implementation can go
too far.
In the case of signbit(), it seems that an implementation is allowed
to change the representation because it is not a function but a macro,
even if it's not the intent.
Chris Croughton
<kuy...@saicmodis.com> wrote:
> No, the phrase "negative zero" would never occur in ordinary English,
> being apparently a contradiction in terms. It is a piece of specialized
> jargon, referring to one of the two representations of 0 that can be
> made in sign-magnitude systems. Both representations represent the same
> value, 0, and -0<0 is false, just as +0>0 is false.
It does occur on my car's dashboard (and that of many other modern cars)
as a temperature, meaning "it's below zero but not enough to make it -1",
so it certainly does occur now in "ordinary English" for a significant
chunk of the population.
Chris C
Jun Woong
"James Kuyper" <kuy...@saicmodis.com> wrote in message news:41C83D5C...@saicmodis.com...
> Jun Woong wrote:
[...]
>
> > ... Why did the wording for sqrt() change
> > from C90? After my previous posting I found that log()/log10 and
> > log2() has different wordings to specify the same behavior:
> >
> > log(): A domain error occurs if the argument is negative.
> > log10(): A domain error occurs if the argument is negative.
> > log2(): A domain error occurs if the argument is less than zero.
>
> I doubt that the difference in phrasing was intended to convey a
> difference in meaning.
The change the committee made from C90 made me suspect the difference
was meaningful.
I wonder why the committee has chagned it if not trying to make a
different between them. C90's wording was much clearer.
Jun Woong
"Chris Croughton" <ch...@keristor.net> wrote in message news:slrncsglg6...@ccserver.keris.net...
The negative zero which you have on your car's dashboard and so a
significant chunk of the population knows have a different meaning
from the one James Kuyper pointed out. As you said, yours is actually
*below* zero while the negative zero in the standard should compare
equal to zero.
Douglas A. Gwyn
> ... the negative zero in the standard should compare
> equal to zero.
I don't have a copy of the standard with me on vacation,
but for *integer* types the intent is that all
representations of the value zero shall compare equal
even though that means a normalization step is necessary
(on such systems). I'm pretty sure we decided that -0
is not allowed to test as negative; it makes just as
much sense as +0 testing as positive, which is not
allowed.
Gabriel Dos Reis
| Jun Woong wrote:
| ...
| > Then what is the difference the specifications for log() and sqrt()
| > show for? It has nothing to do with the negative zero; "negative" just
| > has the same meaning with "less than zero" as an ordinary English
| > dictionary says, doesn't it? ...
|
| No, the phrase "negative zero" would never occur in ordinary English,
| being apparently a contradiction in terms.
Probably true, but irrelevant. The C standard is not written in
ordinary English -- whatever that means. A "negative zero" is a is
value that compares equal to zero, but with a representation that has
the sign bit set. It is one of the most controversial invention if
IEEE-754, regretably carried on by C99.
-- Gaby
Gabriel Dos Reis
yes, but it represents a limit value zero from above.
No wonder why it was thought to be a great invention :-(
-- Gaby
Douglas A. Gwyn
> Probably true, but irrelevant. The C standard is not written in
> ordinary English -- whatever that means. A "negative zero" is a is
> value that compares equal to zero, but with a representation that has
> the sign bit set. It is one of the most controversial invention if
> IEEE-754, regretably carried on by C99.
The C standard has to accommodate the most natural representations
of actual implementations. In fact even in the original 1989 C
standard we were careful to allow negative zero for integer reps.
For C99 we specify the additional details that IEEE/IEC f.p.
implementations need to know, which includes treatment of
negative zero, denorms, and infinities. Implementations that
don't advertise IEEE/IEC f.p. compliance don't need to deal with
these.
Jun Woong
"Gabriel Dos Reis" <g...@integrable-solutions.net> wrote in message news:m3ekhhf...@uniton.integrable-solutions.net...
> James Kuyper <kuy...@saicmodis.com> writes:
>
> Probably true, but irrelevant.
Not true. If the standard or ISO 2382-1 it refers to does not define
a term, its readers are guided to refer to an ordinary English
dictionary according to ISO/IEC Directives.
C99 uese it without defining in a f.p. representation context; it's
defined only in an integer representation context. In addition to it,
there is usage of other terms related to the f.p. arithmetic which
should be tidied up during the next revision of the standard.
Gabriel Dos Reis
| "Gabriel Dos Reis" <g...@integrable-solutions.net> wrote in message news:m3ekhhf...@uniton.integrable-solutions.net...
| > James Kuyper <kuy...@saicmodis.com> writes:
| >
| > Probably true, but irrelevant.
|
| Not true. If the standard or ISO 2382-1 it refers to does not define
| a term, its readers are guided to refer to an ordinary English
| dictionary according to ISO/IEC Directives.
But then you end up with something that is not just ordinary English;
don't you?
| C99 uese it without defining in a f.p. representation context; it's
| defined only in an integer representation context. In addition to it,
| there is usage of other terms related to the f.p. arithmetic which
| should be tidied up during the next revision of the standard.
|
|
| --
| Jun, Woong (woong at icu.ac.kr)
| Information and Communications Univ.
|
|
|
--
Gabriel Dos Reis
g...@integrable-solutions.net
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > Probably true, but irrelevant. The C standard is not written in
| > ordinary English -- whatever that means. A "negative zero" is a is
| > value that compares equal to zero, but with a representation that has
| > the sign bit set. It is one of the most controversial invention if
| > IEEE-754, regretably carried on by C99.
|
| The C standard has to accommodate the most natural representations
| of actual implementations. In fact even in the original 1989 C
| standard we were careful to allow negative zero for integer reps.
I see a difference between allowing, and actively advertising.
In particular, it could have just postulate an operational normalized
form of a zero: They all compare equal -- be they unsigned, signed or
without sign.
| For C99 we specify the additional details that IEEE/IEC f.p.
| implementations need to know, which includes treatment of
| negative zero, denorms, and infinities. Implementations that
| don't advertise IEEE/IEC f.p. compliance don't need to deal with
| these.
treatments of infinities and denorms is not what I was specifically
talking about. But, definitely, we could debate also on the
inventions in the area of complex numbers with inifities, NaNs -- that
were not part of IEEE-754 :-)
-- Gaby
Antoine Leca
>> Probably true, but irrelevant.
>
> Not true.
Please precise: Gaby was wrong with his "probably" and James was wrong also,
or you are arguing against the "irrelevant"?
> If the standard or ISO 2382-1 it refers to does not define
> a term,
"If". As we say in France, "With ifs, one can put Paris into a bottle."
The standard happens to define explicitely "negative zero" when it talks
about integers (6.2.6.2 uses italic type), and James did care to give the
definition.
> C99 uese it without defining in a f.p. representation context;
Is it not a normative reference to IEC 60559:1989 in clause 2?
Does this standard forget to define it?
Note that the normative reference applies even when the implementation does
not actually support the IEC_559 (appendix F) arithmetic, or similarly it
applies even when the conforming program does not depend upon the
__STC_IEC_559__ feature macro.
You might have a point if something that could could be named /negative
zero/ existed which were not the IEC 60559 (born IEEE 754) thingy. However,
the only such thing known to exist is the integer negative zero, and it is
adequately covered. In f.p. context, I am not aware of other
interepretations; as such, I do not see any ambiguity here.
Antoine
Dik T. Winter
...
> A "negative zero" is a is
> value that compares equal to zero, but with a representation that has
> the sign bit set. It is one of the most controversial invention if
> IEEE-754, regretably carried on by C99.
The invention predates IEEE-754 by many years, think about 1-s complement
arithmetic.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jun Woong
"Antoine Leca" <ro...@localhost.gov> wrote in message news:41ca953f$0$29450$626a...@news.free.fr...
> En cqe0mp$rek$1...@news1.kornet.net, Jun Woong va escriure:
> >> Probably true, but irrelevant.
> >
> > Not true.
>
> Please precise: Gaby was wrong with his "probably" and James was wrong also,
> or you are arguing against the "irrelevant"?
It's against the "irrelevant."
>
> > If the standard or ISO 2382-1 it refers to does not define
> > a term,
>
> "If". As we say in France, "With ifs, one can put Paris into a bottle."
>
I should have said "when," not "if."
> The standard happens to define explicitely "negative zero" when it talks
> about integers (6.2.6.2 uses italic type), and James did care to give the
> definition.
I also pointed it out. But the definition 6.2.6.2 gives can't apply
to the f.p. context, can it?
>
> > C99 uese it without defining in a f.p. representation context;
>
> Is it not a normative reference to IEC 60559:1989 in clause 2?
The normative reference sloves no problem related to the definitions.
Clause 3:
[some terms are defined in clause 3 and others in italic type
through the standard]
Terms not defined in *this* International Standard are to be
interpreted according to ISO/IEC 2382-1. Mathematical symbols not
defined in *this* International Standard are to be interpreted
according to ISO 31.11.
This makes the following argument moot.
> Does this standard forget to define it?
>
> Note that the normative reference applies even when the implementation does
> not actually support the IEC_559 (appendix F) arithmetic, or similarly it
> applies even when the conforming program does not depend upon the
> __STC_IEC_559__ feature macro.
>
> You might have a point if something that could could be named /negative
> zero/ existed which were not the IEC 60559 (born IEEE 754) thingy. However,
> the only such thing known to exist is the integer negative zero, and it is
> adequately covered. In f.p. context, I am not aware of other
> interepretations; as such, I do not see any ambiguity here.
>
I'm not talking about ambiguity here. Following the strict
interpretation of the standard I showed so far the standard does not
define the term, "negative zero" in the f.p context. This is true even
if we can easily catch what the real intent is. So what James Kuyper
told about an ordinary English dictionary is relevant. That was my
point.
Jun Woong
"Gabriel Dos Reis" <g...@integrable-solutions.net> wrote in message news:m3r7lhe...@uniton.integrable-solutions.net...
> "Jun Woong" <wo...@icu.ac.kr> writes:
>
> | "Gabriel Dos Reis" <g...@integrable-solutions.net> wrote in message news:m3ekhhf...@uniton.integrable-solutions.net...
> | > James Kuyper <kuy...@saicmodis.com> writes:
> | >
> | > Probably true, but irrelevant.
> |
> | Not true. If the standard or ISO 2382-1 it refers to does not define
> | a term, its readers are guided to refer to an ordinary English
> | dictionary according to ISO/IEC Directives.
>
> But then you end up with something that is not just ordinary English;
> don't you?
>
I'm not arguing that the term in question should be interpreted
according to the definition an ordinary English dictionary gives.
What I was trying to say was you, because said "irrelevant", was
wrong. Following the strictest way to interpret the standard, a
technical document, this is the case where an English dictionary is
involved and it gives a wrong answer. So it should be fixed during the
next revision; okay, I admit this not a big problem. We know what the
real intent is.
Gabriel Dos Reis
| In article <m3ekhhf...@uniton.integrable-solutions.net> Gabriel Dos Reis <g...@integrable-solutions.net> writes:
| ...
| > A "negative zero" is a is
| > value that compares equal to zero, but with a representation that has
| > the sign bit set. It is one of the most controversial invention if
| > IEEE-754, regretably carried on by C99.
|
| The invention predates IEEE-754 by many years,
I know that arithmetic predates IEEE-754, just like many errors.
-- Gaby
Antoine Leca
> The normative reference sloves no problem related to the definitions.
>
> Clause 3:
> [some terms are defined in clause 3 and others in italic type
> through the standard]
> Terms not defined in *this* International Standard are to be
> interpreted according to ISO/IEC 2382-1. Mathematical symbols not
> defined in *this* International Standard are to be interpreted
> according to ISO 31.11.
I guess you are over-reading here.
The first sentense you quoted should be put in its context. The previous
sentense said that the definitions in this IS override anything else
(paraphrased). So I do not believe emphasis should be put on *this* in the
phrase above.
Furthermore, this kind of argument can lead to real nightmares. For example,
at first sight I noticed that 6.5.6p2 speaks about addition. Yet what is
defined is the + operator (read other subclauses), and the verbose text
below refer to the "sum". I do not know what say ISO/IEC 2382-1 at the
respect. I agree an English dictionnary will explain there are relationship
between these three concepts, yet they are not equated.
I am sure deep examinations might dig "better" (read worse if you want)
examples. I am also sure nobody get it wrong, as you noted.
> Following the strict
> interpretation of the standard I showed so far the standard does not
> define the term, "negative zero" in the f.p context.
Under your interpretation, should it? In other words, should all the
concepts in the standard receive a name?
My point was that the concept exist, since it is introduced by IEC 559.
Furthermore, you agree there is no ambiguity.
Also, the real need is not to define "negative zero" (only used once), but
rather the signedness or unsignedness of zero: there are much more
references to "positive zero", "unsigned zero", "signed zero". Which, as I
said, is a full by-product of IEC 559.
Antoine
Jun Woong
"Antoine Leca" <ro...@localhost.invalid> wrote in message news:41cb253b$0$15047$626a...@news.free.fr...
[...]
>
> I guess you are over-reading here.
>
You're straining the meaning of my words. I didn't mean to claim that
the readers of the standard should not refer to IEEE 754 to understand
the concept of "negative zero." What I was trying to say was that when
reading the standard, even if it's a technical document, a reference
to an ordinary English dictionary *is* relevant according to the
standard itself and ISO/IEC Directives.
You are absolutely free to help yourself by referring to other
documents to figure out some concepts occurred in the C standard, but
for the C standard to be complete in itself it should define technical
terms used or provide any *official* reference for them.
I admit the concept of "negative zero" is provided by IEEE 754, but
where does the C standard allow you to bring its definition from IEEE
754 and apply it to the C standard as if defined in the C standard?
Just because it's one of the normative references for the C standard,
which does not agree with ISO/IEC Directives say? The C standard
should have it defined officially in the f.p. context whether IEEE 754
has it or not. Admittedly it's not a big issue, so I said "during the
next revision," not "by submitting a DR." That is my point.
[...]
>
> My point was that the concept exist, since it is introduced by IEC 559.
> Furthermore, you agree there is no ambiguity.
>
I've never told that the concept doesn't exist. What I agree about "no
ambiguity" is the fact that the term defined in the integer context
does not apply to the f.p. context. I don't think that every piece of
its properties in the standard is clear-cut. Also note that I'm the
only person who asked about them.
> Also, the real need is not to define "negative zero" (only used once), but
> rather the signedness or unsignedness of zero: there are much more
> references to "positive zero", "unsigned zero", "signed zero". Which, as I
> said, is a full by-product of IEC 559.
>
Agreed. It'd better to specify the concept of the signedness of zero.
And all of those refereces and other similar problems need to be tided
up, I think.