A few floating point issues

[Vinny]

I have a few floating point questions/issues I wish to ask. An answer or
discussion would be nice too Any links discussion the subject would be
nice too..

1. How do I generate an underflow exception for testing purposes?


2. What is the fastest wat to suppress floating point exceptions?
Take the following situation as example.
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow exception

I could use exception handling like so:
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

try {
z = x / y; // this should generate a overflow exception
}
catch( EOverflow &eo ) {
//do anything
z = 1.0e38;
}
catch( EZeroDivide &ez ) {
//do anything
z = 1.0e38;
}
catch( EUnderflow &eu ) {
//do anything
z = 0.0;
}


Or is there a better method?



3. This one is weird and may be my compiler itself. When i use the next
example (same as the first one) and compile it for debugging or release i
sometimes get an exception and sometimes i don't. If it didn't and i was
in debug mode, I notice the value of z was unchanged. No matter what the
"useless assignment"'s value was.

float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow


Thanks in advance..
Greetz,
Vinny

 

[Victor Bazarov]

I have a few floating point questions/issues I wish to ask. An answer or
discussion would be nice too Any links discussion the subject would be
nice too..

1. How do I generate an underflow exception for testing purposes?

I don't think there is a certain way, but you could try...

Divide a small number by a big number, like

double a = 1e-200;
double b = 1e200;
double ab = a / b;

2. What is the fastest wat to suppress floating point exceptions?

The language doesn't have any means to do that. They are platform-
specific, I believe.

Take the following situation as example.
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow exception
Hopefully.

I could use exception handling like so:
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

try {
z = x / y; // this should generate a overflow exception
}
catch( EOverflow &eo ) {
//do anything
z = 1.0e38;
}
catch( EZeroDivide &ez ) {
//do anything
z = 1.0e38;
}
catch( EUnderflow &eu ) {
//do anything
z = 0.0;
}

I don't think so. What's EOverflow? What's EZeroDivide? Those are
not Standard types.

Or is there a better method?

You'd have to ask in a newsgroup for your compiler.

3. This one is weird and may be my compiler itself. When i use the next
example (same as the first one) and compile it for debugging or release i
sometimes get an exception and sometimes i don't. If it didn't and i was
in debug mode, I notice the value of z was unchanged. No matter what the
"useless assignment"'s value was.

float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow

Again, the language doesn't really have any way of capturing hardware
exceptions like floating point errors. Perhaps the documentation for your
compiler has some information...

V

 

[Vinny]

I don't think there is a certain way, but you could try...

Divide a small number by a big number, like

double a = 1e-200;
double b = 1e200;
double ab = a / b;

I kinda tried that. Didn't help.

The language doesn't have any means to do that. They are platform-
specific, I believe.


I don't think so. What's EOverflow? What's EZeroDivide? Those are
not Standard types.

Sorry. This was from testing in BCB6. But i assumed catching those
exceptions are possible on other compilers as well and people would get
the idea But assuming it wasn't borland. There must be a way to catch
those acceptions? or am i wrong?

You'd have to ask in a newsgroup for your compiler.


Again, the language doesn't really have any way of capturing hardware
exceptions like floating point errors. Perhaps the documentation for
your compiler has some information...

V

So i guess the exception handling is compiler specific. I kinda guess
your write. *Getting flashbacks of some nasty assembly experiences with
division by zero errors*

 

[John Harrison]

Sorry. This was from testing in BCB6. But i assumed catching those
exceptions are possible on other compilers as well and people would get
the idea But assuming it wasn't borland. There must be a way to catch
those acceptions? or am i wrong?

What you are wrong about is assuming that these exception exist anywhere
other than in Borland. C++ defines no standard means of dealling with
floating point exceptions at all. It does not even define that floating
point exceptions exist. It is all compiler specific. Perhaps you should ask
on a Borland newsgroup.

john

 

[Real Name]

[snip]

On most plattforms you need to activate FPU-Exceptions first. For windows
you need

_control87( 0, _EM_INVALID | _EM_DENORMAL | _EM_ZERODIVIDE | _EM_OVERFLOW | _EM_UNDERFLOW);
_clearfp();

somewhere before you try to generate an exception.

 

[Lionel B]

I have a few floating point questions/issues I wish to ask. An answer or
discussion would be nice too Any links discussion the subject would be
nice too..

First off, there's bound to be some confusion here: floating point
"exceptions" in the Standard C library sense - technically the IEEE 754
standard - are not (necessarily) "exceptions" in the C++ sense.

