[yt-dev] RFC: introduce {length, mass}_units (similar to time_units)

[Britton Smith]

I'm +1 on deprecating the __getitem__ stuff.  I think at this point it
mostly creates confusion.

I also think it might be a good idea to phase out instantiation of sphere,
disk, etc object in the manner discuss in point 3 and push toward using the
(size, unit) tuple method.  This method is consistent with how the
time_series analogs of those objects are created and I think that
consistency is valuable.

Britton

On Sun, Feb 19, 2012 at 11:49 AM, Matthew Turk <matthewturk at gmail.com>wrote:

> Hi Kacper,
>
> This is a gigantic weak spot in yt: handling of units, which generally
> does *work*, is done behind some relatively old and unnecessary code.
> When I started writing it, I learned about operator overloading, and
> so I tossed all the parameters, units, and time_units into a single
> call to __getitem__.  I've disliked this for quite some time, as it
> conflates all types of conversion between things, as well as
> conflating conversion with parameters.
>
> Adding a length and mass unit system would be a bandaid to this system
> ... I'm inclined to say it's probably okay to do, but I would rather
> we go through a more in-depth improvement.
>
> 1) Deprecate *immediately* __getitem__ on a parameter file.  This
> means adding a DeprecationWarning, in whcih we say that in version 3.0
> this functionality will go away.
> 2) Replace all usages of pf[whatever] in the code with calls to
> explicitly the parameters dict or something else.
> 3) Find all places where the idiom something/pf[unit] is used, and
> either replace them with fix_length on it or find some other way
> around it.  (Did you know that spheres, cylinders, etc can all have
> tuples of value, unit passed in?)
> 4) Set up our base of unit conversions, which are applied when IO is
> conducted.
> 5) Use conversions between those units rather than relying on the
> parameter file.
>
> For #5, we could either use a system like Amusecode.org uses (where
> they apply sidecar unit values to wrapped ndarrays; the main amuse
> architect is on this list, so perhaps he could say a bit more) or I
> noticed that Casey's blog indicated he released Dimensionful, a
> library for light tracking and converting units, which would also work
> quite nicely for this.
>
> Either way, I want to get rid of the current system and plan something
> out; first step is letting people know that we're deprecating
> pf[something].  [+-][01]?  But, for now, adding on what you suggest is
> fine, Kacper.  :)
>
> Thoughts?
>
> -Matt
>
> On Sat, Feb 18, 2012 at 10:02 AM, Kacper Kowalik
> <xarthisius.kk at gmail.com> wrote:
> > Hi,
> > I've been hit by a part of the code
> > (plot_modifications:get_smallest_appropriate_unit) that assumed my data
> > knows what a Mpc, or even Rsun is. While it's trivial to workaround by
> > using try/except, that made wonder why time_units get a special
> > treatment in StaticOutput? Would it be beneficial to introduce
> > corresponding {lenght,mass}_units?
> > Cheers,
> > Kacper
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120220/c60d2706/attachment.html>