In article <7rf61g$30st$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>Perhaps standards need to include a specification against compiler
>suicide... ;)

I think we can manage that, but I think prohibition of murder is outside
our remit:)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<James.Kanze@dresdner-bank.com> wrote...
> (It the compiler happened to be on the disk which was
> formatted, one could also argue that there is no longer an
> implementation to be conforming.)

Perhaps standards need to include a specification against compiler
suicide... ;)

- Scott




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37D55B62.602DE0E3@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:

> An interesting question is if it would be allowed by the
> C++ standard - after all, the only way to detect it
> (if the drive doesn't contain the swap file ;-)) is
> through the I/O functions/objects. But their interaction
> with the "outside world" is very implementation defined
> anyway (I don't think an implementation would be
> non-conforming if it failed to prevent any _other_ program
> to format the hard disk while the C++ program runs - and
> the effect would be indistinguishable).

I have a conforming program, and it failed to run just because some
idiot pulled the plug on the computer.  I can't find anything in the
standard that says it is illegal to pull the plug while the program is
running, so this must be a bug in the implementation.  It's a fairly
widespread bug: I've found it in VC++, Sun CC, g++, and a couple of
other compilers as well.  I can only conclude that compiler writers
don't know their job.

Seriously, I've always liked the explination that in such cases, the
implementation is (temporarilly) non-conforming.  Alternatively, there
is a clause in the C standard, at least, letting the implementation off
the hook in the absense of resources.  I think that either explination
could apply equally to the case where a second program reformatted the
hard disk.  (It the compiler happened to be on the disk which was
formatted, one could also argue that there is no longer an
implementation to be conforming.)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:

> What we're really saying here is that there is no portable way of handling
> numerical exceptions under Standard C++. That's something that should be
> looked into on the next revision cycle.

Well, there is an easy way to ensure that happens.  Join the committee
and do it yourself.

Remember that the committee is made up of unpaid volunteers.  If people
interested in numerical issues do not join the committee, then little or
no progress will be made resolving current numerical issues or adding
numerical features during the next revision cycle.  If more numerical
people become active, more numerical stuff will happen.

--Beman Dawes


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <37CD75B4.CD72C79D@wizard.net>...
[snip]
> Furthermore, remember that "undefined behaviour" cancels
>all other guarantees made by the C++ standard, so it's inherently
>impossible for the situation you describe to be a contradiction. It's
>always resolved in favor of "undefined behavior".

I'm stumped. Let somebody who is good in logic tell me. If standard defines
some behavior of a particular situation in one place, and says that the same
situation has undefined behavior in another place, is it a plain
contradiction? It can be either defined or undefined, but not both.

Gene Bushuyev
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> OTOH, it's still useless, since "undefined behaviour"
> isn't restricted to the number itself. Assuming the
> behaviour would be to format your hard disk and then
> set the result to NaN, it would be conforming to
> IEC 559 (since that doesn't tell you anything about
> your hard disk) *and* to the C++ standard even with
> the flag set to true (since formatting the hard disk
> is allowed for undefined behaviour).

By that logic, it would be IEC559 conformant if 1.0 + 1.0 formatted your hard
disk and returned 2.0.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" wrote:
>
> Christopher Eltschka wrote:
> >
> > OTOH, it's still useless, since "undefined behaviour"
> > isn't restricted to the number itself. Assuming the
> > behaviour would be to format your hard disk and then
> > set the result to NaN, it would be conforming to
> > IEC 559 (since that doesn't tell you anything about
> > your hard disk) *and* to the C++ standard even with
> > the flag set to true (since formatting the hard disk
> > is allowed for undefined behaviour).
>
> By that logic, it would be IEC559 conformant if 1.0 + 1.0 formatted your hard
> disk and returned 2.0.

While I don't have that particular standard, I'd be very surprised
if it covers anything but the results of the numeric operations
(and error reporting in case one occurs).

So yes, I think it would be conforming to IEC559 to format the
hard disk on adding 1.0 and 1.0, as long as the result is 2.0.

Imagine an implementation which does IEC559 calculations, but as
a side effect writes a protocol of each operation it does.
Should that be non-conforming in respect to IEC559?

BTW, how do you check for a formatted hard disk using only
operations defined by IEC559?

(I can imagine one limitation, though: If the hard disk
contains numbers of the current calculation, maybe it's
not legal to format it ;-))

