Re: [unitsml] "Float64" in UnitsML

["Martin S. Weber" <martin.weber@nist.gov>]

Quoting "Peter J. Linstrom" <peter.linstrom@nist.gov>:

> All,
>
>   This message is also intended to be part of the
> asynchronous portion of the September 2008 UnitsML
> TC meeting.

Same here.

>
> (...) There were several arguments in favor the
> use of double precision numbers, but as I recall
> the most persuasive was that this approach would be
> more developer friendly (and hence ease adoption
> of UnitsML).

I can see that, and I agree that we should not be using strings for  
these numbers. (but see also below)

>
>   I am not sure there is a strong case for
> representations greater than double precision.
> Conversion factors are typically of two types
>
> 1.) Conversions set by standards or rules. These
>    conversions are adopted based on conventions
>    and are typically fixed decimal point numbers
>    (e.g. an international foot is 0.3048 meters).
>    I am not aware of any of these conversions
>    which would come close to using the number
>    of digits available in double precision numbers.

That is, 15 to 16 fractional digits. I can well see how we can,  
including prefixes, scale available data down or up by 5 orders of a  
magnitude, and at some point this is going to bite us. For the example  
you gave, and given that the smallest normalized double is roughly  
10^-306, if we just look at the first 50 fractional digits we see...
  0.30480000000000001536548666081216651946306228637695

I'm not arguing against using a numeric type inside of UnitsML, I'm  
arguing for using a numeric type that, by its definition, does not  
turn a well specified number into some other number just by means of  
representation. I also don't say that people will want to input more  
than 15 or 16 fractional digits to start with. What I meant is that  
just by the fact that doubles are defined as-is in IEEE 754, we're  
pulling in errors that shouldn't be there (look above). In UnitsML  
there might stand a 0.3048, but the computer isn't computing with that  
value. It's using the value above. And Imho we shouldn't allow the  
computer to change the meaning of what we said. In that respect the  
"string" representation was better as it does not imply loss of  
precision or garbage fractional digits.
The xsd:decimal type is offering the same service.

I can see how xsd:double is easier to support in implementations for  
XML than an unbounded decimal, so this argument might well be valid.  
But the error (e.g. in the above) is obvious I think.

> (...)
>   In addition I would like to note that UnitsML
> was designed to support multiple semantics for
> conversions; it currently supports two:
> "Float64ConversionFrom" and "SpecialConversionFrom".
> Addition of a new type does not require the removal
> of an existing type. (...)

Well, that is basically the "other" issue I was talking about. In the  
"Float64ConversionFrom" we're just describing a linear equation which  
is not limited to the allowable numbers within IEEE-754 double  
precision floats. What we are describing is a "LinearConversionFrom",  
and I think we should call it like that.

So, even if we stayed with xsd:double's within UnitsML, would you have  
a problem calling the element describing the linear conversion from  
another unit "LinearConversionFrom" ?

Regards,

-Martin Weber