VOunits draft

[Rob Seaman]

On May 24, 2009, at 4:11 PM, Francois Ochsenbein wrote:

> I think I completely disagree with you on this point, Rob -- either  
> we accept SI or we refuse it.

Does accepting SI mean refusing everything else?  Are "parsec",  
"Angstrom" and "Msun" SI units?

I didn't say anything about refusing SI.  Rather, I think compiling an  
enumerated list of units (perhaps as a vocabulary with aliases) -  
including various SI units and copious SI prefixes - is likely to be a  
more successful strategy than building a units parser into every VO  
application.

> Taking a part of it and replacing a set of about a dozen of symbols  
> plus a dozen of prefixes, all well-defined and internationally  
> accepted, by an enumerated list of your own is a non-sense.

The success of the endeavor is the best way to prove my nonsense  
wrong :-)

I've just scanned again through VOUnits v0.1 (a perfectly reasonable  
first draft, I should say) and realized that it contains no list of  
proposed base units.  Were people really thinking that a dozen base  
units would be enough?

This discussion has artificially elevated the importance of prefixes  
in SI methodology.  But in the 48 orders of magnitude from yocto to  
yotta, the basic gimmick is surely to define new units, not to serve  
the needs of scaling in numerical calculations.  For instance, the SI  
unit of mass is the kilogram, not the gram, yet absolute adherence to  
SI rules is abandoned posthaste since we call the other unit a  
milligram, not a micro-kilogram.

Has there been any discussion about terminology for bits and bytes?   
Are we planning to disambiguate 1000 from 1024 via kilo/kibi or mega/ 
mebi?  The six additional options (Ki, Mi, Gi, Ti, Pi and Ei) make a  
total of 26 prefixes to support - seven of which are two characters  
and one of which is a greek letter.

> I don't see the usefulness of adding 'cc' as a synonym of 'cm3', at  
> least associated to the data we expect to exchange between the data  
> providers and the VO applications.

I wasn't seeking to add anything.  In the U.S. a milliliter is often  
referred to as a "cc", this is simply a synonym.  This is not a very  
important example astronomically, but the basic point is that we  
should support the diverse usage that is actually encountered.  Unit  
labels have long forms and often multiple short forms (abbreviations),  
and the abbreviations can be very idiosyncratic.

> Of course if one application prefers to write 'cc' instead of 'cm3',  
> there must be an absolute freedom to do so -- but what we are  
> talking about is the set of units which are have to be understood by  
> _any_ VO application.

I'm not looking for absolute freedom - but if that's what the VO wants  
an enumerated list is more free since more than one set of rules can  
be implemented.

And if one wants to establish a limited common subset, an enumerated  
list can be more limiting and precise, as well.

> Again, the final user must have the right to choose whatever unit he  
> would like to plot along the axes -- horsepower per acre and  
> Megacycle if he likes this. Such choices do not imply that the VO  
> standard has to understand such units.

If this can be accomplished in spite of the standard, why would the  
standard be needed?

>> What it suggests to me is that the rules are too complex (and  
>> possibly too expensive) to implement at runtime.  Rather, the goal  
>> should be to parse an expression against a static list of all  
>> viable combinations of prefix and base unit.  That will be hard  
>> enough to get correct.
>
> Again I basically disagree here. These rules are simple, not  
> difficult to implement at run-time. Computers are excellent for such  
> operations, they are able to deal with all viable combinations  
> faster, and with a 100% reliability.

I stand corrected.

However, an enumerated list with a few hundred (or even a few  
thousand) entries is also not difficult to implement.  Computers are  
excellent at managing lists.

Rob