An interesting question is if it would be allowed by the
C++ standard - after all, the only way to detect it
(if the drive doesn't contain the swap file ;-)) is
through the I/O functions/objects. But their interaction
with the "outside world" is very implementation defined
anyway (I don't think an implementation would be
non-conforming if it failed to prevent any _other_ program
to format the hard disk while the C++ program runs - and
the effect would be indistinguishable).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
>
> James Kuyper wrote:
> >
> > Ron Natalie wrote:
> > ...
> > > Unfortunately, there's contradictory statements in the C++
> > > standard.  You may never get past the division line regardless
> > > of what numeric_limits tells you.
> >
> > You seem to be misinterpreting what "undefined behavior" means.
>
> Nope, it seems to be you that don't understand.  The standard
> can't both say something has undefined behavior in one place
> and say it has defined behavior in another.  It's a contradiction.

Remember that "undefined" in the context of the C++ standard means only
that the C++ standard doesn't define it. Other entities are still free
to define it. Furthermore, remember that "undefined behaviour" cancels
all other guarantees made by the C++ standard, so it's inherently
impossible for the situation you describe to be a contradiction. It's
always resolved in favor of "undefined behavior".

And behavior which is undefined by the C++ standard is permitted to
include behaving exactly in the manner defined by  IEC 559.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Ron Natalie wrote:
>...
>> You would hope that is_iec559 indicates that while the overall standard
>> doesn't define the divide-by-zero behavior, that the presence of this
>> flag means it conforms to that 559.  This unfortunately is not the
>> case, I believe.  Hopefully in the next revision of C and C++ it
>> will.
>
>The standard says that if is_iec559 is true, it means that the type
>conforms to IEC 559. Is there something else the standard must say,
>beyond that?

One subtle issue -- not directly related to division by zero, but
related to the predictability of IEEE float -- is that the IEEE flaot
standard (IEC 559) leaves some things implementation-defined or undefined.
It does not define how source code maps to IEEE float operations.
For example, implementations can perform certain operations in extended
precision (e.g. this is commonly done on some architectures for
operations whose operands are in registers).

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Ron Natalie wrote:
>>
>> James Kuyper wrote:
>> >
>> > Ron Natalie wrote:
>> > ...
>> > > Unfortunately, there's contradictory statements in the C++
>> > > standard.  You may never get past the division line regardless
>> > > of what numeric_limits tells you.
>> >
>> > You seem to be misinterpreting what "undefined behavior" means.
>>
>> Nope, it seems to be you that don't understand.  The standard
>> can't both say something has undefined behavior in one place
>> and say it has defined behavior in another.  It's a contradiction.
>
>Remember that "undefined" in the context of the C++ standard means only
>that the C++ standard doesn't define it. Other entities are still free
>to define it.

True... but if the C++ standard says both that the behaviour must conform
to IEC 559 and also that the behaviour is undefined, then that is a
contradiction in the C++ standard.

If IEC 559 said the behaviour is defined and the C++ standard said only
that the behaviour was undefined, there would be no contradiction.
The contradiction arises because the C++ standard also says that the
behaviour must conform to IEC 559.

(Well, actually the C++ standard only says that the _type_ must conform
to IEC 559, not the operations on the type, but that is a separate issue...)

>Furthermore, remember that "undefined behaviour" cancels
>all other guarantees made by the C++ standard, so it's inherently
>impossible for the situation you describe to be a contradiction. It's
>always resolved in favor of "undefined behavior".

Where in the standard does it say that?

>And behavior which is undefined by the C++ standard is permitted to
>include behaving exactly in the manner defined by  IEC 559.

Yes, but it is not required to do so.  So, assuming you resolve the
contradiction in favour of undefined behaviour, the behaviour of
division by zero is undefined even if numeric_limits says is_iec559 is
true.  The implementation is permitted to return an Inf but it's not
required to.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
>
> James Kuyper wrote:
> >
> > Ron Natalie wrote:
> > ...
> > > Unfortunately, there's contradictory statements in the C++
> > > standard.  You may never get past the division line regardless
> > > of what numeric_limits tells you.
> >
> > You seem to be misinterpreting what "undefined behavior" means.
>
> Nope, it seems to be you that don't understand.  The standard
> can't both say something has undefined behavior in one place
> and say it has defined behavior in another.  It's a contradiction.
> Read 1.3.12 of the spec carefully.

I'm not sure if the following reasoning is correct according
to the standard interpretation of the standard's language,
but:

Division by zero is undefined by the standard. That means
that the implementation may do anything. However, if the
implementation does something which doesn't conform to
IEC 559, it may not set the iec559 flag to true.
So, no contradiction here.
OTOH, it's still useless, since "undefined behaviour"
isn't restricted to the number itself. Assuming the
behaviour would be to format your hard disk and then
set the result to NaN, it would be conforming to
IEC 559 (since that doesn't tell you anything about
your hard disk) *and* to the C++ standard even with
the flag set to true (since formatting the hard disk
is allowed for undefined behaviour).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Fergus Henderson wrote:
> James Kuyper <kuyper@wizard.net> writes:
....
> >Furthermore, remember that "undefined behaviour" cancels
> >all other guarantees made by the C++ standard, so it's inherently
> >impossible for the situation you describe to be a contradiction. It's
> >always resolved in favor of "undefined behavior".
>
> Where in the standard does it say that?

It's not stated as such; rather, it's implicit in the structure of the
standard. The standard as a whole defines what the behavior should be;
it also specifies a large number of situations that allowing undefined
behavior. Undefined behavior can be arbitrarily bad; it can terminate
execution, or even the compilation of a program. Many programs with
undefined behavior, including most real ones, have large chunks of code
with perfectly well-defined behavior. How could the permission for
undefined behavior be allowed to include termination of translation,
much less termination of execution, if the standard's promises for those
other chunks weren't canceled by the undefined behavior allowed by the
defective part of the code? Those promises typically cannot be fulfilled
until the relevant code's actually been executed, which might occur
after the defective code has executed.

Let's take a specific example:

 unsigned func1()
 {
  static unsigned count=0U;
  return ++count;
 }

 void func2()
 {
  char *p;
  *p = ' ';
 }

Now, func1() is a function for which the standard guarantees
implementation-defined behavior (due to the implementation-defined value
of UINT_MAX). On the other hand, func2() has undefined behavior. Does
this mean that you can still count on func1() to work as guaranteed
every time it's called, no matter how often you call func2()? No - the
uninitialized value of 'p' might happen to point at one of the bytes
covered by 'count'. On some rather nasty systems, it might even point at
the compiled code for func1().

"Undefined behavior" cancels all other promises made by the standard - I
don't see how it could be otherwise. I'd appreciate an explanation if
that's not the case.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:

> I'm stumped. Let somebody who is good in logic tell me. If standard defines
> some behavior of a particular situation in one place, and says that the same
> situation has undefined behavior in another place, is it a plain
> contradiction? It can be either defined or undefined, but not both.

There isn't just one logic. It depends on the logic.

I have heard that some logics can tolerate that rules
that have exceptions, although I don't know any which
does.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Ron Natalie wrote:
> ...
> > Unfortunately, there's contradictory statements in the C++
> > standard.  You may never get past the division line regardless
> > of what numeric_limits tells you.
>
> You seem to be misinterpreting what "undefined behavior" means.

Nope, it seems to be you that don't understand.  The standard
can't both say something has undefined behavior in one place
and say it has defined behavior in another.  It's a contradiction.
Read 1.3.12 of the spec carefully.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern <austern@sgi.com> wrote in message...
> No, because that's not always what happens on a conforming IEEE754
> implementation.  The standard allows users to set a flag so that
> division by zero results in a trap, rather than returning Inf.

I used to have a IEEE 754 document somewhere; now I can't find the damned
thing.

Most processors have a set of registers for setting such behaviors, which I
assume stem from the IEEE 754/IEC 559 definition. Problem is, different
compilers implement different functions for manipulating those registers.

What we're really saying here is that there is no portable way of handling
numerical exceptions under Standard C++. That's something that should be
looked into on the next revision cycle.

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:

> Unfortunately, there's contradictory statements in the C++
> standard.

Which statements ?

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
>
> In 5.6 of the Standard, it states: "If the Second operand of / or % is zero
> the behavior is undefined." Therefore, can I assume that correct
> mathematical behavior is not enforced (i.e., division by zero == infinity),
> even though the is_iec559 member of numeric_limits<double or float> is true?

IEC559 indicates a certain behavior for floating point operations.
Division by zero by the way is not always infinity.  It may be
-Infinity or Nan depending on the numerator.

You would hope that is_iec559 indicates that while the overall standard
doesn't define the divide-by-zero behavior, that the presence of this
flag means it conforms to that 559.  This unfortunately is not the
case, I believe.  Hopefully in the next revision of C and C++ it
will.

>
> Now here's the weird part: According to the Standard, if is_iec559 != false
> for given floating-point type, then has_infinity must be true for that type.
> If the Standard is forcing the definition of has_infinity based on
> is_iec559, then why doesn't it also require that division by zero equal
> infinity for is_iec559 != false?

Because it is only defining the behavior of these bools here,
perhaps if there was a bool that says "divide by zero yields
infinity" that would be nice, but there isn't one.  The clauses
you are reading are purely defining the existant fields in
numeric_limits.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
...
> You would hope that is_iec559 indicates that while the overall standard
> doesn't define the divide-by-zero behavior, that the presence of this
> flag means it conforms to that 559.  This unfortunately is not the
> case, I believe.  Hopefully in the next revision of C and C++ it
> will.

The standard says that if is_iec559 is true, it means that the type
conforms to IEC 559. Is there something else the standard must say,
beyond that?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote...
> The standard says that if is_iec559 is true, it means that the type
> conforms to IEC 559. Is there something else the standard must say,
> beyond that?

It isn't clear from the standard the *operations* on the type must also
conform to IEC 559.

Be that as it may: Am I safe in assuming:

if (numeric_limits<float>.is_iec559)
{
    float f1, f2, f3;
    f1 = 1.0;
    f2 = 0.0;
    f3 = f1 / f2;

    if (f3 == numeric_limits<float>.infinity)
        cout << "hey, this really is IEC 559!" << endl;
    else
        cout << "well, so much for the is_iec559 flag" << endl;
}

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie <ron@sensor.com> wrote in message
news:37CAC0DC.73976B5C@sensor.com...
> IEC559 indicates a certain behavior for floating point operations.
> Division by zero by the way is not always infinity.  It may be
> -Infinity or Nan depending on the numerator.

Okay, you got me :) I should have included all the cases. An infinity
divided by an infinity is a Nan, for instance.

