[Insight-developers] vnl_math changes

Brad King brad.king at kitware.com
Mon Jul 19 14:21:22 EDT 2004


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


More information about the Insight-developers mailing list