Hans Aberg wrote:
...
> This is really the point I wanted to know: How to get a signaling NaN
> generate a C++ exception.

What you have to do is investigate the implementation's documentation.
Unless the implementation itself provides an option for converting a
floating point exception into a specified C++ exception, you're probably
out of luck. Throwing a C++ exception from an appropriately defined
signal handler would render it no longer a POF (Section 18.7p5), and the
behavior is therefore implementation-defined. There's essentially no way
to do this portably.

> The C++ standard does not seem to give any provision for that, in the case
> one now has access to floats with signaling NaN's.

Correct. Section 5p5 says "If during the evaluation of an expression,
the result is not mathematically defined or not in the range of
representable values for its type, the behavior is undefined, unless
such an expression is a constant expression (5.19), in which case the
program is ill-formed. [_Note:_ most existing implementations of C++
ignore integer overflows. Treatment of division by zero, forming a
remainder using a zero divisor, and all floating point exceptions vary
among machines, and is usually adjustable by a library function.]"

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3ADE1EB4.4B742C0C@wizard.net>, "James Kuyper Jr."
<kuyper@wizard.net> wrote:
>> This is really the point I wanted to know: How to get a signaling NaN
>> generate a C++ exception.
>
>What you have to do is investigate the implementation's documentation.
>Unless the implementation itself provides an option for converting a
>floating point exception into a specified C++ exception, you're probably
>out of luck. Throwing a C++ exception from an appropriately defined
>signal handler would render it no longer a POF (Section 18.7p5), and the
>behavior is therefore implementation-defined. There's essentially no way
>to do this portably.

Out of luck is probably the name of the game.

>> The C++ standard does not seem to give any provision for that, in the case
>> one now has access to floats with signaling NaN's.
>
>Correct.

But it is fun that one has at least implemented a cosmetic version of
signaling NaN's.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

The handling of NaNs is very hardware- and compiler-specific. As other's
here have pointed out, the Standard C++ does not include any support for
trapping signalling NaNs with C++ exceptions.

Specific compiler provide control over signalling NaNs and other
floating-point exceptions. Visual C++, for example, suppports a variety of
functions for controlling how the math coprocessor (or its emulator) handles
"exceptions" via signals; this, however, is very specific to the Wintel
platform. I don't believe that a cross-platform, cross-compiler solution
exists.

If you'd like, I can ship you an example of Visual C++ code that manages
floating-point exceptions. But it *will* be Microsoft-Intel specific...

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order & Chaos
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://www.research.att.com/~austern/csc/faq.html                ]

In article <cwoD6.33719$o9.7051318@typhoon.tampabay.rr.com>, "Scott Robert
Ladd" <scott@coyotegulch.com> wrote:
>The handling of NaNs is very hardware- and compiler-specific. As other's
>here have pointed out, the Standard C++ does not include any support for
>trapping signalling NaNs with C++ exceptions.
...
>I don't believe that a cross-platform, cross-compiler solution
>exists.

This limitation in the C++ standard is evidently due to the CPU hardware
situation.

But perhaps that situation has changed, so that if signaling NaN's are
available, one also set them to generate C++ exceptions. But then one
would need to check the hardware situation first.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article
<remove.haberg-1904011122490001@du133-226.ppp.su-anst.tninet.se>,
remove.haberg@matematik.su.se (Hans Aberg) wrote:

>In article <3ADE1EB4.4B742C0C@wizard.net>, "James Kuyper Jr."
><kuyper@wizard.net> wrote:
>>> This is really the point I wanted to know: How to get a signaling NaN
>>> generate a C++ exception.
>>
>>What you have to do is investigate the implementation's documentation.
>>Unless the implementation itself provides an option for converting a
>>floating point exception into a specified C++ exception, you're probably
>>out of luck. Throwing a C++ exception from an appropriately defined
>>signal handler would render it no longer a POF (Section 18.7p5), and the
>>behavior is therefore implementation-defined. There's essentially no way
>>to do this portably.
>
>Out of luck is probably the name of the game.