I'm not sure exactly what the IEEE 754 standard says, but generally
under an IEEE 754 exception a floating point "status word" will be set
to indicate the problem. How you access this status word will almost
certainly be compiler/system-dependent.

On some sytems you may be able to set "traps" for floating-point
exceptions; this should cause a SIGFPE signal to be raised (the default
action of which, if not handled, is probably to abort your program) in
the case of an IEEE 754 fp exception.

On some systems (yours, by the looks of it) your C++ compiler might be
persuaded to throw C++ exceptions in the case of IEEE 754 fp
exceptions.

1. How do I generate an underflow exception for testing purposes?

This is - as are many floating point issues - probably
architecture/compiler dependent. However, you could try:

#include <cmath>

std::exp(-1000.0);

This certainly *should* cause underflow (!)

2. What is the fastest wat to suppress floating point exceptions?

Not sure quite what you mean by "supress", but see above... if you're
not trapping exceptions or throwing C++ exceptions, then by default
nothing happens apart from the fp status word being set (which you are
free to ignore). Your compiler might even allow you to "turn off" the
fp status word setting (although this would break some standards
compliance, I guess). Gnu gcc, for example, allows this as an
optimisation option, IIRC.

Take the following situation as example.
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow exception

I could use exception handling like so:
float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

try {
z = x / y; // this should generate a overflow exception
}
catch( EOverflow &eo ) {
//do anything
z = 1.0e38;
}
catch( EZeroDivide &ez ) {
//do anything
z = 1.0e38;
}
catch( EUnderflow &eu ) {
//do anything
z = 0.0;
}

I don't know what your compiler/system are, and have no idea what the
(apparently C++) exceptions EOverflow, etc. are. This is not standard
C++.

Or is there a better method?

See above - check if your compiler allows you to turn off fp exception
handling.

3. This one is weird and may be my compiler itself. When i use the next
example (same as the first one) and compile it for debugging or release i
sometimes get an exception and sometimes i don't. If it didn't and i was
in debug mode, I notice the value of z was unchanged. No matter what the
"useless assignment"'s value was.

float x = 1.0e38, //max float value
y = 1.0e-45, //min float value
z = 0.0f; //useless assignment

z = x / y; // this should generate a overflow

Be interested to know what your system/compiler are, and what compiler
flags are set for "release" and "debug".

Regards,

 

[Vinny]

Be interested to know what your system/compiler are, and what compiler
flags are set for "release" and "debug".

Regards,

Read my reactor to Victor. It contains the answers you request

Compiler = BCB6
the example code was within a simpel onclick event. But it was just an
example If other compilers work fine with the code i guess i must have
made a stupid mistake somewhere.

Greetz
Vincent

 

[Vinny]

[snip]

On most plattforms you need to activate FPU-Exceptions first. For
windows you need

_control87( 0, _EM_INVALID | _EM_DENORMAL | _EM_ZERODIVIDE |
_EM_OVERFLOW | _EM_UNDERFLOW); _clearfp();

somewhere before you try to generate an exception.

I recognize this code from some OpenGL code I once was trying.
But if there is a way to activate them, is there not a way to deactivate
them?

Greetz
Vincent

 

[Vinny]

_control87( 0, _EM_INVALID | _EM_DENORMAL | _EM_ZERODIVIDE |
_EM_OVERFLOW | _EM_UNDERFLOW); _clearfp();

Ok, I found this on the INet. It says borland but is this also compiler
specific?
Greetz Vincent

---------------------------------------------------------------------------
EXCEPTIONS

Math exceptions and access violations will occasionally cause your OpenGL
applications to abort. By default, MS ignores floating point exceptions;
Borland does not. Add the following line to the initialization section of
your code:

_control87(MCW_EM, MCW_EM); /* defined in float.h */

It will disable Borland's floating point exception handlers.

Windows 9x applications may need to call

_clear87();
_control87(MCW_EM, MCW_EM); /* defined in float.h */

before each frame is rendered.

---------------------------------------------------------------------------

 

[Victor Bazarov]

Ok, I found this on the INet. It says borland but is this also compiler
specific?

Yes, it is. Quite. 'borland.public.cppbuilder.language' awaits you.

V

 

[Vinny]

Ok.. Thanks everyone.. Didn't know all of it was so compiler specific..

I learned alot about floating points ( and my compiler )

Vincent