[Insight-developers] vnl_math changes

[Hans Johnson]

Brad,

The error with intel 8 compiler is that the finite function is
overloaded to take either float or double, but not long double.  The
float version simply calls finitef.  In order to work around this, I
thought it would be most appropriate to test for finitef finite, and
finitel separately. I also thought that the VNL_HAS_IEEEFP was a
parallel construct that should also test for these separatly.

The real problem is that the original code will not compile because of
the ambiguous call to finite(double xxx) or finite(float xxx) when xxx
is a long double.

All the VNL_*_IEEEFP changes could be reverted back, as I now know they
are not used on the intel 8, or gcc platforms.

Hans



On Mon, 2004-07-19 at 13:21, Brad King wrote:
> Hans Johnson wrote:
> > Brad,
> > 
> > I was not having problems on any of my platforms.  I have no platforms
> > that have or requires VXL_HAS_IEEEFP  I implemented those changes based
> > on your comments:
> > 
> >>Hi Hans,
> >>
> >>I think you may have forgotten to commit some of these changes.
> >>Somehow the variables like VXL_IEEEFP_HAS_FINITEF need to be mapped >to
> >>VNL_HAS_NO_FINITEF.
> >>
> >>-Brad
> 
> This comment was meant to point out that you have the test for 
> VXL_IEEEFP_HAS_FINITEF but never use the result.  I assumed that you had 
> meant to put in a connection to VNL_HAS_NO_FINITEF but didn't commit the 
> change.
> 
> > From your earlier comments, I took the rule to be "If VXL_HAS_IEEEFP_H
> > version of floating point is being used, or nothing else is defineed, be
> > sure that [FL ] is defined".  I also think that it is odd that the isnan
> > functions are redefined based on if VNL_HAS_NO_FINITE is defined. 
> > Shouldn't this depend on a new declaration of VNL_HAS_NO_ISNAN?
> > 
> > I think that the VNL_HAS_NO_FINITE could probably be completely
> > eliminated from this file.   Either you are using VCL_VC, VCL_BORLAND,
> > VXL_C_MATH, or VXL_IEEEFP_H.  The VNL_HAS_NO_FINITE is really a
> > VNL_HAS_NO_SINGLE_DOUBLE_LONG_DIFFERENTIATION_FUNCTIONS.
> > 
> > In some places the #if are dependant on the value of the variable, and
> > in some cases it is dependant on if the variable is defined.  I would
> > propose that this be made consistent.
> > 
> > Let me know how you would like me to proceed.
> > 
> > Hans
> > 
> > PS:  What I am really trying to accomplish is differentiation between
> > single, double, and long versions of finite.
> 
> About 6 months ago I set out to implement a completely new version of 
> this file.  The basic problem is that the isnan and finite have many 
> variations and the calls do not work properly on all platforms even when 
> they are defined (the Mac produces a wrong answer in a few cases IIRC). 
>   I started implementing a fail-safe version that decodes the IEEE 
> floating-point layout at build-time and generates a correct 
> implementation of each function.  However, I then discovered that "long 
> double" is not always IEEE conforming (it is not on x86, for example).
> 
> In the end I gave up and said it wasn't worth the time until we 
> encountered a real problem.  Have you encountered one?
> 
> -Brad
>