This is even more true than the difficulty of getting your code executed
and throwing an exception.

Exceptions cause optimizing compilers headaches. They have to account
for the alternate return path that might result from any call that could
result in an exception.

If your compiler assumes that floating-point operations do not throw c++
exceptions, it can do many optimizations that will leave variables in
bad states if you throw exceptions from floating-point IEEE exceptional
opererations.

I would highly recommend against trying to introduce any points at which
exceptions can begin propogating that the compiler doesn't know about
(either implicity, or explicitly with a function call boundary).

Mitch

------------------------------------------------------------------------
Mitch Adler                   "There are people in the world who
Intelligent Paradigm           do not love their fellow human beings,
Mitch@mitch.org                and I hate people like that."
Mitch@IntelligentParadigm.com      - Tom Lehrer

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> In article <cwoD6.33719$o9.7051318@typhoon.tampabay.rr.com>, "Scott Robert
> Ladd" <scott@coyotegulch.com> wrote:
> >The handling of NaNs is very hardware- and compiler-specific. As other's
> >here have pointed out, the Standard C++ does not include any support for
> >trapping signalling NaNs with C++ exceptions.
> ...
> >I don't believe that a cross-platform, cross-compiler solution
> >exists.
>
> This limitation in the C++ standard is evidently due to the CPU hardware
> situation.
>
> But perhaps that situation has changed, so that if signaling NaN's are
> available, one also set them to generate C++ exceptions. But then one
> would need to check the hardware situation first.
>
Well, since there's no requirement that signalling NAN's exist it would
be hard to bind them to anything.

There's nothing really that prevents an implementation from binding the
synchronous traps (floating point exceptions) to exceptions.  Some do.
You do have to resolve the interaction with SIGNAL though.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Just here MSWindows is comfortable enough.
Using

#include <eh.h>

static void my_translator(unsigned code, _EXCEPTION_POINTERS *);
static void my_translator(unsigned code, _EXCEPTION_POINTERS *)
{
 throw code;
};

  _set_se_translator(my_translator);

We transform floating point exceptions and other ones into unsigned int.

Thanks,
Alex

Hans Aberg <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-1904011122490001@du133-226.ppp.su-anst.tninet.se...
> In article <3ADE1EB4.4B742C0C@wizard.net>, "James Kuyper Jr."
> <kuyper@wizard.net> wrote:
> >> This is really the point I wanted to know: How to get a signaling NaN
> >> generate a C++ exception.
> >
> >What you have to do is investigate the implementation's documentation.
> >Unless the implementation itself provides an option for converting a
> >floating point exception into a specified C++ exception, you're probably
> >out of luck. Throwing a C++ exception from an appropriately defined
> >signal handler would render it no longer a POF (Section 18.7p5), and the
> >behavior is therefore implementation-defined. There's essentially no way
> >to do this portably.
>
> Out of luck is probably the name of the game.
>
> >> The C++ standard does not seem to give any provision for that, in the
case
> >> one now has access to floats with signaling NaN's.
> >
> >Correct.
>
> But it is fun that one has at least implemented a cosmetic version of
> signaling NaN's.
>
>   Hans Aberg      * Anti-spam: remove "remove." from email address.
>                   * Email: Hans Aberg <remove.haberg@member.ams.org>
>                   * Home Page: <http://www.matematik.su.se/~haberg/>
>                   * AMS member listing: <http://www.ams.org/cml/>
>
> ---
> [ 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://www.research.att.com/~austern/csc/faq.html                ]
>


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
>
> There's nothing really that prevents an implementation from binding the
> synchronous traps (floating point exceptions) to exceptions.  Some do.
> You do have to resolve the interaction with SIGNAL though.

The problem is that they _aren't_ synchronous on many architectures. You
can't make FP exceptions synchronous without forcing a pipeline flush
after every operation, which can be a major performance hit.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3AE06FED.74B2CE46@spamcop.net>, Ron Natalie <ron@spamcop.net> wrote:

>> But perhaps that situation has changed, so that if signaling NaN's are
>> available, one also set them to generate C++ exceptions. But then one
>> would need to check the hardware situation first.
>>
>Well, since there's no requirement that signalling NAN's exist it would
>be hard to bind them to anything.

One binds them in the cases they do exist. :-)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <mitch-9ECE91.14174920042001@news.brainstorm.net>, Mitch Adler
<mitch@intelligentparadigm.com> wrote:
>Exceptions cause optimizing compilers headaches. They have to account
>for the alternate return path that might result from any call that could
>result in an exception.
>
>If your compiler assumes that floating-point operations do not throw c++
>exceptions, it can do many optimizations that will leave variables in
>bad states if you throw exceptions from floating-point IEEE exceptional
>opererations.

