[Dcmlib] not using double for high precision

[Mathieu Malaterre]

Jean-Pierre ROUX wrote:
> At 15:52 -0500 5/03/07, Mathieu Malaterre wrote:
>> Dennis wrote:
>> > Hi,
>> >
>> > In gdcm::File, float File::GetXOrigin() will lost some precision. I
>> > think it should provide as: double File::GetXOrigin()...
>> > for example, if -13.1 is converted to float in GetXOrigin(), actually
>> > it will return as -13.1000000381470.
>>
>> No :)
>> In the next generation of GDCM, it will be much more strongly typed. If
>> the DICOM standard specify a Tag should be expressed as 16bits floating,
> 
> --> Mathieu : float are 32 bits longs ;-)

ooops :)

> But the problem remains :
> 'Pixels Spacing' is expressed as 'decimal string' e.g. : "3.5\3.5"
> So is 'Image Position (Patient)'.
> If we loose information at conversion time because of the float/double 
> (32bits/64bits) problems, we loose information.
> (OK, it's only a 0.0000001 percent error, but the result looks strange, 
> doesn't it?)

I am pretty sure this is just because you cannot represent those values. 
For instance start a python shell and type:

python> 0.1
it should return
0.10000000000000001


>>
>> we should return from a function with the most appropriate c++ type: 
>> float.
>> So in conclusion, no you are not loosing precision, you are explicitly
>> made aware by GDCM of the DICOM standard :)
> 
> This is true for the 'Float' Value Representation, not for the 'Decimal 
> String' VR.


Ok I'll have to think a little more about it.

Thanks for the comments,
-M