hi,

I've got a program that outputs a float through a stream, like so:

outf << f;

Sometimes f is infinity, as in numeric_limits<float>::infinity(). In
that case it outputs "inf".  When compiled with GCC 2.96 or 2.95.3,
doing

istream infile;
....
infile >> f;

f comes out as infinity again, which I rely on happening.


Under GCC 3.2.3 or 3.3 this results in a read error.  I've fixed it
like so:

infile >> f;
if (!infile) {
  string str;
  infile.clear();
  infile >> str;
  if (str == "inf") {
    f = numeric_limits<float>::infinity();
  }
}

it seems that the string gets thunked through to the libc functions
__strtof_l which incorporates the locale, but doing
$ export LANG=C
has no effect either.

What is the right way to handle this?

Albert

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Albert Visagie" <avisagie@dsp.sun.ac.za> wrote in message

> infile >> f;
> if (!infile) {
>   string str;
>   infile.clear();
>   infile >> str;
>   if (str == "inf") {
>     f = numeric_limits<float>::infinity();
>   }
> }

Relying on the string "inf" is this portable?  I searched standard for
"infinity" and "inf" (whole words only) but didn't find anything.

--
+++++++++++
Siemel Naran


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Albert Visagie wrote:
[ reading "inf" results in infinite for floats with some stdlibs and fails
with others. ]

1. http://gcc.gnu.org/gcc-2.96.html

2. In the face of portability (which Simiel Naran hinted at), you might
consider creating your own num_put<> and num_get<> facets, they are the
proper place for putting this.

However, I also wonder what restrictions the standard puts on the output of
streams: does the resulting text have to be readable ? In this particular
case, shouldn't the write-operation already fail ?


Uli


-- 
Questions ?
see  C++-FAQ Lite: http://parashift.com/c++-faq-lite/  first !


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hello, Albert Visagie!

Albert Visagie schrieb:

> hi,
>
> I've got a program that outputs a float through a stream, like so:
>
> outf << f;
>
> Sometimes f is infinity, as in numeric_limits<float>::infinity(). In
> that case it outputs "inf".  When compiled with GCC 2.96 or 2.95.3,
> doing
>
> istream infile;
> ...
> infile >> f;
>
> f comes out as infinity again, which I rely on happening.
>
> Under GCC 3.2.3 or 3.3 this results in a read error.  I've fixed it
> like so:
>
> infile >> f;
> if (!infile) {
>   string str;
>   infile.clear();
>   infile >> str;
>   if (str == "inf") {
>     f = numeric_limits<float>::infinity();
>   }
> }
>
> it seems that the string gets thunked through to the libc functions
> __strtof_l which incorporates the locale, but doing
> $ export LANG=C
> has no effect either.
>
> What is the right way to handle this?
>

The current C++98 standard is not very precise (in my opinion)
concerning the validity of the an floating-point-infinity-Symbol as
input for a floating-point number. To my my mind, there are two
contradicting snetences in the standard:

1) The description of the 2nd stage of the conversion process (in
22.2.2.1.2) seems to imply, that valid input must contain characters in
the set defined by
"0123456789abcdefABCDEF+�", the locale decimal point, and the locale
thousands separator.

2) The beginning of the description of the 3rd stage references to the
2nd stage as "[..](according to the rules of scanf)[..]".

3) I do not have the C89 standard available, but the newer C99 standard
says the following:
(a) The description of scanf delegates the problematic situation to
strtod in 7.19.6.2/ page 284:

"Matches an optionally signed floating-point number, infinity, or NaN,
whose
format is the same as expected for the subject sequence of the strtod
function."

(b) strtod guarantees the following in 7.20.1.3/ p.3:
"The expected form of the subject sequence is an optional plus or minus
sign, then one of
the following:
� a nonempty sequence of decimal digits optionally containing a
decimal-point
character, then an optional exponent part as defined in 6.4.4.2;
� a0x or 0X, then a nonempty sequence of hexadecimal digits optionally
containing a
decimal-point character, then an optional binary exponent part as
defined in 6.4.4.2;
� one of INF or INFINITY, ignoring case
� one of NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part,
where:
n-char-sequence:
digit
nondigit
n-char-sequence digit
n-char-sequence nondigit
The subject sequence is defined as the longest initial subsequence of
the input string,
starting with the first non-white-space character, that is of the
expected form. The subject
sequence contains no characters if the input string is not of the
expected form."

