Jump to content
Mohammad Atikur Rhaman

"Divided by zero" exception

Recommended Posts

Both in fact. My point is that there is viable justification for why the 754 designers chose to put 0/0 in the class of invalid operations and not in the division by zero class.

Share this post


Link to post
2 hours ago, David Heffernan said:

It's all proscribed by ieee754.

IEEE754 dictates exceptions?

 

<Should know better than to question David Heffernan; checks and finds out it's true.>

 

Wow. Interesting. Apparently several other languages ignore this... Python, Ruby and Perl all raised the same exception for either case when I just tried them. PHP returned INF or NaN and only issued a warning (good old frightening PHP). I guess my hat's off to Guido Van Rossum, Yukihiro Matsumoto and Larry Wall for doing the sensible thing rather than the "right" thing. As usual, Rasmus Lerdorf manages to zig when he should zag. 🙂

 

Also, I now formally declare my allegiance to Unums, which only have two exception types....

 

https://en.wikipedia.org/wiki/Unum_(number_format)

Share this post


Link to post

MDagg would you happen to be the mathematician with the same name that writes solutions on the berkeley.edu website? Just curious.

 

If so then I didn't know you used Delphi since I don't recall you ever mentioning Delphi there. I guess Delphi is more popular than I thought.

Share this post


Link to post
On 5/6/2021 at 10:56 PM, 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.

Could you please tell me how to identify the DLL that changes the floating point control status to mask exceptions.
Reiterating that this issue occurring after we mover our project form Delphi Seattle to Delphi Sydney. our project was working fine on Delphi Seattle.

Share this post


Link to post
4 hours ago, Mohammad Atikur Rhaman said:

Could you please tell me how to identify the DLL that changes the floating point control status to mask exceptions.
Reiterating that this issue occurring after we mover our project form Delphi Seattle to Delphi Sydney. our project was working fine on Delphi Seattle.

Step 1 is to inspect the state of the floating point exception masks while your program is executing. Use trace debugging to do that. Check whether or not my hypothesis is correct. 

Share this post


Link to post
On 5/11/2021 at 6:40 PM, David Heffernan said:

Step 1 is to inspect the state of the floating point exception masks while your program is executing. Use trace debugging to do that. Check whether or not my hypothesis is correct. 

Sorry for the late reply, I couldn't get back to this issue due to other priority work.

We’ve traced down floating point exception masks at the initialization of our project. We’ve found [exInvalidOp,exDenormalized,exZeroDivide,exOverflow,exUnderflow,exPrecision] this set of exceptions is already masked on our project. 
For more confirmation we’ve created a new VCL application and traced down floating point exceptions. This time the set was [exDenormalized,exUnderflow,exPrecision]. 

Could you please tell us if there is any project setting or something that we can remove the ‘exZeroDivide’ exception from this set or get back to the default floating point exceptions?

Share this post


Link to post
21 minutes ago, Mohammad Atikur Rhaman said:

Could you please tell us if there is any project setting or something that we can remove the ‘exZeroDivide’ exception from this set or get back to the default floating point exceptions?

This isn't to do with project settings. These settings are owned by the thread and something is changing them. By the sounds of it that something is an external DLL. If so you need to save the fp control word before you call the dll and restore that saved value when the dll call returns. 

Share this post


Link to post
38 minutes ago, David Heffernan said:

This isn't to do with project settings. These settings are owned by the thread and something is changing them. By the sounds of it that something is an external DLL. If so you need to save the fp control word before you call the dll and restore that saved value when the dll call returns. 

Thank you, we'll try to figure out how to set our exception mask as needed in our code.

Share this post


Link to post

For 32 bit it's just Get8087CW and Set8087CW, but your real problem is still identifying the specific point in the code where it is changed.

Share this post


Link to post
58 minutes ago, David Heffernan said:

For 32 bit it's just Get8087CW and Set8087CW, but your real problem is still identifying the specific point in the code where it is changed.

Okay. we'll definitely looks on those point.

Share this post


Link to post

I had the same problem!  In Delphi 10.4 the compiler directives {$Q+} or {$R+} don't seem to have any effect anymore. 

