c99 says what about the number of digits in a zero exponent?

D

David Mathog

double dv=0.0;
printf("%e\n",dv);

prints this on a linux/gcc system:

0.000000e+00

Is the two digits in the exponent mandated or just something gcc does?
That is, does C99 also allow these:

0.000000e+0
0.000000e+000

?

Thanks,

David Mathog
 
J

jacob navia

Le 09/06/11 20:32, David Mathog a écrit :
double dv=0.0;
printf("%e\n",dv);

prints this on a linux/gcc system:

0.000000e+00

Is the two digits in the exponent mandated or just something gcc does?
That is, does C99 also allow these:

0.000000e+0
0.000000e+000

?

Thanks,

David Mathog

The standard says that at least 2 zeros should be printed, and as many
digits should be printed as necessary to represent the exponent.

lcc-win printf had 2 zeroes but users complained because Microsoft
writes three zeroes, so now lcc-win writes three zeroes as Microsoft.

The first of your examples with only one zero is not allowed by the
standard. At LEAST two digits of exponent should be printed.

The second is non-conforming, but it could be argued that it makes
the exponent "clearer"...

:)

jacob
 
D

David Mathog

The standard says that at least 2 zeros should be printed, and as many
digits should be printed as necessary to represent the exponent.

OK. (Odd choice though. Either allow just one, as one is enough for
many numbers, or require all that are needed [3 for doubles]. Why
require two digits?)

Does the standard say anything about the sign of the exponent? Could

printf("%e\n",0.0);

ever emit:

0.0000e-00

?

Thanks,

David Mathog
 
K

Keith Thompson

David Mathog said:
double dv=0.0;
printf("%e\n",dv);

prints this on a linux/gcc system:

0.000000e+00

Is the two digits in the exponent mandated or just something gcc does?
That is, does C99 also allow these:

0.000000e+0
0.000000e+000

?

C99 7.19.6.1p8:

The exponent always contains at least two digits, and only as
many more digits as necessary to represent the exponent. If
the value is zero, the exponent is zero.

You might want to grab a copy of
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.
 
J

jacob navia

Le 09/06/11 21:12, David Mathog a écrit :
Does the standard say anything about the sign of the exponent? Could

printf("%e\n",0.0);

ever emit:

0.0000e-00

The standard says "If the value is zero the exponent is zero", probably
meaning that -0 should be printed as zero, without the sign.

The whole paragraph is:

<quote>
The exponent always contains at least two digits, and only as many more
digits as necessary to represent the exponent. If the value is zero, the
exponent is zero.
<end quote>
 
K

Keith Thompson

jacob navia said:
Le 09/06/11 20:32, David Mathog a écrit :

The standard says that at least 2 zeros should be printed, and as many
digits should be printed as necessary to represent the exponent.

lcc-win printf had 2 zeroes but users complained because Microsoft
writes three zeroes, so now lcc-win writes three zeroes as Microsoft.
[...]

Hmm.

I suspect Microsoft is following the C90 standard, which merely
says that "The exponent always contains at least two digits.";
always providing 3 digits is consistent with that, through probably
not with the intent.

C99 is more specific: "The exponent always contains at least two
digits, and only as many more digits as necessary to represent
the exponent."

You might consider providing an option (perhaps an
implementation-specific function) to conform either to the C99
standard or to Microsoft's behavior. lcc-win's C99 conformance is a
major distinguishing point between it and Microsoft's implementation,
n'est-ce pas?
 
K

Keith Thompson

jacob navia said:
Le 09/06/11 21:12, David Mathog a écrit :

The standard says "If the value is zero the exponent is zero", probably
meaning that -0 should be printed as zero, without the sign.

I think that just means that if the value of the number is zero, the
exponent is zero. In other words, 0.0 won't print as "0.000000e+42".
That sentence isn't providing guidance for how a zero exponent should be
printed.
The whole paragraph is:

<quote>
The exponent always contains at least two digits, and only as many more
digits as necessary to represent the exponent. If the value is zero, the
exponent is zero.
<end quote>

I don't think "0.000000e-00" is specifically prohibited, but it wouldn't
make much sense to print it that way.
 
D

David Mathog


