[yt-dev] ipython-physics

[Matthew Turk]

Hi all,

Sorry for letting this drop.

My feeling is that we should definitely go with dimensionful (Casey's
project), and add SymPy to the stack.  It seems likely that the
emerging SciPy stack will include SymPy as a component, and
furthermore it's pure python, so it should not be terribly difficult
to include in that respect.

Having a coherent unit stack is crucial.  Right now we have the
really, really terrible (and I take full blame for this) overloading
of parameter files like dictionaries.  As an example, here's how Enzo
would work:

pf["time"]
pf["InitialTime"]
pf["kpc"]
pf["HydroMethod"]
pf["seconds"]
pf["Density"]

All of these do different things.  And, on the backend, they query
different dictionaries -- units, conversion_factors, and parameters.
This is not okay!  We have:

pf.current_time

but this is given in code units for some reason for most codes.

I think we should move to a system where when querying, the person
doing the querying needs to explicitly state what they want.  And all
the unit conversion stuff (time, length, fluid, etc) needs to be
handled by a separate process -- and my preference would be that it
would be handled by dimensionful.  I think that can come in at a
higher level than the conversion from on-disk to CGS, but it should
come in somewhere.

I would absolutely love to rip out all of the dictionary-access for
parameters this instant -- moving to tuples of (value, unit) was the
first step, to get away from value/pf[unit].  But we can't do this
just yet, and it needs to happen at a 3.0 break.

What does everyone think?  Can we do a [+-][01] on SymPy +
Dimensionful, or do we need more info?

-Matt

On Sat, Oct 6, 2012 at 12:59 AM, Anthony Scopatz <scopatz at gmail.com> wrote:
> Hi Mike,
>
> ipython-physics looks like a good, relatively simple solution.  I would
> assume that we would use this *instead* of sympy to prevent having to add
> yet-another-dependency and end up packaging this right with yt.  (ip-p seems
> to be unlicensed yet 'placed in the public domain', which is weird since the
> public domain is not a legal construct everywhere.  We would need to ask
> them about that before including in yt.)
>
> That said, I think a sympy solution would end up being more powerful
> ultimately.  Additionally, ip-p definitely needs some clean up before
> inclusion.  At quick glance they seems to use camel case for some functions,
> their main class NumberDict subclasses from dict (huge no-no,
> collections.MutableMapping people!), all of the _addUnit() calls at the end
> of the file should be hard coded into _unit_table (or a mapped call), they
> seem to be definitely using eval() wrong by not having an empty globals dict
> which captures builtins, and the unit comments never seem to be used (so why
> have them?).  And they have no tests!
>
> So I would be in favor a rewrite of ip-p, but sympy would be better ;)
>
> Be Well
> Anthony
>
> On Fri, Oct 5, 2012 at 7:24 PM, Michael Kuhlen <mqk at astro.berkeley.edu>
> wrote:
>>
>> Hi yt gang
>>
>> Just had a little chat with Matt, and he suggested I bring up
>> ipython-physics for discussion. Sounds like unit handling is an issue that
>> needs to be addressed in yt. I've found ipython-physics to be pretty neat
>> and quite usable. Maybe this is something worth tying into yt? Matt also
>> mentioned that Casey had written a sympy-based library for handling units;
>> how does it compare to what ipython-physics does?
>>
>> Mike
>>
>> --
>> *********************************************************************
>> *                                                                   *
>> *  Dr. Michael Kuhlen              Theoretical Astrophysics Center  *
>> *  email: mqk at astro.berkeley.edu   UC Berkeley                      *
>> *  cell phone: (831) 588-1468      B-116 Hearst Field Annex # 3411  *
>> *  skype username: mikekuhlen      Berkeley, CA 94720               *
>> *                                                                   *
>> *********************************************************************
>>
>> _______________________________________________
>> 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
>