> You would hope that is_iec559 indicates that while the overall standard
> doesn't define the divide-by-zero behavior, that the presence of this
> flag means it conforms to that 559.  This unfortunately is not the
> case, I believe.  Hopefully in the next revision of C and C++ it
> will.

I hope so too. Right now, the flag really doesn't mean much more than "when
I'm set, these other booleans must be set too". Not very helpful...

I wonder how many people on the C committee were numerical programmers?

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Ron Natalie wrote:
> ...
> > You would hope that is_iec559 indicates that while the overall standard
> > doesn't define the divide-by-zero behavior, that the presence of this
> > flag means it conforms to that 559.  This unfortunately is not the
> > case, I believe.  Hopefully in the next revision of C and C++ it
> > will.
>
> The standard says that if is_iec559 is true, it means that the type
> conforms to IEC 559. Is there something else the standard must say,
> beyond that?

Yes, as the original poster pointed out it says that divide by
zero provides UNDEFINED BEHAVIOR.  It needs to either be changed
to IMPLEMENTATION DEFINED, or there needs to be text that says
when the behavior is not UNDEFINED in the case of IEC559 compliant
numerics.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

> James Kuyper <kuyper@wizard.net> wrote...
> > The standard says that if is_iec559 is true, it means that the type
> > conforms to IEC 559. Is there something else the standard must say,
> > beyond that?
>
> It isn't clear from the standard the *operations* on the type must also
> conform to IEC 559.
>
> Be that as it may: Am I safe in assuming:
>
> if (numeric_limits<float>.is_iec559)
> {
>     float f1, f2, f3;
>     f1 = 1.0;
>     f2 = 0.0;
>     f3 = f1 / f2;
>
>     if (f3 == numeric_limits<float>.infinity)
>         cout << "hey, this really is IEC 559!" << endl;
>     else
>         cout << "well, so much for the is_iec559 flag" << endl;
> }

