divide by zero

[Troodon]

What's the type of of the expression? 1 div 0 (integer division) is indeed a EDivByZero exception, but 1 / 0 (floating point) is not. It leads to infinity as what you get.

Hm... I don't know how to read this. Infinity is not a numerical value, so division by 0 is a mathematical impossibility. Why complicate matters?

[TurboRascal]

If it departed from Delphi for all 3 operating systems, then maybe yes.  But it seems like it departs from Delphi only for OSX.

But Bart showed how he also got EDivByZero for floating point division by zero in Linux...

[TurboRascal]

Hm... I don't know how to read this. Infinity is not a numerical value, so division by 0 is a mathematical impossibility. Why complicate matters?

CPU floating point units do indeed define infinity, as +Inf and -Inf IIRC. They can also return NaN. It is therefore logical that software floating point operations that use the FPU do the same.

[Troodon]

CPU floating point units do indeed define infinity, as +Inf and -Inf IIRC. They can also return NaN. It is therefore logical that software floating point operations that use the FPU do the same.

That's funny... So, CPU makers have decided to reinvent mathematics. If one were to follow this line of reasoning then, for x = 0

(1/x = Inf) => (2/x = 2*Inf)
 
As Inf > 0 it is "obvious" that 2*Inf > Inf

How further can one push this... logic?

[TurboRascal]

Apparently it's part of the IEEE 754-2008 (Standard for Floating-Point Arithmetic)... It seems they "reinvented" it to help with numerical representations in certain circumstances... Strange as it may seem, yet also the floating point format representations in FPUs don't have much connection to the "real reals" in general math

[mbohn]

I've been doing some reading on the fpc mail list which seems to be a parallel discussion:

http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg17915.html

They talk about a mask in the mathuh.inc file but I've yet to find that file on my system.

[Troodon]

I read that post, what he wants is a division by zero "without raising an exception".

That's Perl thinking. Software running without raising exceptions by default, although the results are invalid. It's a choice, I guess.

[mbohn]

I can't see why you'd ever not want to raise an exception.  The IEEE discussions about some calculations that can survive a divide-by-zero error and should be allowed to proceed seems like total nonsense to me.  If I'm doing a resistor-in-parallel calculation and I know that it is possible for one of the resistances to be zero I'd prefer the computational efficiency of the exception handling heirarchy to that of testing for the possibility every time or to that of blithely letting the error propogate through the calculation.  

In my case it did just that and only by tediously going backwards through the calculation  sequence (without the benefit of a debugger) could I see where the problem originated.  If my try..except block had worked, I would have had zero effort.

I remember when Delphi first came out and I had the hardest time understanding the concept of try..except or try..finally.  I'd be embarrassed to tell you how long it took to sink in.  When it finally did it all seemed so elegant.  Now I'm not interested in going backwards 20 years.

[Troodon]

I can't see why you'd ever not want to raise an exception.  The IEEE discussions about some calculations that can survive a divide-by-zero error and should be allowed to proceed seems like total nonsense to me.

I totally agree with you. Not catching the result of a divide-by-zero operation as an error would entail more coding and contingency planning by the developer.

[mbohn]

That's funny... So, CPU makers have decided to reinvent mathematics. If one were to follow this line of reasoning then, for x = 0

(1/x = Inf) => (2/x = 2*Inf)
 
As Inf > 0 it is "obvious" that 2*Inf > Inf

How further can one push this... logic?

In the case of Intel, I don't think so.  They offer both the NaN and exception-raising approaches.  This is from the Intel® 64 and IA-32 Architectures, Software Developer’s Manual Volume 1:Basic Architecture:

8.5  X87 FPU FLOATING-POINT EXCEPTION CONDITIONS
8.5.3  Divide-By-Zero Exception (#Z)
When a divide-by-zero exception occurs and the exception is masked, the x87 FPU
sets the ZE flag and returns the values shown in Table 8-10. If the divide-by-zero
exception is not masked, the ZE flag is set, a software exception handler is invoked
(see Section 8.7, “Handling x87 FPU Exceptions in Software”), and the top-of-stack
pointer (TOP) and source operands remain unchanged.

I could not get the table to look right so just go to  http://www.intel.com/Assets/PDF/manual/253665.pdf

In an earlier post, Marc said that unmasking the divide-by-zero exception can result in other problems on the Mac.  I'll test that soon and report back.

[mbohn]

It seems to work with my simple test program shown earlier and with the following additions:

Code: [Select]

implementation
     uses math;
.
.

initialization
  {$I unit1.lrs}
   SetExceptionMask(GetExceptionMask-[ExZeroDivide]);
finalization
   SetExceptionMask(GetExceptionMask+[ExZeroDivide]);
end.     
I haven't seen any other strange behavior but I'll report back if I do once I implement this in my real project.

[TurboRascal]

In the case of Intel, I don't think so.  They offer both the NaN and exception-raising approaches.  This is from the Intel® 64 and IA-32 Architectures, Software Developer’s Manual Volume 1:Basic Architecture:

Oh yes, when I was talking about the IEEE standard I didn't say definitions of Inf and NaN PREVENT exceptions. Perhaps I should have remembered to say that CPU's actually DO trigger an exception when they return those values