VOunits draft

Mon May 25 23:53:35 PDT 2009

Hi Rob,

Le 26/05/2009 02:35, Rob Seaman écrivait :

> Hi Francois,
> 
>> Looks like there is a misunderstanding there -- I was just saying
>> that we have to accept the full SI, with all its prefixes.
> 
> I've have been attempting to make three points:
> 
> 1) Why do we "have to"?  What are the requirements pertinent to VO use 
> cases that would lead to our accepting "yotta" and "yocto" (for 
> instance) for our purposes?

On my side, I don't understand why you're focusing on these two ends of 
the distribution !

> 
>> If an enumerated list is easier to handle in your code, please do so,
>> but again that's not how the SI is defined.
> 
> 2) It was implied by others in this thread that VO applications would 
> need a rules-based parser.  I wanted to suggest that an enumerated list 
> might be better adapted to the purpose.

But will lead to revision in the future if new cases appear where new 
prefixes are needed.

>> ... 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 ?
> 
> 3) It was suggested by others in this thread that SI prefixes somehow 
> supplied a solution to numerical precision issues.  This is an 
> interesting idea, but devoid of details.  How would this work in practice?

the basic idea (that comes from the best practise of numerical 
computation community) is the fact we can separated the magnitude (10^n 
here, not the astronomical one :-) ) from the significant part of a real 
number (mantissa). By chance (?), the SI use only power of ten to encode 
unities...

Let's assume a parcsec to be (I know this is an approx) :
     1 pc =  3 085 677 581 282 10^{16} m

you don't need to declare a real number as 3.085677581282E+16 (fortran 
notation sorry!). To make a conversion you only need to define the 
3.085677581282 with as much as precision as you want (or need) and then 
compute separatly the exponent. If I want to convert the box size of the 
Horizon 4pi simulation (2 Gpc), I just need to multiply 2 by 
3.085677581282 on one side and 9 + 16 for the exponent.

the correct answer is 6,171355162564 10^25 (manual computation)

Now, a small program (written in fortran 77 compile with g77, no 
optimisation at all... the worst that can do a beginner :-) ) gives the 
following answers:

real number arithmetics with full exponents gives : 6.17135500167932E+25 
(wrong!)

real operations on the mantissa and integer arithmetics of the 
exponents: 6.17135524749756     25

(still wrong since only 7 digits are significant in simple precision but 
right if we keep only the 7 first digits as we have to do in simple 
precision arithmetics)

double precision arithmetics with full numbers : 6.17135518525686E+25 
(still wrong!)

double precision on mantissa and integer on exponents :
6.17135516256400     25

the last one is the only correct answer...

Btw, this is the number of digit in the floating point processor that 
ultimaly defines the arithmetic precision, not the size of the storage 
words. So, depending on the computer (and compilation options), it could 
be useless to use double precision storage. One only avoids truncation 
errors at the storage phase.

> 
>> 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.
> 
> The IVOA ultimately falls under commission 5 of the IAU.  We should 
> certainly be cognizant of - and influential over - the development of 
> IAU standards.
> 
> This is the first time the general preeminence of ISO standards has been 
> suggested in this thread.  Perhaps you meant SI (CGPM).  We do have some 
> interest in a subset of ISO-8601, but the proprietary nature of ISO 
> isn't a good match to either IAU or IVOA.
> 
> IVOA standards requirements should derive from use cases, not from an 
> appeal to any external authority, whether IAU, ISO or SI.

I'm a bite surprised there, since IVOA standards already depend heavily 
on external standards as W3C ones for instance. W3C seems to be such an 
external authority. FITS is only heavily used, that is an IAU standard.

> For example, SI base units are the metre, kilogram, second, ampere, 
> kelvin, mole, candela.  Astronomers use all of these at some point, but 
> use a wider variety of non-SI units for key purposes.  It is simply not 
> true that SI is all we need to worry about.  Since we're only interested 
> in a subset of ISO-8601, perhaps we're also only interested in a subset 
> of SI, perhaps deprecating the more obscure SI prefixes.

Maybe I'm wrong, but what I've understood from the discussion is that 
the defintion of a common unit system is needed for 'internal' purpose 
(eg service-to-service communication). At the level of the human client, 
any 'traditional' unit is allowed. Am I right?

Cheers,

Herve

> Rob
> 
> 

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