This suggests, that either "INF" or "INFINITY", ignoring case should be
a valid input for floating point numbers, iff we interpret the current
C++98 standard somewhat future orientated. I do not have the C89
standard to my hands, but even if we assume the same rule concerning
infinites as in the C99 standard, I think the current wording of the
C++98 standard needs a clearer wording concerning this situation.

Greeting from Bremen,

Daniel Spangenberg




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <3F39F77B.6B33406C@bdal.de>, Daniel Spangenberg wrote:
> Hello, Albert Visagie!
> 
> Albert Visagie schrieb:

[Summary: Infinite floats can be written to and read from streams as
"inf" in GCC 2.95.3 and 2.96, but this does not work in 3.2.3 and 3.3.]

>> What is the right way to handle this?
>>
> 
> The current C++98 standard is not very precise (in my opinion)
> concerning the validity of the an floating-point-infinity-Symbol as
> input for a floating-point number.

Actually, it is precise.

> To my my mind, there are two
> contradicting snetences in the standard:
> 
> 1) The description of the 2nd stage of the conversion process (in
> 22.2.2.1.2) seems to imply, that valid input must contain characters in
> the set defined by
> "0123456789abcdefABCDEF+-", the locale decimal point, and the locale
> thousands separator.
> 
> 2) The beginning of the description of the 3rd stage references to the
> 2nd stage as "[..](according to the rules of scanf)[..]".
> 
> 3) I do not have the C89 standard available, but the newer C99 standard
> says the following:

C99 has been heavily influenced by Fortran users and has very
different floating-point facilities from earlier versions of C, so C99
should not be used as even a guide to floating-point support in C++.

(Quite what an ordinary C++ programmer is supposed to use as a
reference to the C library now, I don't know.  ACCU recommends
"Standard C: A Reference" but the 1996 edition is now out of print and
the earlier editions don't cover the 1995 amendment (AM1).  ISO
9899:1990 is available from BSI for only �30 but I can't see how to
obtain AM1 at all.)

> (a) The description of scanf delegates the problematic situation to
> strtod in 7.19.6.2/ page 284:
<snip> 
> (b) strtod guarantees the following in 7.20.1.3/ p.3:
> "The expected form of the subject sequence is an optional plus or minus
> sign, then one of
> the following:
> ? a nonempty sequence of decimal digits optionally containing a
> decimal-point
> character, then an optional exponent part as defined in 6.4.4.2;
> ? a0x or 0X, then a nonempty sequence of hexadecimal digits optionally
> containing a
> decimal-point character, then an optional binary exponent part as
> defined in 6.4.4.2;
> ? one of INF or INFINITY, ignoring case
> ? one of NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part,
<snip>

In C95 strtod only accepts the first format.

It's a known problem that glibc only has a C99 version of strtod:
<http://sources.redhat.com/ml/bug-glibc/2001-02/msg00052.html>.

Evidently libstdc++ 3 avoids using it because of this.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Good Morning, Ben Hutchings!

Ben Hutchings schrieb:

 > In article <3F39F77B.6B33406C@bdal.de>, Daniel Spangenberg wrote:

[snip]

 > > The current C++98 standard is not very precise (in my opinion)
 > > concerning the validity of the an floating-point-infinity-Symbol as
 > > input for a floating-point number.
 >
 > Actually, it is precise.

This is a very baseless statement. Maybe I have a stone in my head (or
something
worse;-), but looking at the following quotes of the current C++ standard:

 > > To my my mind, there are two
 > > contradicting snetences in the standard:
 > >
 > > 1) The description of the 2nd stage of the conversion process (in
 > > 22.2.2.1.2) seems to imply, that valid input must contain characters in
 > > the set defined by
 > > "0123456789abcdefABCDEF+-", the locale decimal point, and the locale
 > > thousands separator.
 > >
 > > 2) The beginning of the description of the 3rd stage references to the
 > > 2nd stage as "[..](according to the rules of scanf)[..]".
 > >
 > > 3) I do not have the C89 standard available, but the newer C99 standard
 > > says the following:
 >

.... I don't understand to interpret these rules. If I am strict lawyer, I
would
use the stronger one (The first one), which says, that "inf" (or "INF") is
not
a continous sequence which is described by the set of valid chracters. In
this
case the 2nd rule **additionally** constraints the 1st rule in the sense that

