Prev: Why are static member variables allowed in c++ and not in C?
Next: enum operator overload ambiguity
From: Andrew on 27 Jan 2010 20:53
I have some questions about how floating point errors should be
handled portably in C++ programs. The errors I am talking about are
associated with C math functions such as exp.

Documentation such as http://docs.sun.com/app/docs/doc/806-3332/6jcg55o9k?a=view
talks about 'exceptions' but the math library is a C library.
Obviously when it uses the word 'exception' it means in the IEEE
sense, not in the C++ sense. Here is an excerpt:

---
some NaN or results may be issued by the floating-point unit and be
returned
as such to the application without any warning better than the value
of the
result. Detected errors are reported by setting errno to either ERANGE
or
EDOM, performing a system-dependant notification, and returning
either
+ , - or NaN, whichever best suits the nature of the error.
---

So, what's a C++ programmer supposed to do? I am working on a project
that is doing lots of number crunching in a Microsoft environment,
using the Visual Studio compilers. Apparantly there has been a change
between VC6 and VC8 regarding the way floating point 'exeptions' are
handled. In VC6 the IEEE exception is converted to a C++ exception but
in VC8 it is not. I am looking for some advice on how people handle
these issues in a portable way. And I don't just mean between
different versions of Visual Studio. I am thinking of POSIX platforms
too, including Linux.

Regards,

Andrew Marlow

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

From: Pete Becker on 28 Jan 2010 01:06
Andrew wrote:
> some NaN or results may be issued by the floating-point unit and be
> returned
> as such to the application without any warning better than the value
> of the
> result.

Yes, that's how IEEE floats are designed: don't check for errors until
the end. That way your code runs flat out in normal execution, and code
that runs into errors perhaps runs further than it otherwise would. But
if you read carefully about how NaN values and infinities propagate,
you'll see that you don't lose them, so checking at the end is safe.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

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

From: George Neuner on 28 Jan 2010 08:17
On Thu, 28 Jan 2010 12:06:33 CST, Pete Becker
<pete(a)versatilecoding.com> wrote:

>Andrew wrote:
>> some NaN or results may be issued by the floating-point unit and be
>> returned as such to the application without any warning better than
>> the value of the result.
>
>Yes, that's how IEEE floats are designed: don't check for errors until
>the end. That way your code runs flat out in normal execution, and code
>that runs into errors perhaps runs further than it otherwise would. But
>if you read carefully about how NaN values and infinities propagate,
>you'll see that you don't lose them, so checking at the end is safe.

The problem with quiet NaNs (and also with INFs) is that isn't easy to
identify the particular operation or data that caused your complex
computation to fail unless you check the results at every step. It
only gets worse using SIMD. It doesn't help that most FP hardware
doesn't support signaling NaNs with an interrupt and so, in most
cases, implementing language level exceptions requires slowing
calculations by inserting extra check code.

George

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

From: Pete Becker on 29 Jan 2010 06:46
George Neuner wrote:
> On Thu, 28 Jan 2010 12:06:33 CST, Pete Becker
> <pete(a)versatilecoding.com> wrote:
>
>> Andrew wrote:
>>> some NaN or results may be issued by the floating-point unit and be
>>> returned as such to the application without any warning better than
>>> the value of the result.
>> Yes, that's how IEEE floats are designed: don't check for errors until
>> the end. That way your code runs flat out in normal execution, and code
>> that runs into errors perhaps runs further than it otherwise would. But
>> if you read carefully about how NaN values and infinities propagate,
>> you'll see that you don't lose them, so checking at the end is safe.
>
> The problem with quiet NaNs (and also with INFs) is that isn't easy to
> identify the particular operation or data that caused your complex
> computation to fail unless you check the results at every step. It
> only gets worse using SIMD. It doesn't help that most FP hardware
> doesn't support signaling NaNs with an interrupt and so, in most
> cases, implementing language level exceptions requires slowing
> calculations by inserting extra check code.
>

The goal isn't making it easy to debug your code and validate input,
it's to make math operations run as fast as possible on valid values.
For debugging, enable floating-point exceptions and add your own
exception handlers. (Note: this has nothing to do with C++ exceptions;
floating-point math has its own idea of what constitutes an exception).
I don't know how intrusive that is in the real world; I'm not an expert
on floating-point math.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

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

From: Goran on 29 Jan 2010 06:45
On Jan 28, 2:53 pm, Andrew <marlow.and...(a)googlemail.com> wrote:
> I have some questions about how floating point errors should be
> handled portably in C++ programs. The errors I am talking about are
> associated with C math functions such as exp.
>
> Documentation such ashttp://docs.sun.com/app/docs/doc/806-3332/6jcg55o9k?a=view
> talks about 'exceptions' but the math library is a C library.
> Obviously when it uses the word 'exception' it means in the IEEE
> sense, not in the C++ sense. Here is an excerpt:
>
> ---
> some NaN or results may be issued by the floating-point unit and be
> returned
> as such to the application without any warning better than the value
> of the
> result. Detected errors are reported by setting errno to either ERANGE
> or
> EDOM, performing a system-dependant notification, and returning
> either
> + , - or NaN, whichever best suits the nature of the error.
> ---
>
> So, what's a C++ programmer supposed to do? I am working on a project
> that is doing lots of number crunching in a Microsoft environment,
> using the Visual Studio compilers. Apparantly there has been a change
> between VC6 and VC8 regarding the way floating point 'exeptions' are
> handled. In VC6 the IEEE exception is converted to a C++ exception but
> in VC8 it is not. I am looking for some advice on how people handle
> these issues in a portable way. And I don't just mean between
> different versions of Visual Studio. I am thinking of POSIX platforms
> too, including Linux.

I would guess that the difference you see between VC6 and 8 is in /EH
(project properties->C/C++->Code Generation->Enable C++ Exceptions,
where the default is now /EHsc). VC6 used to generate code that
catches MS's "structured" exceptions (OS exceptions) in C++ (that was
IMO a __bad__ idea). But, MS being what it is, you should be able to
get to the original situation by using /EHa (if you are asking me,
don't - at least not on the whole project level).

Goran.


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

 |  Next  |  Last
Pages: 1 2 3
Prev: Why are static member variables allowed in c++ and not in C?
Next: enum operator overload ambiguity