Re: Divide by 0 - exception thrown?

Tech-Archive recommends: Speed Up your PC by fixing your registry

So, I must ask...

How do all of you prevent divide by 0 and overflows?

The first thing is to see if you can perform the calculation in such a way
that subexpressions don't foul up while still yielding the same answer.

I have done this as much as possible. Usually this means storing the
inverse and multiplying, when it is a commonly used constant. This also has
the advantage of additional speed.


This may be easier for integer vs. floating point calculations. Concerning
the latter, it may be easiest not to even try to prevent errors beyond the
trivial division by zero but instead to detect them when you're done. You
can leave FP exceptions masked and detect errors by checking the FPU
status
word. From memory, you will use functions like _clearfp and _statusfp.

Doug, this is precisely what I have proposed in the first post of this
thread. I was mainly concerned with reliability and portability, however.
I found that it should be reliable, as long as 3rd party code (i.e. drivers)
do not change the FPU control word and forget to change it back (I am
uncertain as when such code could be invoked, and thus when the best place
to confirm the control word is as it should be). As far as portability, so
far, due to lack of information, I can only *assume* that if other platforms
use FPUs that follow the IEEE standard, which supports NaNs, that the
hardware can be set to mask exceptions (i.e. that is, to follow the IEEE
standard). I should be able to set the compilation to fail on such
platforms, so I can find / implement their OS specific functions to ensure
the FPU control word at that time. Also, I was planning on merely using
_isnan() to check the final result to see if anything "bad" happened, but
the functions you mention could work, as well, but they'd require a little
more work (i.e. I don't considered a denormal an error; it's just a loss of
precision -- but some people could).

Thanks for your time,

--

Jason Doucette / Xona.com
www.jasondoucette.com / www.xona.com


.

Relevant Pages

  • Re: Pentium 1.8Ghz / Windows 2000 / Delphi 6 problem
    ... >>What harm does setting the control word for extended calculations do ... changing the FPU control word and not restoring it is ... there are many cases where DLL's that your app is using may have a flaw ...
    (comp.lang.pascal.delphi.misc)
  • Re: Divide by 0 - exception thrown?
    ... response stating that crashes only occurred after the printer was ... think it is more than clear this is the cause of those crashes. ... It also makes COMPLETE sense that the FPU control word is stored within the ...
    (microsoft.public.vc.language)
  • Re: Pentium 1.8Ghz / Windows 2000 / Delphi 6 problem
    ... >Some DLL perhaps sets the FPU control word wrong, like an OpenGL DLL. ... I had never had to deal with the FPU Control word before. ... double precision rather than extended precision calculations. ...
    (comp.lang.pascal.delphi.misc)