revised quantity draft: comments from Aus-VO

[Arnold Rots]

I agree that we need to decide how to handle this (and that it needs
to be handled).
In XML schemas one has the option of using "decimal", rather than,
say, double.  That allows arbitrary precision, but it does not, of
course, map automatically into standard software datatypes.
My question is whether this perfectly good mechanism to ensure
maintaining full precision in metadata exchange is the right
solution.  I am inlined to think so (and have used it for time in the
STC schemata), but I am aware that it may hide the subtlety to
unsuspecting implementors.

  - Arnold

Anita Richards wrote:
> 
> >
> > 3. [suggestion] the question of accuracy is raised, and in 4.13 a tuple
> >    is given as a possibility for non-simple data types.  Looking at all
> >    astrometry packages, times are already always given as two doubles
> >    (you can barely get a us precision over a full year in one word)
> >    and the same is getting true for frequencies: THz central frequency
> >    with precise offsets.  A data model where it is possible to specify
> >    an offset in a separate word of a tuple would solve this (and future)
> >    precision issues.
> 
> I have already run into rounding errors where applications use decimal
> radians and positions need to be expressed to milli-arcsec accuracy.  In
> fact I am told that if full double precision is used properly then it
> should be OK for micro-arcsec.  However, in practice that is almost never
> the case, in my experience; even applications which handle data correctly
> internally don't report it correctly (AIPS, Aladin... that is just the
> ones beginning with A...).  Using a tuple can make things worse
> in that you can be returned the sum of two parts of a tuple which have
> both been rounded separately.  The other extreme is applications which
> return a very large No of decimal places regardless of the accuracy,
> convert integers to non-integers etc.
> 
> mm-vlbi results are already being reported with a precision of ~4e-13
> radians (sub-uas) and of course you need an extra place for rounding.
> Pulsar timing and SETI use the sort of precision David mentioned in the
> time/frequency domain.  There are probably many other examples.  This is
> not an academic issue.
> 
> So I agree strongly with David that we need to ensure that accuracy is
> properly handled _and returned_ and the suggestion he makes is probably
> the best way to do it (I am happy to leave it up to experts) but I wonder
> how best to get good practice _adopted_, i.e. to produce applications and
> models which work to the appropriate degree of accuracy and which leave
> room for the sort of very high accuracy which is in use - not to mention
> the future.
> 
> Sorry to labour the point, but I did some work briefly with Al Stirling on
> investigating how VO tools which currently exist might cope with ALMA data
> and we found that most of them can't even cope with 22 GHz MERLIN or 1.6
> GHz VLBI data (i.e. milli-arcsec accuracy), which is actually a severe
> handicap here and now.
> 
> cheers
> a
> 
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
> 
> >
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------