Anita M. S. Richards
a.m.s.richards at manchester.ac.uk
Sun May 24 10:29:55 PDT 2009
> 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
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
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
'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
More information about the dm