Re: [yt-dev] ipython-physics

+1 for Sympy + Dimensionful. On Tue, Oct 23, 2012 at 11:57 AM, Anthony Scopatz wrote:

I am +1 for adding sympy.

On Tue, Oct 23, 2012 at 9:55 AM, Matthew Turk wrote:

...

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

...

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),

...

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 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

On Sat, Oct 6, 2012 at 12:59 AM, Anthony Scopatz wrote: they 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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org