Re: `>>' can't read what `<<' produced: NaNs and Inf

[Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>]

Joao Cardoso <jcardoso@inescn.pt> writes:

| Ulrich Drepper wrote:
| > 
| > Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:
| ...
| > > Typically, this will print "Infinity" or "Inf".
| > > What happens when a user tries to read back the output? Should we
| > > extend the langage so that extracting "Infinity" (or "Inf") be treated
| > > as a lexeme that happens to represent numeric_limits<double>::infinity()?
| > 
| > Yes, definitely.  This is what the strtod() function in glibc does.
| > 
| > It also has to handle NaNs which can be written as
| > 
| >         NAN
| >         NAN(0x234)
| > 
| 
| Hi, I have a patch available, but I need some advise here:
| 
| 1-Should NaNs and Infs be generated by the compiler, generating a
| warning at library compile time (double f=1./0.;), or should they be
| generated ( *f = 0x...)?

The library has builtin functions to generate NaNs and Infs.

(volatile makes the compiler not to complain).

| 
| In the former case, the compiler warning can be disturbing for the user,
| but it generate the numbers in an architecture independent way (VAX,
| ix86, m68k, ...), while in the second case I must have the
| representation of NaNs and Infs in those architectures -- unless they
| are all IEEE/ISO/XXXsomething conforming.

It is almost impossible to do speak of NaNs and Infs out of  the scope
of IEEE 754 or IEC 559 or ISO/IEC 1067.


| If the correct approach is the last one, could someone check the
| correctness of the following?
|
| NaN =  0xfff8000000000000
| +Inf = 0x7ff0000000000000
| -Inf = 0xfff0000000000000

I assume you meant endian-free representation.

| 
| 2-If I remember correcty, NaNs can have several internal
| representations. I think that any one of them will be just as good as
| the others, as "NaN OP number" is always a NaN. Is this correct?

NaNs don't compare equal, and I would suggest we report NaNs with
mantissa. This is the approach taken in glibc

| 3- My parsing recognizes:
| 
| [+-]inf[inity]
| [+-]nan
| 
| with any mixing of upper or lower case.
| The above construct, nan(0x234) is not recognized. Is it really needed?

Yes.

-- Gaby