"Divided by zero" exception

[Mohammad Atikur Rhaman 0]

Our project was throwing "Divided by zero" exception fine when we were in Delphi Seattle IDE. Now As we have moved to Delphi Sydney IDE, the exception is no longer working, instead of that variable is now being set to INF. We have tried the exception mask to enable the exception but that doesn't satisfy our requirements. Is there a better solution than this like changing IDE , compiler or project setting?

[Lars Fosdal 1793]

What target? Windows, iOS, Android, Linux? 

32 or 64 bit?

In the IDE or outside?

[Vandrovnik 215]

And what is wrong with SetExcepionMask to desired value?

http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Math.SetExceptionMask

[David Heffernan 2353]

Probably you are calling some code, typically in a DLL, which changes the floating point control status to mask exceptions. Delphi default is for them to be unmasked, but most other Windows dev tools mask them.

[Mohammad Atikur Rhaman 0]

On 5/6/2021 at 5:51 PM, Lars Fosdal said:

What target? Windows, iOS, Android, Linux? 

32 or 64 bit?

In the IDE or outside?

Our target is Windows 32 bit in the IDE

[Mohammad Atikur Rhaman 0]

On 5/6/2021 at 6:00 PM, Vandrovnik said:

And what is wrong with SetExcepionMask to desired value?

http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Math.SetExceptionMask

It doesn't throw exception on zero divided zero scenario.

[Mohammad Atikur Rhaman 0]

23 hours ago, David Heffernan said:

Probably you are calling some code, typically in a DLL, which changes the floating point control status to mask exceptions. Delphi default is for them to be unmasked, but most other Windows dev tools mask them.

But previously at Delphi Seattle IDE it was working fine. It stopped working when we moved to Delphi Sydney IDE.

[Vandrovnik 215]

In Delphi 10.4.2, this:

 

uses
  System.SysUtils,
  System.Math;

var a, b, c: double;

begin

try
 SetExceptionMask([]);
 a:=0;
 b:=0;
 c:=a/b;
 Writeln(c);
except
 on E: Exception do Writeln(E.ClassName, ': ', E.Message);
end;

Readln;
SetExceptionMask(exAllArithmeticExceptions);

 

raises the exception:

EInvalidOp: Invalid floating point operation

 

When "a" is 1, the exception is:

EZeroDivide: Floating point division by zero

 

When I do not call "SetExceptionMask(exAllArithmeticExceptions);" in the end, I get:

Runtime error 216 at 004067EA

 

[MDagg 0]

Note that 0/0 is an indeterminate form whereas 1/0 is undefined. This is the reason why the errors are different. The Intel FPU does recognize indeterminate forms.

[David Heffernan 2353]

3 hours ago, Mohammad Atikur Rhaman said:

But previously at Delphi Seattle IDE it was working fine. It stopped working when we moved to Delphi Sydney IDE.

Do yourself a favour and check whether exceptions are masked in the two programs at the point where exveptions are raised. 

[Joseph MItzen 252]

2 hours ago, MDagg said:

Note that 0/0 is an indeterminate form whereas 1/0 is undefined. This is the reason why the errors are different. The Intel FPU does recognize indeterminate forms.

Division by zero is division by zero, whether it's 0 / 0 or 1 / 0.

[Vandrovnik 215]

8 minutes ago, Joseph MItzen said:

Division by zero is division by zero, whether it's 0 / 0 or 1 / 0.

Try 1/0 and 0/0 on Wolfram Alpha: https://www.wolframalpha.com/input/?i=0%2F0

[Joseph MItzen 252]

1 minute ago, Vandrovnik said:

Try 1/0 and 0/0 on Wolfram Alpha: https://www.wolframalpha.com/input/?i=0%2F0

Today I learned 1 / 0 is "complex infinity". Perhaps I should have written "If an exception is called 'division by zero' it should be raised for any division by zero regardless of the numerator otherwise its name is misleading."

 

I just checked and SymPy live gives the same complex infinity symbol for 1 / 0 while CoCalc & SageCell (powered by SageMath) raises a traditional "rational division by zero" exception for each. Wolfram and SymPy seem to be more math-oriented while SageMath is more programming-oriented I guess.

[MDagg 0]

That's only true is you are working in the complex field. Most computer algebra programs work in the complex field by default.

 

In the real field 1/0 is undefined.

[David Heffernan 2353]

38 minutes ago, Joseph MItzen said:

Division by zero is division by zero, whether it's 0 / 0 or 1 / 0.

Well, for ieee754 the former is NaN and the latter is +inf. 

 

Edited May 7, 2021 by David Heffernan

[MDagg 0]

Indeed... they did that for making the distinction but I wouldn't suggest using NaN to identify indetermine forms as sqrt(-1) over the reals will get you NaN but its not an indetermine form.

[David Heffernan 2353]

6 minutes ago, MDagg said:

Indeed... they did that for making the distinction but I wouldn't suggest using NaN to identify indetermine forms as sqrt(-1) over the reals will get you NaN but its not an indetermine form.

I'm not recommending anything. I'm just stating how ieee754 defines these operations. 

[MDagg 0]

Sure.. I know but I have seen some try to use them to identify results and I didn't want anyone to take what I stated to try to identify indeterminate forms.

[Joseph MItzen 252]

24 minutes ago, David Heffernan said:

Well, for ieee754 the former is NaN and the latter is +inf. 

 

What I meant to say was that if an exception is called "division by zero" it should be raised for any division by zero or else renamed.

[David Heffernan 2353]

2 minutes ago, Joseph MItzen said:

What I meant to say was that if an exception is called "division by zero" it should be raised for any division by zero or else renamed.

Well, this depends on whether or not exceptions are masked. 

[Joseph MItzen 252]

28 minutes ago, David Heffernan said:

Well, for ieee754 the former is NaN and the latter is +inf. 

 

And for Ahaan Sharma it's not a problem at all.

 

 

[Joseph MItzen 252]

2 minutes ago, David Heffernan said:

Well, this depends on whether or not exceptions are masked. 

OK, let me try this then...

Vandrovnik's code example raised different exceptions depending upon whether 0 / 0 or 1 / 0 was attempted, with no exceptions masked or calls to outside libraries. MDagg seemed to be justifying this because of the two returning different results. In that context I felt that they should both have raised a "division by zero" exception since that was what was attempted in both cases, regardless of returned value.

 

And that's all I have to say on the subject lest I start thinking that 7 * 13 = 28....

 

 

[MDagg 0]

It is worth knowing that from real analysis that 0/0 is a symbol and not a division at all. One could attempt a clever argument that lim 0/x as x-->0 means the same thing as lim 1/x as x-->0 but it does not.

 

All  indeterminate forms over the reals are symbols, not operations.

 

 

[David Heffernan 2353]

3 minutes ago, MDagg said:

It is worth knowing that from real analysis that 0/0 is a symbol and not a division at all. One could attempt a clever argument that lim 0/x as x-->0 means the same thing as lim 1/x as x-->0 but it does not.

 

All  indeterminate forms over the reals are symbols, not operations.

 

 

Are you talking about maths, or talking about ieee754? 

[David Heffernan 2353]

8 minutes ago, Joseph MItzen said:

Vandrovnik's code example raised different exceptions depending upon whether 0 / 0 or 1 / 0 was attempted, with no exceptions masked or calls to outside libraries.

It's all proscribed by ieee754.