Steve,
Actually I initially asked for the distances in parsecs and was expecting
that they would be presented in a convenient format. So, to frame it in terms of
your analogy, I ordered a short black and become upset when I am delivered 8oz
of coffee in a 55 gallon drum.
This seems to be one of those unstated assumptions that have caused confusion in
these discussions. Sometimes you want fix the prefix, sometimes you don't. For
example, the Bel (B) is a unit of measure for ratios, but we never use it
directly, we always use decibels (dB). Nobody uses mB or kB or even B, it is
always dB. But with other units we do use the scale factors and we do tend to
normalize the presentation. For example, nobody says the Usain Bolt won the
100000mm dash, or the 0.1km dash. Similarly when people refer to the length of
the Olympic road race in Rio, they say 56km, not 56000m.
This is really only an issue with output. What I am suggesting is adding support
for the second case into stdlib. For example:
>>> print('Attenuation = {:.1f}dB at {:r}m.'.format(-13.7, 50e3))
Attenuation = -13.7dB at 50km.
-Ken
On Tue, Aug 30, 2016 at 11:41:10PM +1000, Steven D'Aprano wrote:
> On Mon, Aug 29, 2016 at 08:48:55PM -0700, Ken Kundert wrote:
>
> > >>> print(d_sun.to(u.kpc))
> > 4.850441695494146e-09 kpc
> >
> > I can see where this can be helpful at times, but it kind of goes against
> > the
> > spirit of SI scale factors, were you are generally expected to 'normalize'
> > the
> > scale factor (use the scale factor that results in the digits presented
> > before
> > the decimal point falling between 1 and 999). So I would expected
> >
> > d_andromeda = 780 kpc
> > d_sun = 4.8504 upc
>
> Let me see if I get this straight... you *explicitly* asked for the
> distance to the sun in kpc (kiloparsecs), but you expected a result in
> µpc (microparsecs)?
>
> When you ask the waiter for a short black, do you get upset that
> he doesn't bring you a latte with soy milk? *wink*
>
> I can see that such a normalising function would be useful, but I don't
> think it should be the default. (If I ask for millimetres, I want
> millimetres, not gigametres.) I've written and used code like that for
> bytes, it makes sense to apply it to other measurement units. But only
> if the caller requests normalisation, never by default.
>
> I don't think there is any such general expectation that values should
> be normalised in that way, and certainly not that your conversion
> program should automatically do it for you. For example, see this list
> of long-lived radioactive isotopes:
>
> http://w.astro.berkeley.edu/~dperley/areopagus/isotopetable.html
>
> Values above 650,000,000,000 (650e9) years are shown in "scientific
> format", not "engineering format", e.g. Selenium-82 is given
> as 1.1 x 10^20 rather than 110 x 10^18.
>
> Likewise:
>
> http://www.nist.gov/pml/data/halflife-html.cfm
>
> displays a range of units (minutes, hours, days) with the base value
> ranging up to over ten thousand, e.g. Ti-44 is shown as 22154 ± 456
> days. This is NIST, which makes it pretty official. I don't think
> there's any general expectation that values should be shown in the range
> 1 to 999. (Perhaps in certain specialist areas.)
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
