VOUnits RFC

[Rob Seaman]

Urgh…meant to mention the precise definitions of transcendental constants versus inevitable truncation by floating point.  Do we have sufficient support for unit-less quantities like π (pi)?

Also a typo.  "An in fact that table does exhaust the variations" should be "does not exhaust".  And it should be "And in fact".  But then I should have resisted beginning the sentence with a conjunction.
--

On Aug 1, 2013, at 10:25 AM, Rob Seaman <seaman at noao.edu> wrote:

> Hi Norman,
> 
>>  2. 'Unknown units' needs to be permitted in the syntax.
> 
> Another way to look at this is as a mechanism for user-defined units, similar to adding local terms to a spelling dictionary.  Many authors create unit-tokens on the fly for a very localized purpose - to simplify exposition of a derivation, for instance.  Heck, this happens even in science fiction:
> 
> 	The Doctor: You named a unit of measure after yourself?
> 	Dr. Malcolm Taylor: Well it didn't do Mr. Watt any harm. Furthermore, one hundred Malcolms equals a Bernard.
> 
> (Not to mention that the word "UNIT" is itself overloaded in the same episode :-)
> 
>> Re 1: there's still a bit of discussion necessary about the exact syntax of the float -- permissive or restrictive
> 
> And I guess as far as zero-points contrasted with scale-factors that these are presumed to be implicit in the units, for example zero degrees in the various temperature scales.  And if there is a need to specify such explicitly that the assumption would be that this is a second keyword or metadatum as with epoch, a prime meridian, orbital elements, etc?
> 
>> Re 1: this means that there are now two exceptions to the aspiration that a VOUnits string will be parseable in all the other syntaxes, namely (i) the choice of '.' as the multiplication symbol is incompatible with OGIP, which uses '*', and (ii) the FITS and OGIP syntaxes only permit powers of 10, and the CDS syntax permits floats with a different syntax.  That's probably OK.
> 
> Floating point versus "powers of 10" is not the only issues here.  There are at least two others:
> 
> 1) Some scale factors are defined as precise constants, whether integral (-5 magnitudes is 100x brighter) or fractional (that 2.54 again).  Using a float (well "floatish" literal string) for everything loses these distinctions.  (Plus note that some scale factors are negative.)
> 
> 2) Not all bases are decimal.  In addition to hex and binary expressions mentioned previously (we are programmers after all), there are the the "kibi" verus "kili" variations:
> 
> 	http://en.wikipedia.org/wiki/Binary_prefix
> 
> as well as all the sexigesimal and duodecimal (which wikipedia warns us not to confuse with Dewey Decimal :-) variations beloved of astronomers.
> 
> and another:
> 
> 3) Ambiguity or error propagation?  One often sees binary and decimal prefixes mixed informally:
> 
> 	http://en.wikipedia.org/wiki/Binary_prefix#Deviation_between_powers_of_1024_and_powers_of_1000
> 
> An in fact that table does exhaust the variations since one will often see mebibytes (1024^2 bytes) grouped a thousand at a time and referred to as a "gigabyte".  Or a thousand gibibytes or gigabytes (whichever meaning) grouped into some number of informal TBs somewhere midway between a metric terabyte and an IEC tebibyte.
> 
>> Re 1 and 2: the spec should include some text describing the disadvantages of both of these options; we may call this 'deprecation' or we may just call it 'usage advice'.
> 
> "Pragmata"?
> 
>> How does that sound?  Have I missed anything (I'm pretty sure I have, but can't now recall what)?  Does anyone have particular suggestions for where clarifications should happen?
> 
> The ultimate clarifications are wrangled in the literature (this is part of "the mangle of practice").  If IVOA (or some other activity of Comm 5 or even ADS) were to undertake to maintain such a list it would resemble the daily / weekly / monthly / annual tz database interactions, though presumably with different duty cycle(s).  Note that the tz database must frequently be updated retroactively.
> 
> …and from the previous message:
> 
>> This means that [J/s] would be joules in whatever definition of the second QUDT has settled on (which I think is the SI second), but [J/'s'] would not be that, and might be useful if someone wants to use some different definition of the second for some mad reason, and would require them to communicate what this 's' unit was in some other out-of-band way.
> 
> For "mad reason" read "every usage of the term 'second'".  The ambiguity is ubiquitous except, as you say, when explicitly saying something like "SI-second".  And the ambiguity in second usage spreads to situations that are even less rigorous.  So a minute or an hour is deemed at least as factually a fraction of a solar day as it is the corresponding multiplier of SI-seconds.  (Mightily resisting commenting further on time issues…)
> 
> Rob
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20130801/dc00261a/attachment-0001.html>