Re: [unitsml] "Float64" in UnitsML

["Peter J. Linstrom" <peter.linstrom@nist.gov>]

All,

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

   I would like to note that in the current draft
of the UnitsML schema the "Float64ConversionFrom"
element contains attributes to reflect the precision
of the numbers used in the conversion. For example
the "multiplicandDigits" attribute will indicate the
number of meaningful digits in the conversion factor.
Because of this 0.3048 or (0.3048 minus some small
number) will result in the same value.

   The rather awkward name of "Float64ConversionFrom"
was chosen to discriminate from other possible
representations of numbers for conversions. Since
the overwhelming number of conversions are linear,
I believe this is a more appropriate convention for
discriminating among conversion type rather than
linear vs. non-linear. Of course other committee
members may have other (better) ideas.

Peter Linstrom

======================================================
Peter J. Linstrom
NIST, Chemical and Biochemical Reference Data Division
Phone: (301) 975-5422
======================================================

----- Original Message ----- 
From: "Martin S. Weber" <martin.weber@nist.gov>
To: <unitsml@lists.oasis-open.org>
Sent: Tuesday, September 30, 2008 2:25 PM
Subject: Re: [unitsml] "Float64" in UnitsML


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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php