VOunits draft

[Anita M. S. Richards]

>
> Rather than implementing some general purpose mechanism for representing SI 
> prefixes, why not ignore the issue entirely?  Centimeters and kilometers 
> might be easily convertible to meters, but they are really three different 
> units in practice.  That is, explicitly support cm, km and m as separate unit 
> labels.
>

Hi Rob,

There are two issues here.  Firstly, we need to recognise unit strings 
attatched to published data.  My impression is that rather a lot of SI 
prefixes are in common use, from milli to Tera for Hz for example. 
Secondly, one of the things which came up from the initial attempt to get 
use cases was that users often need data in relatively short floating 
point numbers with SI prefixes rather than with huge (or tiny) exponents, 
since labelling axes on a plot or tabulating results as 9.87 to 345.6 nJy 
is often much more convenient, and intuitive for the human reader to 
visualise, than 9.78e-9 to 3.456e-7 or 0.00000000987 to 0.0000003456 
Jy.

Handling data internally using SI prefixes also helps to avoid possible 
loss of precision - see my previous rant - although really that should be 
fixed by making all tools format numbers sensibly, but you often don't 
find out until you try and pass nJy through a package written when 100 mJy 
was the depths of sensitivity...

We need to make sure that we regonginse SI prefixes to avoid Mcm, etc.

Of course, users should be able to control whether they get data back in 
the original units entirely, or with SI prefixes changed as appropriate.
But if you love cgs and I publish data in SI, youd probaby like to get 
stellar radii in km, back in cm?

You also mentioned logarithmic units.  We should support these, in the VO 
Units draft we were uncertain as to how, but the FITS standard may be the 
best way. The problems arise when they require an attatched coordinate 
system, and when in the case of magnitudes, the conversions into other 
units can be dependent on variable factors.  We stop short of this in the 
Units model.

'Decibels' does illustrate the point made by Paddy Leahy I think, that we 
should be able to parse the whole prefic (deci) as well as the 
abbreviation.  And if for a few units we have to have special rules like 
'don't convert to centibels', that is no big deal.

The bottom line is that I think that we should cater to all user 
requirements if it is relatively straightforward so to do, either by using 
existing libraries or by writing our own code for an SI parser (but surely 
there is one already?).

all the best

Anita