Subject: Code problem resolution

From: "Sean Wall, x3736" <[email-masked]>
Date: Thu, 4 Mar 93 08:41:46 EST

Hi,

        Well, I fixed that problem I was having.  And it was something stupid.
It was a combination of dumbness on my part and poor documentation on
Borland's part!
        The problem WAS in fact a math exeception.  Particularly, it was
a domain error in the acos() function.  acos() expects input in the range
[-1,1] and although the math I was performing should have ensured that,
a BIG oversight on my part was letting bad input through.  You know the
rest, "garbage in, garbage out".  However, I had been using the matherr()
function to trap math errors and the signal() function to trap FPU
divide by zeroes. It wasn't until I linked in the emulation libs that
matherr() was called to flag the acos() error.  Apparently,  matherr()
will trap domain and range errors ONLY in the emulation library and not
in the FPU (this kind of makes sense...)  Since no divide by zeros were
occuring, signal() never trapped anything.  After putting in some limiting
code, everything now runs fine.  What a mess!!!  The on-line docs
state that matherr() will trap function errors in the floating point
library.  Stress "library"!!!!  Nowhere in the docs (as far as I can tell)
does it clearly state "matherr() will not trap math errors in the FPU".
Maybe it does and I'm just not using it right.  Who knows??!!!

        I figured I'd pass this tale of woe on to you, gentle reader,
in case anyone else might run into the same problem.

-Sean
([email-masked])

P.S. - Kudos to Dave Stampe who suggested linking in the emulation library
       as a possible fix.  Yes Dave, it was one of those "neat bugs"
       that Borland likes to slip in.  (I think...)