'Floating point division by zero' when running script

[Guest]

Hello,

 

I am starting playing with 'P4D', and I am using 'PyScripter' to test the scripts that I'll eventually use in my Delphi applications. I have some questions because of an error I got when running one script:

 

1) Is 'Demo01' supposedly to run without problems every script that you can run through 'PyScripter'? I have a script that runs flawlessly on 'PyScripter' but it is raising 'Floating point division by zero' error when running with 'Demo01' on 'P4D';

2) Is there some limitation on the scripts that 'P4D' can execute?

I am using Delphi 10.3.3

 

Thank you for any help.

 

  Regards,

  Joao Lira.

Edited January 6, 2022 by Guest

[David Heffernan 2345]

This is just going to be the age old issue that most Windows code expects floating point exceptions to be masked, and Delphi's RTL unmasks them. So, mask floating point exceptions when you call into Python, and unmask them when the Python call returns. Or just mask them always if you don't care about floating point exceptions.

 

Of course, the floating point support for changing floating point control state is not thread safe in the Delphi RTL as I have been saying for more than a decade now.

[pyscripter 689]

 

9 hours ago, David Heffernan said:

mask floating point exceptions when you call into Python,

P4D provides the MaskFPUExceptions function for that purpose.

[Guest]

Thank you, David and pyscripter!

 

I didn't know about this 'MaskFPUExceptions procedure. I am still studying 'P4D', so I will take a while to use it without consulting the available stuff about it.  I like demos as a complement to new knowledge, but I learn more when I read, haha! Is there some book you wrote and we can purchase about 'Python4Delphi' pyscripter? Have you thought about it as a way to support even more this GREAT project? 'Python4Delphi' is, without doubt, one of the GREAT pieces of Delphi software EVER! Kudos to you!

After calling 'MaskFPUExceptions' before and after the 'PythonEngine1.ExecString' it worked as expected!

 

Regards,

Joao Lira.

[Roger Cigol 103]

On 1/6/2022 at 4:47 PM, David Heffernan said:

Of course, the floating point support for changing floating point control state is not thread safe in the Delphi RTL as I have been saying for more than a decade now.

I am very worried by David H's posting here. But also this could explain an issue I've had on a system for a long time that calls a 3rd party dll that I suspect creates it's own threads. This seems to at random times generate unexpected windows "exception" messages.

The documentation at https://docwiki.embarcadero.com/RADStudio/Alexandria/en/About_Floating-Point_Arithmetic is pretty good at telling you HOW to change floating point exceptions but not at all clear at what to set them to!

Do you recommend when calling external 3rd party dlls that you make a call to SetExceptions() with a value of zero, storing the result (the current settings) into some local variable) before calling the 3rd party dll and then a call to SetExceptions passing the value saved in the local value as soon as the dll completes ?

You may well choose to answer as an experienced Delphi programmer - any advice for me writting in C++ (using classic,, clang32 and clang64 compilers for different apps) would be welcome too.

Thinking about the mulit-threading floating point interaction, surely the only way to achieve this would be to make sure the floating point unit is correctly configured before every floating point operation - a major overhead. I am still pondering this....

[David Heffernan 2345]

53 minutes ago, Roger Cigol said:

Do you recommend when calling external 3rd party dlls that you make a call to SetExceptions() with a value of zero, storing the result (the current settings) into some local variable) before calling the 3rd party dll and then a call to SetExceptions passing the value saved in the local value as soon as the dll completes ?

I set the floating point control state to the Windows default (which masks exceptions) before calling any external library, and then restore it when those calls return. In order for this to work reliably in a multi-threaded environment you need to do some serious RTL patching to fix the thread safety issues.

53 minutes ago, Roger Cigol said:

Thinking about the mulit-threading floating point interaction, surely the only way to achieve this would be to make sure the floating point unit is correctly configured before every floating point operation - a major overhead. I am still pondering this....

No, it is possible to fix the RTL so that you don't require such an invasive solution as you imagine. My numerical software does this.

 

Many years ago I submitted a QC report with the attached document which explains how to fix it. Embarcadero have done nothing yet, although deleting QC meant that my report disappeared from public view!

Rethinking Delphi Floating Point Control Register Management.pdf

Edited February 3, 2022 by David Heffernan

[Roger Cigol 103]

[pdf] That's a very interesting read, thank you

I think your statement about what you do to the floating point control state is what I am trying to achieve with my use of the two SetExceptions() calls.

[Roger Cigol 103]

Hi @David Heffernan, My pondering continued (and continues). Can you confirm that I am correct in concluding that it is the application (ie task) responsibility to maintain the correct FPU exception settings amongst threads it uses but it is the operating system's responsibility to maintain the FPU settings when process time is switched from one task to another. If this is the case then this makes sense to me and explains why applying the fixes so well outlined in your pdf would make a lot of sense.

[David Heffernan 2345]

Yes, through context switches the OS preserves the CPU and FPU state which is part of the thread context