VOunits draft

[Alberto Micol]

> n 26 May 2009, at 17:40, Rob Seaman wrote:
>
> hanks for the discussion of floating point precision.  My two comments 
> are that first, conversions may only be needed if the VO standards 
> require them.  There are lots of tables containing columns of 
> distances in parsec (and kilo and mega parsecs). Are we going to 
> require that these be converted to meters?
>
>     1 Parsec = 3.08568025 × 10^16 meters (according to wikipedia)
>
> So will folks have to convert 1 megaparsec to 30.9 Zettameters (Zm)

> Bear in mind that the distance estimate may be accurate only to +/- 
> 50% and may scale with the hubble constant...
Exactly, any astronomical (hence physical) quantity has got an error, 
there is no point
in transmitting information with higher precision than what the error is.

Hence, to answer your question:

1.- What's wrong with saying that 1 Mpc is just 3.08568025E+22 meters?

{
 or even just 3.086E+22 given that 1 Mpc is essentially not the measured 
value,
 but a rounded version of it, and if you want to get back the number in Mpc:
  3.086E+22 / 3.08568025E+16 = 1.001 Mpc is well within the error.

 Still, to be exact, the VO could declare that
 - the original representation was in Mpc
 - the precision stopped at the integral part of the Mpc.
 - a VO distance is always internally expressed in meters,
 - the VO conversion factor for (e.g.) Mpc is 3.0whateverE+16.)
}


2.- Why do we need Zettameters? Why do we need SI prefixes?

Is the E+22 formulation too simple and general to be acceptable?



3.- It is up to the user to ultimately decide which units are relevant 
to him.
If the original datum is stored in Mpc, but the astronomer wants to 
express it
in units of milky way diameters, it is up to her to do so.
The mere fact that the original number was in Mpc does not mean that the
user will use it in Mpc. So it does not matter what unit is used on the 
wire. The client
will have to translate it anyway to what the user wants (e.g. "milky way 
diameters").

More importantly...

4.- The world is much more heterogeneous than any example I have seen on 
this mailing list.
If we take one example, just ONE of them, wrong conclusions are to be 
derived.
Mpc seems simple to handle if you look at one and only one service...

In the VOSphere (as Sebastien Derriere calls the environment where VO lives)
answers from different services will have to be combined, and if each of 
those services
talk different units, the first thing the application/user will have to 
do is to
convert them all to the same unit (e.g, the milkyway diameter unit).
That is the client will have to know how to translate all input units to 
the user's required
unit (probably first going to some common intermediate unit).

Much easier if all those services already answered all using the same 
agreed (on-wire) units.
The client will have less to do (nothing to interpret), hence less 
errors will be introduced,
and the overall system will be more performant.


Alberto -- just back from the nice banquet

PS: I'm not forgetting the fact that all servers will probably have to 
perform a conversion
from the originally stored unit to the VO standard one, but given that 
my client will have to wait
for the various streams coming from those different servers, that little 
overhead introduced
by the conversion will have less impact overall.

Maybe more clearly:
A client queries N servers:
The server side workload is shared among all the N queried servers, 
while the client would have
to do it all by itself.