VOunits draft

[Hervé Wozniak]

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!) :
http://en.wikipedia.org/wiki/SI_prefix

However, if we want to use the full SI system to transport data from the 
data provider to any client, after maybe some pipeline process or 
workflow, we have to keep as much as possible the accurary of the 
original data during the various transformations (at least two: orginal 
units to SI, SI to client units. But maybe some intermediate clients 
would make internal conversions).

I agree there is no problem to change cm into m with SI prefix but it 
could be a bit more tricky to keep accuracy when you move from Kcal to J 
(not the worst case anyway but maybe other readers can find more 
difficult cases, especially those including a physical constant; and 
this depends a bit on the number of significant digits in the original 
data). Technically, to prevent any lost in accurary, we have to keep the 
real numbers in the *normalised* range of values, so we need prefixes.

Herve



Le 24/05/2009 19:29, Anita M. S. Richards écrivait :

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

-- 
Herve WOZNIAK

Astronome
Observatoire Astronomique de Strasbourg
UMR 7550 Universite de Strasbourg - CNRS
11, rue de l'Universite, F-67000 Strasbourg

Tel/Phone : +33 3 90 24 24 45   Fax : +33 3 90 24 24 32

mel/mail : herve.wozniak at unistra.fr skype : herve.wozniak

http://herve.wozniak.fr/