the input must **also** be a valid input for scanf. This means for my that
neither "INF" nor "INFINITY" could be a valid input. Obviously this was not
the intend (I hope).

 > C99 has been heavily influenced by Fortran users and has very
 > different floating-point facilities from earlier versions of C, so C99
 > should not be used as even a guide to floating-point support in C++.
 >
 > (Quite what an ordinary C++ programmer is supposed to use as a
 > reference to the C library now, I don't know.  ACCU recommends
 > "Standard C: A Reference" but the 1996 edition is now out of print and
 > the earlier editions don't cover the 1995 amendment (AM1).  ISO
 > 9899:1990 is available from BSI for only �30 but I can't see how to
 > obtain AM1 at all.)
 >

Thanks for this information. Since I don't have neither "Standard C: A
Reference"
nor "ISO 9899:1990" available, I watched at the C99 standard.

How do I have to understand your opinion concerning C99 in this case? It
seems,
that you don't welcome this extension concerning infinity-readibility?
To my opinion it is the way in the correct direction to make both C and C++
more interesting for scientific numeric (That is what I understand as
"influenced by
Fortran users"). I think this growing interest is already visible, think of
the (currently
still somewhat truncated) ublas library of boost, see their interval classes
and so on.


 > <snip>
 > > (b) strtod guarantees the following in 7.20.1.3/ p.3:
 > > "The expected form of the subject sequence is an optional plus or minus
 > > sign, then one of
 > > the following:
 > > ? a nonempty sequence of decimal digits optionally containing a
 > > decimal-point
 > > character, then an optional exponent part as defined in 6.4.4.2;
 > > ? a0x or 0X, then a nonempty sequence of hexadecimal digits optionally
 > > containing a
 > > decimal-point character, then an optional binary exponent part as
 > > defined in 6.4.4.2;
 > > ? one of INF or INFINITY, ignoring case
 > > ? one of NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part,
 > <snip>
 >
 > In C95 strtod only accepts the first format.

Which one? Do you mean simply "INF" or do you mean both "INF" **or**
"INFINITY"
**but not** "NAN" or "NAN"(n-char-sequenceopt)?

Greetings from Bremen,

Daniel




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

In article <3F3C79DE.1EDED67A@bdal.de>, Daniel Spangenberg wrote:
> Good Morning, Ben Hutchings!
> 
> Ben Hutchings schrieb:
> 
> > In article <3F39F77B.6B33406C@bdal.de>, Daniel Spangenberg wrote:
> 
> [snip]
> 
> > > The current C++98 standard is not very precise (in my opinion)
> > > concerning the validity of the an floating-point-infinity-Symbol as
> > > input for a floating-point number.
> >
> > Actually, it is precise.
> 
> This is a very baseless statement. Maybe I have a stone in my head (or
> something worse;-), but looking at the following quotes of the current
> C++ standard:
> 
> > > To my my mind, there are two
> > > contradicting snetences in the standard:
> > >
> > > 1) The description of the 2nd stage of the conversion process (in
> > > 22.2.2.1.2) seems to imply, that valid input must contain characters
> > > in the set defined by "0123456789abcdefABCDEF+-", the locale decimal
> > > point, and the locale thousands separator.

The first string is just a set of characters that the first block of code
may need to convert from charT to char type.  The second block constructs
a lookup table for this conversion.

Paragraphs 9 and 10 say that that only characters that would be accepted
by scanf for the selected conversion are accumulated, and only thousands
separators are ignored, and conversion continues only if the character
falls into one of those categories.

> > > 2) The beginning of the description of the 3rd stage references to the
> > > 2nd stage as "[..](according to the rules of scanf)[..]".

No problem, as stage 2 accepts the same character sequences as scanf.  But
note that this is scanf as defined in C95 (i.e. C89/90 as amended by TC1
and AM1).

<snip>
> > > (b) strtod guarantees the following in 7.20.1.3/ p.3:

Reformatted quote:

   "The expected form of the subject sequence is an optional plus or
    minus sign, then one of the following:
    -- a nonempty sequence of decimal digits optionally containing a
       decimal-point character, then an optional exponent part as defined
       in 6.4.4.2;
    -- a 0x or 0X, then a non-empty sequence of hexadecimal digits
       optionally containing a decimal-point character, then an optional
       binary exponent part as defined in 6.4.4.2;
    -- one of INF or INFINITY, ignoring case
    -- one of NAN or NAN(n-char-sequence_opt), ignoring case in the NAN
       part, where:"

> > In C95 strtod only accepts the first format.
> 
> Which one? Do you mean simply "INF" or do you mean both "INF" **or**
> "INFINITY" **but not** "NAN" or "NAN"(n-char-sequenceopt)?

There are four items in the list.  In C95 strtod only accepts the first;
the hexadecimal format, infinity and NaN representations are all C99
additions which strtod does not in C95 or C++98.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]