VOunits draft

[Francois Ochsenbein]

>
>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.
>

Looks like there is a misunderstanding there -- I was just saying
that we have to accept the full SI, with all its prefixes. 
Deploying all combinations, and then making your choice in
these units -- like for instance refusing Tm because you don't
see an immediate use case -- is what I am concerned with.
Additional units (the astronomical extensions of table 5 from IAU at
http://www.iau.org/science/publications/proceedings_rules/units/ )
should be recognized, and maybe part of table 6 if it is felt to
be important.

>> 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.

The 'u' is replacing the 'mu' in the the packages dealing with units 
-- at least that's the practice I've generally seen. This convention
should be added in the document.

About powers of 2 (kibi mebi etc) it's a rather recent addition,
these are not quoted by IAU -- why not ?

>> 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?

One more time, an *application* is a piece of software that, one
one side, reads data from data servers using agreed *VO standards*, 
and on the other side produce results, tables, plots, images, 
statistics ... using any user-defined units. The units used for
the *exchange of data* between data servers and applications must
conform to agreed-upon standard to enable interoperability.

>>> 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.
>

If an enumerated list is easier to handle in your code, please do so,
but again that's not how the SI is defined.

Rob, I would like also to understand what you mean in your more recent
message:

>> I think using SI prefix is rather a good idea. The number of SI  
>> prefixes is fixed and rather short (20) compared to other stuff we  
>> have often to compile... (including units!) :
>
>Is there a reference to using SI prefixes to handle numerical  
>precision conversions?  Unfortunately my Numerical Recipes is at the  
>office (and the building has been closed until tomorrow due to  
>flooding in the basement!)  A quick google on "SI prefixes numerical  
>precision" returns the top hit (on some Perl mailing list):
>
>>> "String numerifier with SI prefix support ... Given a floating- 
>>> point numerical input, I produce an output string formatted in  
>>> engineering notation."
>
>With the punchline:
>
>>> "...It does not handle rounding or precision correctly"

... I really don't see the point. It may happen that a problem
happens in floating point values when the exponent is too large
(e.g. it's impossible to store in an IEEE floting-point number
the value representing the mass of a galaxy express in grams);
is that this problem you are tackling ?

Anyway the discussion on units is taking place to-morrow; 
and I really hope that the ISO and IAU recommendations will
be viewed as more compelling than what can be read in a 
novel -- even if the author is an excellent scientist.

Francois
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================