[Insight-users] Insight-developers Digest, Vol 67, Issue 27

[Mathieu Malaterre]

On Sat, Nov 28, 2009 at 6:41 PM, Simon Warfield
<simon.warfield at childrens.harvard.edu> wrote:
> Dear Bill and Mathieu,
>
>  I notice your discussion of the handling of floating point numbers
> depending on locale.
>
>  I have been having an issue with the precision of floating point numbers,
> especially with the representation of gradient directions in diffusion
> weighted images.  I believe that all of the floating point numbers that end
> up in a non-standard key/value pair get converted to a string quite early on
> after reading (I haven't yet worked out exactly where, deep in GDCM). It
> looks like the default conversion keeps six decimal places.
>  Since the norm of the gradient of the diffusion weighted image is
> proportional to the b-value, some loss of precision makes our adjusted
> b-values slightly wrong.
>
>  I would appreciate any hint you might have about how to maintain full
> double precision representation for these types of entries.

Hi Simon,

  That is also a really good catch. Could you please log in a bug for
GDCM 1.x for that. This has been fixed in GDCM 2.x using this:

template < typename Float >
struct precision {

  static unsigned int digits ( unsigned int base ) {
    return( -
            std::log( std::numeric_limits<Float>::epsilon() )
            /
            std::log( base ) );
  }
};
template < typename Float >
unsigned int sig_digits ( Float const & ) {
  return( precision<Float>::digits(10) );
}

double x = 12.230912093719823691836;
std::cout << std::setprecision( sig_digits(x) ) << x << '\n';


ref:
http://www.archivum.info/comp.lang.c++/2005-10/03220/Re:_std::stringstream_and_floating_point_accuracy

If ITK is ever moving to newer version of the C++ standard, I believe
this could be replaced by: std::numeric_limits<double>::max_digits10

HTH
-- 
Mathieu