No, because that's not always what happens on a conforming IEEE754
implementation.  The standard allows users to set a flag so that
division by zero results in a trap, rather than returning Inf.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern wrote:

>
> No, because that's not always what happens on a conforming IEEE754
> implementation.  The standard allows users to set a flag so that
> division by zero results in a trap, rather than returning Inf.

Yes, but by default the exceptions should be off, so the code
should work in a comforming implementation.

Unfortunately, there's contradictory statements in the C++
standard.  You may never get past the division line regardless
of what numeric_limits tells you.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The fact that the spec says, without qualification, that divide
by zero produces undefined behavior.  This is at odds with saying
that the language produces any defined behavior for divide by
zero.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
...
> Unfortunately, there's contradictory statements in the C++
> standard.  You may never get past the division line regardless
> of what numeric_limits tells you.

You seem to be misinterpreting what "undefined behavior" means. One part
of the standard says that division by zero allows undefined behavior.
Another says that the type conforms to IEC 559. That's not a
contradiction. One permissible form of undefined behavior is strict
conformance with IEC 559.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
>
> The fact that the spec says, without qualification, that divide
> by zero produces undefined behavior.  This is at odds with saying
> that the language produces any defined behavior for divide by
> zero.

Sure - the behavior is undefined by the C++ standard; that doesn't
prohibit the behavior from being defined either by the implementation,
or by IEC 559. And of course, even if the behavior were left completely
undefined, it's still legal for it to be exactly what you want it to be.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Further exploration and ruminations...

Apparently, both GCC 2.95 and Visual C++ 6 handle division by zero
correctly, generating an infinity! the following fragment of code:

        f1 = 1.0;
        f2 = 0.0;
        f3 = f1 / f2;
        cout << "f3 = " << f3 << endl;

generates this under GCC 2.95:

        f3 = Infinity

and this under Visual C++:

        f3 = 1.#INF

In 5.6 of the Standard, it states: "If the Second operand of / or % is zero
the behavior is undefined." Therefore, can I assume that correct
mathematical behavior is not enforced (i.e., division by zero == infinity),
even though the is_iec559 member of numeric_limits<double or float> is true?

Now here's the weird part: According to the Standard, if is_iec559 != false
for given floating-point type, then has_infinity must be true for that type.
If the Standard is forcing the definition of has_infinity based on
is_iec559, then why doesn't it also require that division by zero equal
infinity for is_iec559 != false? That way, a programmer could test the
setting of is_iec559 to determine if they can rely on correct handling of
division by zero.

Inquiring mathematical minds want to know.

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]