Thanks! (I thought that the only way to obtain a C99 standard was to
pay $$$ - that's the way most standards are.)

Just reviewed in this specification a couple of points of recent
interest (to me) - there are an amazing number of logical states that
are not specified. For instance, the behavior of log() says:

Description
2 The log functions compute the base-e (natural) logarithm of x.
A domain error occurs if the argument is negative. A range error may
occur
if the argument is zero.
Returns
3 The logfunctions return loge(x).

And what does it return if there there is a domain error, which could
occur
with half the possible values for x? It certainly cannot return
loge() in these cases, as described, since that is mathematically
undefined. The answer must be "implementation defined", conceivably
even an apparently valid result, like "5.0" (which is no more right
nor wrong than -HUGE_VAL) so long as it set the domain error. This
omission is presumably because implementations do not have to support
NaN or Inf (5.2.4.2.2-3). However, since most do, and the
specification says what these are in C99, would it have killed the
standard's writers to have changed the log() return spec to describe
what happens in that case? To something like (second sentence added):

Returns
3 The log function normally returns loge(x). If a domain error
occurs it returns NAN if implementation supported, else returns -
HUGE_VAL.

and in section 7.12.1-2, make the more general change for all
functions:

On a domain error, the function returns an implementation-
deï¬ned value;

to

On a domain error, the function returns NAN if implementation
supported, else the value specified by this standard.

?

For that matter, Solaris supports quiet and signaling nan, C99 does
not. C99 defines bits for NAN, which is a quiet NAN, but doesn't do
anything about the signaling type, F.2.1-1 says "This speciï¬cation
does not deï¬ne the behavior of signaling NaNs."

As for printing -0 as "-0". That is in notes 242 and 282 (page 276
and 350) which annotate the "+" modifier:

The results of all floating conversions of a negative zero, and of
negative values that round to zero, include a minus sign.

Which I would argue was the wrong choice (but that horse has left the
barn), since a printed -0 is not the desired result in any physical
measurement or quantization. Discriminating between +0 and -0 is only
of interest to a programmer - it is the sort of special case usually
handled by a macro like
isnormal().

Regards,

David Mathog
 
K

Keith Thompson

David Mathog said:
Thanks! (I thought that the only way to obtain a C99 standard was to
pay $$$ - that's the way most standards are.)

The actual C99 standard does cost money. The three Technical Corrigenda
are available at zero cost. N1256 is not the official standard; it's a
draft consisting of the C99 standard with the contents of the TCs merged
into it and marked with change bars.

For most purposes, N1256 is actually more useful than the C99 standard
(I have both), but there are probably some situations where only the
official standard will do.

(I won't try to explain ISO's and ANSI's pricing policies.)

[...]
 
J

jacob navia

Le 10/06/11 22:40, Sherm Pendley a écrit :
A pity, because I really wish someone would...

sherm--

Well, it is very difficult to read the standard.

There is a whole cottage industry of language lawyers that
apparently have mastered the art of interpreting that document.

After years of studying (and years of work implementing it)
I am still unable to understand what it says, as I demonstrated again
in this thread.

I said
The standard says "If the value is zero the exponent is zero", probably

Then Mr Thompson answered:

I think that just means that if the value of the number is zero, the
exponent is zero. In other words, 0.0 won't print as "0.000000e+42".
That sentence isn't providing guidance for how a zero exponent should be
printed.


Is Mr Thompson right?
Am I right?

Nobody knows, the sentence is ambiguous. Are they speaking of negative
zero? Or are they speaking about 0.000000e+45?

As many people have pointed out before, the standard leaves a lot just
"undefined" or "implementation defined". Error analysis is one of the
weakest point in the whole document.

In years of discussions in this group and in comp.std.c, I have tried to
point out to the most glaring deficiencies, with some success, since the
committee changed some parts of the standard in the direction I was
proposing, but those are really minimal changes.

jacob
 
K

Keith Thompson

jacob navia said:
Le 10/06/11 22:40, Sherm Pendley a écrit :

Well, it is very difficult to read the standard.

There is a whole cottage industry of language lawyers that
apparently have mastered the art of interpreting that document.
[snip]

Ok, but the question was about their pricing policies.
 
N

Nobody

I said


Then Mr Thompson answered:

I think that just means that if the value of the number is zero, the
exponent is zero. In other words, 0.0 won't print as "0.000000e+42".
That sentence isn't providing guidance for how a zero exponent should be
printed.

Is Mr Thompson right?
Probably.

Am I right?

Probably not.
Nobody knows, the sentence is ambiguous.

Such is the case for practically anything written in natural language.
Are they speaking of negative zero? Or are they speaking about
0.000000e+45?

Probably the latter. "0.0e+45" would clearly contradict the language in
the standard; whether "0.0e-00" contradicts it depends upon interpretation
(or rather, it only contradicts it if you infer meaning over and above the
literal meaning).
As many people have pointed out before, the standard leaves a lot just
"undefined" or "implementation defined".

Which is inevitable, given that the language is supposed to be both
efficient and portable to a wide range of architectures (including those
with segmented memory, ones-complement or sign-bit representation, trap
representations, etc).
 
K

Keith Thompson

Seebs said:
Oh, they're very easy to explain:

Large bureaucracies do stupid stuff sometimes.

Hope this helps.

Large bureaucracies often have policies that make sense in some
contexts, but apply them to other contexts where they make less
sense.

But comp.std.c would be the best place to discuss this. (Warning:
these questions have been asked before, and the discussions haven't
been terribly productive.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top