I would like to capture floating point errors.
For now in case of error the program execution follows, but you can find in the doubles, things like INF or NAN.
This behaviour is very conservative for my apps, and I'd prefer in some situations to capture these situations stopping the execution.

I have tried it unsuccessfully using:
- signal(SIGFPE, ...)
- _controlfp_s()
- _set_se_translator()

Any help will be acknowledged!

PD. Somebody could say "just check that all data is adequate before using it in division, sqrt, ...". That's true, but difficult and cumbersome in some situations using uncontrolled data sources where sometimes even doing lots of "if" to check the consistency of data, that's not enough.

CrashHandler works only in DEBUG and is connected to TheIDE so when debugging you can capture floating point (FP) and other problems. Production code could not use CrashHandler.

Division by zero and other FP errors, are errors and have to be debugged. Just imagine two situations:
- The calculation of your bank account balance is infinite

- The controller that determines the direction of your car with automatic driving sets an infinite angle

I do not want my code to fall in these situations.

Ah, that explains it. So you have like 2 weeks of experience with this issue

Yet another example, how are you going to fix this:

double SomeFunction(double x)
{
    return ln(x*x*x - 15*x*x + x + 20);
}

Now this function is used throughout your code on 50 places and you have got an exception because the argument is negative.

How are you going to fix it?

This is the main problem I have encounterd with "activate FP exception" approach and I still do not know the correct solution....

Mirek

mirek wrote on Tue, 27 October 2020 11:16

Yet another example, how are you going to fix this:

double SomeFunction(double x)
{
    return ln(x*x*x - 15*x*x + x + 20);
}

Now this function is used throughout your code on 50 places and you have got an exception because the argument is negative.

How are you going to fix it?

This is the main problem I have encounterd with "activate FP exception" approach and I still do not know the correct solution....

Mirek

In my code I would put an ASSERT to capture the error in DEBUG. Just like Vector checks if index is negative.

Yeah, so your program now does not work in debug for particular input data. What is the next step?

Quote:

Yeah, so your program now does not work in debug for particular input data. What is the next step?

The next step when TheIDE debugger breaks is to solve the problem

Quote:

Yeah, so your program now does not work in debug for particular input data. What is the next step?

The next step when TheIDE debugger breaks is to solve the problem

koldo wrote on Tue, 27 October 2020 17:18

Quote:

Yeah, so your program now does not work in debug for particular input data. What is the next step?

The next step when TheIDE debugger breaks is to solve the problem

Or if you want more practical example, take

examples/FnGraph

then activate fp exceptions, start the debugger and enter ln(x). Then tell me how you fixed the code....

Then try to imagine all the fixes you will need to make to avoid all FP exceptions and I can guarantee you two things:

a) you have probably missed something
b) the code will be about 2 times longer and much harder to maintain

Mirek

Hello,
I slowly stop understanding what this thread is about?

I think it is perfectly fine to validate input each time it can be wrong - this is the secure coding principles.

What you say is not conceivable for me. In my world a negative square root is the same as a Vector v(2); v[-1] = 2;

koldo wrote on Tue, 27 October 2020 19:25

What you say is not conceivable for me. In my world a negative square root is the same as a Vector v(2); v[-1] = 2;

Cool, then please fix example/FnGraph.

Mirek

Hello,

I slowly stop understanding what this thread is about? I think it is perfectly fine to validate input each time it can be wrong - this is the secure coding principles. So, in example bring by kold when i (-1) "v(2); v[i] = 2;", we should always check and handling appropriate. The same is true for divided by zero problem.

The only problem I have is that the CrashHandler is forced by using SysInfo package on Debug mode. For me the class should not be there in nay cases. If you would like to write such debug code just do it in your application not in the library. This is my postulate. If this code will help you find errors in your application that's fine, but use it only there.

EDIT: I saw that crash handler was removed from SysInfo. Thanks!

Klugier

mirek wrote on Tue, 27 October 2020 20:50

koldo wrote on Tue, 27 October 2020 19:25

What you say is not conceivable for me. In my world a negative square root is the same as a Vector v(2); v[-1] = 2;

Cool, then please fix example/FnGraph.

Mirek

In this case my old Casio calculator prints an error message.

Edited: Just checked with my daughter's CASIO Graph 35+E. 1/0 prints "Math ERROR. Press EXIT". Really updated, this version even comes with Python.

I am also pretty interested what will you do when you get exception in eigen. I am not that advanced in math, but I am pretty sure that e.g. matrix inversion can produce a lot of divide by zero for degenerate matrix and I am also pretty sure that eigen follows NaN model like every other mature library (if for nothing else, then for performance reasons).

Are you going to compute determinant before each call to inversion?

Mirek

mirek wrote on Wed, 28 October 2020 14:04

I am also pretty interested what will you do when you get exception in eigen. I am not that advanced in math, but I am pretty sure that e.g. matrix inversion can produce a lot of divide by zero for degenerate matrix and I am also pretty sure that eigen follows NaN model like every other mature library (if for nothing else, then for performance reasons).

Are you going to compute determinant before each call to inversion?

Mirek

I am well aware of operations that could be bad conditioned . I use a lot matrix inversion.
In fact STEM4U includes some tools to handle infinite precision numbers (well, but as expected, very inefficiently)
If you ask me if I prefer to search for NaNs after every matrix algebra operation, or catching an exception, I will choose the second.