"Divided by zero" exception

[MDagg 0]

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.

[Joseph MItzen 251]

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)

[JSPUS 0]

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.

[Mohammad Atikur Rhaman 0]

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.

[David Heffernan 2347]

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. 

[Mohammad Atikur Rhaman 0]

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?

[David Heffernan 2347]

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. 

[Mohammad Atikur Rhaman 0]

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.

[David Heffernan 2347]

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.

[Mohammad Atikur Rhaman 0]

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.

[Koen Van de moortel 0]

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!
 

[Lajos Juhász 293]

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.

[David Heffernan 2347]

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. 

[tgbs 14]

Do You use SHDocVw from Internet ?

[Attila Kovacs 629]

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.

[tgbs 14]

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

[Attila Kovacs 629]

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

[David Heffernan 2347]

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. 

[tgbs 14]

This is simple project,  no dlls

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

ProjZero.zip

[programmerdelphi2k 237]

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?

[Attila Kovacs 629]

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.

[programmerdelphi2k 237]

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 January 24, 2023 by programmerdelphi2k

[David Heffernan 2347]

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. 

[programmerdelphi2k 237]

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

[David Heffernan 2347]

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.