Re: C2124 is most disrespectful of IEEE floating point arithmetic

Doug Harrison [MVP] wrote:

On Sun, 27 Aug 2006 17:51:26 -0700, "Dr Pizza"
<DrPizza@xxxxxxxxxxxxxxxxx> wrote:

Since VC++ purports to follow IEC 559, and IEC 559 defines the
division of a non-zero by a zero to be a signed infinity, isn't it
rather silly that:

float inf(1.0f / 0.0f);

should result in a compile-time error, C2124? An error may be
appropriate for integer arithmetic (as it'll generate a runtime SEH
exception), but for floating point arithmetic it's surely incorrect
behaviour?

What gives? Am I being unreasonable in my expectations? It's
certainly rather nicer to type the above than have to spew:

float inf(std::numeric_limits<float>::infinity());

Division by zero is undefined, so the compiler can do whatever it
wants. For a compile-time expression, emitting an error is highly
appropriate. Using numeric_limits as above is self-documenting and
portable, and it is highly preferable to 1.0/0.0.

But it isn't undefined. Well; it's undefined in standard mathematics.
It isn't undefined in IEC 559, and VC++ purports to adhere to IEC 559.

IEEE 754 says that in the case of division of a finite value by zero:
<quotation>
7.2 Division by Zero

If the divisor is zero and the dividend is a finite nonzero number,
then the division by zero exception shall be signaled. The result, when
no trap occurs, shall be a correctly signed [Infinity] (6.3).
</quotation>

So depending on our handling of FP exceptions we should see one of two
things: with exceptions disabled, a signed infinity; with exceptions
enabled a divide by zero exception.

Yet in this case we get neither a trap nor a correctly signed infinity.
Instead, we have a compile-time error.

This is in spite of std::numeric_limits<float>::is_iec559 being 'true'
for float.

I don't see how you can have it both ways. Either is_iec559 should be
'false'--in which case all bets are off as to the behaviour of these
types and they are indeed "undefined", and a compile-time error is
consistent (even if not at all useful)--or the compiler should refrain
from trapping the division at compile-time, and instead allow the
defined runtime behaviour to occur.

I don't see why using numeric_limits is "highly preferable", as 1.0/0.0
is concise, well-defined, and clear.

--

.

Relevant Pages

  • Re: C2124 is most disrespectful of IEEE floating point arithmetic
    ... of a non-zero by a zero to be a signed infinity, ... float inf; ... Division by zero is undefined, so the compiler can do whatever it wants. ... For a compile-time expression, emitting an error is highly appropriate. ...
    (microsoft.public.vc.language)
  • Re: C2124 is most disrespectful of IEEE floating point arithmetic
    ... This is a compile-time constant expression, ... of a non-zero by a zero to be a signed infinity, ... should result in a compile-time error, ...
    (microsoft.public.vc.language)
  • Re: C2124 is most disrespectful of IEEE floating point arithmetic
    ... Treatment of division by zero, forming a remainder using a zero ... For a compile-time expression, ... So depending on our handling of FP exceptions we should see one of two ... we have a compile-time error. ...
    (microsoft.public.vc.language)
  • Re: INVALID_HANDLE_VALUE vs. NULL
    ... 0 (zero) can never be a valid handle value. ... Of course, ReadFilewill fail with this handle, ... > CloseHandle() does indeed fail when given a bad handle. ... > case it raises an exception. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Convert a string which might be a number to an int
    ... The problem is that if you really want to know if the string was in the correct format then you need to catch an exception which to be honest is a bad technique. ... ConvertTo returns zero in the case of an error which is bad because every mathemetician will scream that zero is a real number and is valid on it's own. ... Find great Windows Forms articles in Windows Forms Tips and Tricks ... Answer those GDI+ questions with the GDI+ FAQ ...
    (microsoft.public.dotnet.languages.csharp)