Jump to content
Mohammad Atikur Rhaman

"Divided by zero" exception

Recommended Posts

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?

Share this post


Link to post

What target? Windows, iOS, Android, Linux? 

32 or 64 bit?

In the IDE or outside?

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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

 

  • Confused 1

Share this post


Link to post

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.

Share this post


Link to post
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. 

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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". :classic_blink: 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.

Share this post


Link to post

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.

Share this post


Link to post
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 by David Heffernan

Share this post


Link to post

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.

Share this post


Link to post
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. 

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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. 

Share this post


Link to post
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.

 

 

1*PdiMsDq2SUC8hAmViSFPjQ.png

Share this post


Link to post
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....

 

 

  • Haha 1

Share this post


Link to post

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.

 

 

Share this post


Link to post
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? 

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×