Where to begin? Working backwards:
Anita wrote:
> the problem with MJD is that most astronomers don't even know what
> the M is.
Whereas the advantage of ISO 8601 is that virtually no astronomers know what it is :-)
> most trig functions need radians.
Have been helping my daughter with her HS trig. Her textbook spends equal time between radians ("natural" units) and degrees (unnatural Babylonian units). Whether computer algorithms and languages prefer radians is an implementation detail. I find it revealing that we aren't arguing about HMS on the one hand and radians on the other, but rather about two different Babylonian variations (HMS versus degrees).
Francois wrote:
> double have 52 bits for the mantissa [...] that means a dynamics of
> 2^53 or
> 10^16. If the largest angle is 360degrees, to get an accuracy of 1
> nano-arcsec
> you need only 51 bits only (360deg = 1.296E+15 nano-arcsec).
>
> [...] you quote is 243 + 0.9130 microarcsec, i.e. expressed with an
> accuracy of
> 0.1nano-arcsec ...
Ed had an extra factor of 3600 in there. Suspect some of us will regard this typo as supporting the "decimal degrees and only decimal degrees" position - and others will see this as support for "allow representations that astronomers actually use".
The "52 bits is enough since we only need 51 bits" argument sounds a lot like "short integer pixels are enough because our A/Ds are only 16 bits and we can force the pixels to be interpreted as unsigned". Suspect we wouldn't have to try too hard to come up with examples where double precision really wasn't enough. Certainly various applications involving arithmetic on such quantities will have to be very carefully written to avoid overflowing doubles internally.
Tom wrote:
> If we allow a variety of formats for the times and positions then
> we will be saddled with them forever.
The genie is already out of the bottle. "Saddled" is a loaded word, but IVOA has had little chance since day one of convincing astronomers to abandon sexigesimal representations. Also, FITS never succeeded in existing as a pure interchange format, unsullied by astronomers' fingerprints - not obvious why IVOA standards should be expected to achieve this (rather perverse, I must say) goal.
Clive wrote:
> Unfortunately this is an issue with which the FITS community has
> failed to deal, and it is a serious one.
Rather, FITS addressed this issue early on - for instance: "If CTYPEn denotes a celestial coordinate, such as right ascension or declination, CRVALn shall be expressed in units of decimal degrees", but found that pragmatic usage diverged from the mandated choice. To a large degree, the FITS community is the ADASS community, and the ADASS community is the IVOA community. That IVOA has managed to enlarge the ADASS community, while FITS never did, is a very strong indicator of continued success - but IVOA can still productively learn from FITS experience. Suggest we pick our battles.
Mark wrote:
> The lexical analysis is not the problem, it's knowing what lexical
> analysis you have to do - there is not a straightforward algorithm
> for the mapping "string -> number" but there is for the mapping
> "string-which-is-in-iso8601-format -> number".
> All I'm proposing is a way of inserting hints about this.
A feature is either required or it is not. What is the value to VOTable (or VOEvent, etc.) of a hint or pragma if tables are not required to use the feature? Applications will still have to heuristically select an appropriate lexical mapping.
Roy wrote:
> Who is writing VOTables with sexagesimal in them? Surely the best
> thing is to convert to decimal as soon as possible, and convert
> back to sexagesimal (if wanted) at the last possible moment before
> the human eyes see it.
Computers are completely able to handle sexigesimal fields. Any manly algorithm is going to have to slice and dice the input quantities internally anyway to avoid overflowing internal variables, for instance. For an application precisely as described - conversion from human friendly sexagesimal, then transport, then conversion back to human friendly sexagesimal - surely the conversions are unnecessary, inefficient and unwanted. Being "human friendly" is just one more requirement placed on a system. We're simply seeking to distinguish use cases in which decimal radians (for instance) are *more* human friendly than sexigesimal, whether or not the tools involved are computers or analog setting circles.
> Suppose I want to represent a number like 3.666667 as "3 2/3" or
> "three and two thirds"?
But this is precisely a requirement that might be placed on some other computer mediated system in support of financial transactions, for instance. Everybody who writes a check generates exactly such a string of characters. An application to either print or OCR such forms may certainly need to convert back-and-forth between $123.45 and "one hundred twenty three and 45/100 dollars".
Again - computers are perfectly capable of performing such conversions. This isn't really a question of humans versus machines.
Mark started with this reasonable enough suggestion (presumably for some future version of VOTable):
> P1. Introduce a new attribute "representation" (or some other name)
> for FIELD/PARAM to contain a special string indicating how
> values
> in that column are to be interpreted. The special values
> "hms", "dms" and "iso8601" (any more?) would be initially noted
> along with rules for what counts as valid instances of those
> representations.
My original reaction was not rejection, but rather:
> Have to wonder if this is really a step forward. Have certainly
> seen examples of mixed representation columns in the past. These
> may even be more frequent in the VO as users assemble tables as
> intermediate products resulting from multiple archives. A column
> might include both sexagesimal and decimal representations -
> potentially even mixed datatypes (floats versus strings, for
> instance) in some more quixotic applications.
And so we have seen various such examples since then. It actually sounds like strings like "12 34 45.67" are standard variations of HMS representations. If you think that few tables will include such usage in the future, a representation attribute is unnecessary. On the other hand, if you think many tables will continue to rely on sexigesimal representations, the question is whether the creators of such tables (including VO end-users) will reliably include such an attribute. If so, by all means add this feature to VOTable and related IVOA standards. But if you don't think such an attribute will be used in the great majority of such cases - or perhaps that it will only be used as a "hint", then it simply seems more trouble than it is worth.
Rob Received on 2006-04-21Z21:14:17