[yt-dev] Milliparsecs

[Britton Smith]

I'm changing my vote to somewhere between -0 and -1.  We will still be
supporting many other implausible units, like centi and nanoparsecs, which
makes this wrinkle seem even more out of place.  I can only see two upsides
to making this change: backward compatibility and difficulty/laziness with
identifying and fixing all the instances of 'mpc' in the code and docs.
 Backward compatibility has already largely been thrown aside for 3.0.
 Other people's reservations have brought me around and I now see the
second upside as not really worth it.


On Tue, Dec 3, 2013 at 1:52 AM, Cameron Hummels <chummels at gmail.com> wrote:

> I'm +0 on having mpc map to Mpc.  I think this is a good situation where
> we could have a note in the docs about the case-sensitivity of units in the
> gotchas section of units or fields or some such.
>
>
> On Mon, Dec 2, 2013 at 2:32 PM, j s oishi <jsoishi at gmail.com> wrote:
>
>> Well, count me as a not terribly passionate -1. I think the idea that
>> coding around the habits of certain subsets of users of yt has gotten us
>> into trouble in the past, and I'm wary of doing it here. While this is
>> certainly not a huge deal, I personally prefer that we be stricter about
>> units standards. However, I totally understand that milliparsecs is not
>> used by anyone. And of course, parsecs are not SI to begin with, so I
>> suppose from a PURELY logical standpoint, we aren't necessarily bound by
>> their prefix conventions.
>>
>> j
>>
>>
>> On Mon, Dec 2, 2013 at 4:22 PM, Sam Skillman <samskillman at gmail.com>wrote:
>>
>>> -0
>>>
>>> I'd rather we all just use Mpc, but I'll go along with it.
>>>
>>>
>>> On Mon, Dec 2, 2013 at 12:53 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:
>>>
>>>> Here is the change:
>>>>
>>>>
>>>> https://bitbucket.org/ngoldbaum/yt/commits/2e6d536ffa1976e4699093c4bb3b3bc4ade3f9da
>>>>
>>>> We'll definitely be leaving 'm' -> 'milli' alone.  FWIW, we already do
>>>> this by mapping 'mpc' -> 'Mpc' in plot labels.
>>>>
>>>>
>>>> On Mon, Dec 2, 2013 at 3:46 PM, Britton Smith <brittonsmith at gmail.com>wrote:
>>>>
>>>>> Ok, then I will put my anal personality (which would never agree to
>>>>> such a thing) aside and say I'm cool with this.
>>>>>
>>>>>
>>>>> On Mon, Dec 2, 2013 at 8:43 PM, Matthew Turk <matthewturk at gmail.com>wrote:
>>>>>
>>>>>> Hi Britton,
>>>>>>
>>>>>> This would be in the units refactor of yt-3.0, and would *only* apply
>>>>>> to parsecs.  This would be the exclusive special case of m[some unit]
>>>>>> meaning Mega.
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>> On Mon, Dec 2, 2013 at 3:41 PM, Britton Smith <brittonsmith at gmail.com>
>>>>>> wrote:
>>>>>> > Hi Matt,
>>>>>> >
>>>>>> > Where exactly is this?  Is this in yt-3.0, and if so, would this
>>>>>> apply to
>>>>>> > all uses of m as milli?  Is that is so, then my concern is for when
>>>>>> yt
>>>>>> > becomes more used by other domains that actually do have a valid
>>>>>> use for
>>>>>> > milli.
>>>>>> >
>>>>>> > Britton
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Dec 2, 2013 at 8:24 PM, Matthew Turk <matthewturk at gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Hi all,
>>>>>> >>
>>>>>> >> Nathan and I are working on some unit things.  One that came up is
>>>>>> >> that it looked like the conversion to mpc was wrong.
>>>>>> >>
>>>>>> >> Turns out, it's not.  But what it's set up as is "mpc" for
>>>>>> >> "milliparsecs" and "Mpc" for "Megaparsecs."  We'd like to get rid
>>>>>> of
>>>>>> >> any usage of milliparsecs, since I think the number of people who
>>>>>> want
>>>>>> >> to use that (globally) are probably between 0 and 0, and just make
>>>>>> Mpc
>>>>>> >> and mpc the same thing.
>>>>>> >>
>>>>>> >> If anybody objects, write back.  Silence will be taken as tacit
>>>>>> agreement!
>>>>>> >>
>>>>>> >> -Matt
>>>>>> >> _______________________________________________
>>>>>> >> yt-dev mailing list
>>>>>> >> yt-dev at lists.spacepope.org
>>>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > yt-dev mailing list
>>>>>> > yt-dev at lists.spacepope.org
>>>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>> >
>>>>>> _______________________________________________
>>>>>> yt-dev mailing list
>>>>>> yt-dev at lists.spacepope.org
>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20131203/423dae6b/attachment.html>