Tim,
As I understand things, the original purpose of the signal handling
in primdat was so that VAL__BADx values would be returned to the
application code if a numerical exception occurs. This was useful stuff,
and its present failure leads to loads of problems with inf and NaN
not being spotted and consequently being propagated into numerical
calculations, etc.
But I can't help thinking that any change to the system would only really
be of value if it re-instated this behaviour. If I understand your
suggestion, it would still end up with inf and NaN being delivered
to the code, rather than VAL__BADx. So what's do we gain?
David
On Wed, 6 Oct 2004, Tim Jenness wrote:
> At the risk of getting flamed again for talking about obsolete
> software....
>
> Is the fact that floating point exception handling is not working within
> primdat on Linux seen as a bug or a feature?
>
> ie has the software now migrated to dealing with Inf and NaN or should
> PRM be "fixed"? I see that kaplibs has routiens for testing Inf and NaN
> but I'm not sure if they are used everywhere. The fact that NUM_ERROR is
> present in code suggests that there is a demand for it.
>
> Anyway, my point is that
>
> 1. C99 supports fine grained testing of floating point exceptions
> (Without a SIGFPE being triggered)
>
> 2. NUM_ERROR now has a function interface rather than a raw common block
> interface
>
> The above two points indicate to me that it should be fairly simple to
> reinstate floating point exception handling again simply by
>
> 1. Throwing away NUM_CMN completely
>
> 2. Make NUM_CLEARERR call feclearexcept (FE_ALL_EXCEPT);
>
> 3. Make NUM_WASOK do something like:
>
> raised = fetestexcept (FE_ALL_EXCEPT );
>
> 4. Make NUM_GETERR do something like
>
> raised = fetestexcept (FE_ALL_EXCEPT );
>
> if (raised & FE_DIVBYZERO) return PRM__INTDZ;
>
> This may well cause surprise for people that are registering their own
> numeric handler routines (Which will no longer be called).
>
> Note that in the new scheme, you will still get Inf and NaN
> (no SIGFPE), you'll just be able to spot the exception without checking
> whether you got Inf or NaN excplicitly (using the kaplibs routines).
> But in that case VEC_ is lying since it will never insert bad pixels
> and so an additional loop will always be required to fix up Nan/Inf to be
> bad values.
>
> Obviously people may also object that the PRM routines will now all have
> to use a function call rather than an inline common block access. [I
> imagine we need to benchmark ccdpack after making the change]
>
> Currently, I can only trigger the SIGFPE if NUM_WASOK does it itself
> on the basis of the C99 exception test.
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
