<div dir="ltr">We should definitely get involved in the VOUnit standardization effort on these things, as the current draft hints at, but doesn't really sufficiently address these issues.<div><br></div><div>Mike</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 9:22 AM, Marten van Kerkwijk <span dir="ltr"><<a href="mailto:mhvk@astro.utoronto.ca" target="_blank">mhvk@astro.utoronto.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Peter,<br>
<div class="im"><br>
>> (1) How would I indicate a dimensionless but logarithmic quantity such<br>
>>     as dex? If I understood the standard correctly, log(surface gravity)<br>
>>     might have the unit "log(cm/s2)", but how about a dimensionless one<br>
>>     (like metallicity).  Would it be "log()", or, by analogy with<br>
>>     magnitude, just "log"?<br>
><br>
</div>> If something has no unit that the unit could be viewer to be unity.<br>
> Hence I would say use log(1). Leaving the argument empty would otherwise<br>
> probably break parsers.<br>
<br>
Thanks!  definitely seems much more logical than the log() or log('') I<br>
suggested, especially since the standard explicitly defines it as the<br>
function having taken an argument and divided it by the unit in<br>
parenthesis.  (And it also matches nicely with our internal astropy use,<br>
where dimensionless unscaled can be represented by Unit(1).)<br>
<br>
My colleage Michael Droettboom looked at wcslib in a bit more detail and<br>
it looks like that package assumes that prefactors for the log()<br>
function are not allowed, and hence that it is not possible to pass that<br>
package a unit of dB(mW) or mag(AB).<br>
<br>
>From the discussion -- which I do find interesting! -- it seems that (as<br>
yet) the FITS standard similarly does not define these cases.  Like we<br>
already do for units with non-factor-of-ten scale, it may be best for<br>
now to simply warn the user that this cannot be stored in a way that one<br>
can count on other packages understanding, and give a hint on what would<br>
be needed to make it more easily supported.<br>
<br>
I do think eventually one would like to be able to handle such units,<br>
however ugly they are (they are just too commonly used...).  In the<br>
recommendations on units by NIST [1], two possibilities are mentioned,<br>
the default one perhaps more alike to Tim's, where the unit is "dB" (in<br>
that example) and the description "L_P (re 20 μPa)" (where "re" stands<br>
for reference level, which I must say I rather dislike) and a "condensed<br>
version" that is more similar to what I had in mind, as that unit<br>
carries all the required information in one place: "dB (20 μPa)"<br>
<br>
Thanks again,<br>
<br>
Marten<br>
<br>
<br>
[1] <a href="http://physics.nist.gov/Pubs/SP811/sec08.html#8.7" target="_blank">http://physics.nist.gov/Pubs/SP811/sec08.html#8.7</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><div><font face="courier new, monospace">|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _  <br></font></div><div><font face="courier new, monospace">|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | </font></div>
</div><div><br></div><div><a href="http://www.droettboom.com/" target="_blank">http://www.droettboom.com/</a><br></div><br><br></div>
</div>