My guess is that this has to do something with that the functions are not pure.

>I would highly recommend against trying to introduce any points at which
>exceptions can begin propogating that the compiler doesn't know about
>(either implicity, or explicitly with a function call boundary).

Perhaps one should add a C++ keyword "pure" telling the compiler that the
computational order can be rearranged.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3adf2d7e$1@galaxy.corning.com>, Alex <KoganOS@corning.com> wrote:

>Just here MSWindows is comfortable enough.
>Using
>
>#include <eh.h>
>
>static void my_translator(unsigned code, _EXCEPTION_POINTERS *);
>static void my_translator(unsigned code, _EXCEPTION_POINTERS *)
>{
> throw code;
>};
>
>  _set_se_translator(my_translator);
>
>We transform floating point exceptions and other ones into unsigned int.

Except that the behaviour of throwing exceptions in signal handlers
(somebody said) is undefined in C++. :-)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

The standard allows quiet and signaling NaN's. I can figure that a quiet
NaN works as a regular number, with the difference that the arithmetic
result becomes a NaN.

But how does signaling NaN work? Does it throw an exception or something.
The standard does not mention the word "signaling" except in the
numeric_limits part, where the semantics is not indicated.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

| But how does signaling NaN work? Does it throw an exception or something.
| The standard does not mention the word "signaling" except in the
| numeric_limits part, where the semantics is not indicated.

The appropriate texts to look for are IEEE-754 and LIA-1.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
...
> But how does signaling NaN work? Does it throw an exception or something.
> The standard does not mention the word "signaling" except in the
> numeric_limits part, where the semantics is not indicated.

They're specified elsewhere, in the floating point standards; as a
result, they don't necessarily apply, unless
std::numeric_limits<double>::is_iec559 is true.IEC 559 is the same as
IEEE 754, which is a specialization of IEEE 854; I didn't want to pay
for all three, and the advice I got was that 854 was the most useful one
of the three. I paid $3/page (!) for a copy of ANSI IEEE 854-1987. At
that price, I was half-expecting calligraphy. :=)  In section 6.2 it
says that

"Signaling NaNs shall be reserved operands that signal the invalid
operation exception for every operation listed in Section 5. Whether
copying a signaling NaN without change of precision signals the invalid
exception is the implementor's choice.
Every operation involving a signaling NaN or invalid operation (7.1)
shall, if no trap occurs and if a floating-point result is to be
delivered, deliver a quiet NaN as its result."

Quiet NaNs, in contrast "shall signal no exception".

Note that this is a floating point exception, not a C++ exception.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <3ADCD0BC.936B2958@wizard.net>, "James Kuyper Jr."
<kuyper@wizard.net> wrote:
>> But how does signaling NaN work? Does it throw an exception or something.
...
>They're specified elsewhere, in the floating point standards;
...
>"Signaling NaNs shall be reserved operands that signal the invalid
>operation exception for every operation listed in Section 5. Whether
>copying a signaling NaN without change of precision signals the invalid
>exception is the implementor's choice.
...
>Note that this is a floating point exception, not a C++ exception.

This is really the point I wanted to know: How to get a signaling NaN
generate a C++ exception.

The C++ standard does not seem to give any provision for that, in the case
one now has access to floats with signaling NaN's.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]