The only thing that seems to make try... except to work like it should, is System.Math.SetExceptionMask([exPrecision]);

But you have to add this in every procedure, since apparently many procedures (from Delphi/Windows???) arrogantly set all the masks without removing them!
I have no idea why this has become the default, since it makes all "try... except" blocks totally useless!

And... very weird, but don't do this: System.Math.SetExceptionMask([]);  !!!


System.Math.SetExceptionMask([]);
x:=2; y:=exp(x);  // TOTAL PROGRAM CRASH!!!

Why?????????????  I have no clue!  It looks like a bug to me!
 

Share this post


Link to post
11 minutes ago, Koen Van de moortel said:

In Delphi 10.4 the compiler directives {$Q+} or {$R+} don't seem to have any effect anymore. 

$Q = Overflow checking (Delphi)

$R = Range checking

 

These directives are working and have their meaning just have nothing to do with ExceptionMask they are different things.

Share this post


Link to post
3 hours ago, Koen Van de moortel said:

I had the same problem!  In Delphi 10.4 the compiler directives {$Q+} or {$R+} don't seem to have any effect anymore. 

The only thing that seems to make try... except to work like it should, is System.Math.SetExceptionMask([exPrecision]);

But you have to add this in every procedure, since apparently many procedures (from Delphi/Windows???) arrogantly set all the masks without removing them!
I have no idea why this has become the default, since it makes all "try... except" blocks totally useless!

And... very weird, but don't do this: System.Math.SetExceptionMask([]);  !!!


System.Math.SetExceptionMask([]);
x:=2; y:=exp(x);  // TOTAL PROGRAM CRASH!!!

Why?????????????  I have no clue!  It looks like a bug to me!
 

There's an awful lot of misunderstanding here. In order to help you we'd need to see some concrete examples. 

Share this post


Link to post
13 minutes ago, tgbs said:

Do You use SHDocVw from Internet ?

Why "from Internet"? What is the difference? The official one also turns off math exceptions.

Share this post


Link to post

I meant SHDocVw from source/internet. If for some reason it is used in the project, division by zero does not occur with a win32 app in try except block

Share this post


Link to post
13 minutes ago, tgbs said:

If for some reason it is used in the project

yup, explorer used it, not sure about the new edge thing

Share this post


Link to post
2 hours ago, tgbs said:

I meant SHDocVw from source/internet. If for some reason it is used in the project, division by zero does not occur with a win32 app in try except block

Floating point exceptions got masked by the library you used. We've covered this hundreds of times here and elsewhere. Some websearch will reveal more. 

Share this post


Link to post

This is simple project,  no dlls

In unit3 is uses for SHDocVw. Please try with and without this uses.

ProjZero.zip

Share this post


Link to post

hi folk,

 

I have a question within the scope of this topic (and from a layman in mathematics concepts): in which moment or scenario, it would be interesting to "don't throw an exception (number/0=OK go ahead, see you later)"?  

that is, would this not imply an error of even greater consequence later, if no way of "stopping" the process was done immediately?

Share this post


Link to post
23 minutes ago, programmerdelphi2k said:

"stopping" the process was done immediately

If you are working with dll's you will not throw such exceptions into the air.

Share this post


Link to post

as said Phill Collins: "...Can you feel it coming in the air tonight, oh lord, oh lord... Well I've been waiting for this moment for all my life, oh lord, oh lord"

  • I think that I would can ... and would kill it...

but the question is: where "number/0" would be acceptable allowing to continue the task?

  • this the question in my question!
Edited by programmerdelphi2k

Share this post


Link to post
10 hours ago, programmerdelphi2k said:

but the question is: where "number/0" would be acceptable allowing to continue the task?

In a programming language that didn't have exceptions. Like C. 

 

It's then up to the programmer to check if the operation failed. Inspect the FPU status word to do that. 

Share this post


Link to post
1 hour ago, programmerdelphi2k said:

ok, then, the answer "in simple term" is: not acceptable! break now, dont hurt me later! 

this would be my point, from "layman"-math

thanks

In a language without exceptions, how do you implement your proposed solution? Answer, you can't. 

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

×