[AstroPy] AstroPy Digest, Vol 81, Issue 12
Erik Bray
embray at stsci.edu
Wed Jun 26 11:51:52 EDT 2013
On 06/20/2013 05:08 PM, Thøger Emil Rivera-Thorsen wrote:
> My reason for writing it was especially that it looks like `astropy.tables` does
> a lot of effort duplication by reinventing functionality that is already in
> Pandas.It may be that `astropy.tables` already has alevel of maturity and
> functionality which means it really isn't worth it to start tinkering with a
> package like pandas, I don't know.
>
> What I do know is that Pandas has been immensely helpful for my particular,
> personal use, which is as an extended record array. The killer feature, in my
> view, is the ability to store heterogeneous data with integer- or label-based,
> possibly hierarchical, indexing. In my case, where my model consists of
> amplitude, fwhm, centroid parameter sets of multiple components of multiple
> transitions for multiple spatial regions of multiple exposures and /keeping
> track of which ones belong to the same physical subsystem/, Pandas is
> indispensable. It allows me to sort, regroup, etc. by a multitude of criteria.
> "Show me the amplitudes of all the components 'c' of the 10th through 21st
> spatial row of the Balmer lines" is a one-liner. The slicing-and-dicing
> capabilities are quite handy, also for someone who's never used R or done any
> statistical work worth mentioning.
I could be wrong, but I don't think anyone is arguing that Pandas isn't
incredibly powerful and useful. Pandas DataFrames simply aren't suitable as the
built-in "table" implementation in Astropy--on some level it's overkill, and on
other levels it's insufficient for some required use cases.
Erik
> It is true that TraitsUI (and Chaco, by the way), have had some stability
> issues, and unfortunately still have. I've found that the MacPorts packages work
> fine. But no, they are not as mature and thoroughly tested as e.g. Matplotlib.
> So if it were only for the plotting capabilities, the choive of matplotlib would
> be a no-brainer. But as we have both experienced, traitsui saves you a *lot* of
> coding time when building a simpler GUI. I honestly don't know if it is a good
> choice of basis for an affiliated package, all things considered, but I
> completely agree that it should stay well outside of core.
>
>
>
> On 20-06-2013 18:34, Erik Tollerud wrote:
>
>> I'm of mixed minds about traits UI because once you know it you can make great
>> GUIs with it, but I've spent a lot of time troubleshooting people's python
>> installations to get traits to work. That is, in general it can be tricky to
>> get installed because of all the dependencies. Maybe this has improved
>> recently with Enthought's Canopy (or other new python distros), but that's
>> been my past experience.
>>
>> More generally, the view in the astropy core package is that we don't want to
>> put GUIs in the core because GUIs always carry lots of dependencies, which we
>> don't want to be forced to deal with. But part of the whole reason for
>> affiliated packages was to get around this, so we're happy to see GUI-based
>> affiliated packages.
>>
>>
>> As for Pandas, to be totally honest, I don't see a huge amount to be gained
>> from adding a Pandas dependency Astropy. It's honestly not clear what it
>> gives the astronomy community that numpy does not already have. The following
>> quote from the Pandas web site has guided me to that conclusion:
>> "/pandas/ helps fill this gap, enabling you to carry out your entire data
>> analysis workflow in Python without having to switch to a more domain specific
>> language like R."
>>
>> I have been carrying out my entire data analysis workflow for some time now in
>> python without using Pandas. It looks to me like Pandas is a tool that was
>> written by and for statisticians who use R. While we can take lessons from
>> this, it's not clear we get much out of it in an astronomy context. For
>> example, how would it make astropy's NDData, Quantity, or Table better to use
>> a Pandas DataFrame vs. a numpy array? Most of what we are doing is
>> building astronomy-convenient interfaces, and I'm not sure what Pandas adds
>> there, at the cost of a pretty heavy-weight dependency.
>>
>> It could just be that I don't know enough about Pandas, though. So if someone
>> who knows Pandas better can speak to this, I'm all ears.
>>
>>
>>
>> On Tue, Jun 18, 2013 at 3:35 PM, Thøger Rivera-Thorsen <trive at astro.su.se
>> <mailto:trive at astro.su.se>> wrote:
>>
>> Pandas is a part of the newly-defined SciPy stack, after all, so that
>> would be part of any science-oriented distribution worth its salt. In
>> fact, I think it could be a good idea for astropy in general to use under
>> the hood, but again, could clash with the philosophy of the project and
>> possibly also maintainabillity.
>>
>> As for offering my code or just my experience, I'll have to square it with
>> my supervisor first, and I also think it depends on what direction the
>> project in question will take. I'm positive about the idea (which is why I
>> wrote in the first place), but supervisor might think it is a better idea
>> to actually get my paper in the project wrapped up before sending the code
>> out there. Will get back about that one!
>>
>> /Emil
>>
>>
>>
>>
>>
>> On 2013-06-18 20:53, Slavin, Jonathan wrote:
>>> Hi Emil,
>>>
>>> That looks very nice! I don't see Pandas as a big issue in terms of
>>> dependencies. I don't know that much about traits, etc. My thought
>>> about the gui was just based on my experience with matplotlib, and the
>>> fact that it is widely used -- though I would agree that too many
>>> dependencies can be a deterrent to people using something. Are you
>>> offering your code as a starting point for the project? It strikes me
>>> that many have gotten some sort of fitting package to a point of personal
>>> usability but no one has the time/interest/motivation to make a more
>>> generally usable package.
>>>
>>> Jon
>>>
>>> On Tue, Jun 18, 2013 at 2:34 PM, <astropy-request at scipy.org
>>> <mailto:astropy-request at scipy.org>> wrote:
>>>
>>> Date: Tue, 18 Jun 2013 20:39:55 +0200
>>> From: Th?ger Rivera-Thorsen <thoger.emil at gmail.com
>>> <mailto:thoger.emil at gmail.com>>
>>> Subject: Re: [AstroPy] ESA Summer of Code in Space 2013
>>> To: astropy at scipy.org <mailto:astropy at scipy.org>
>>> Message-ID: <51C0A97B.8090703 at gmail.com
>>> <mailto:51C0A97B.8090703 at gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> I have been working on a fitting GUI for a while, although it is made
>>> with a specific task in mind.
>>> However, it is not based on Matplotlib but on Traits/Traitsui/Chaco and
>>> Pandas. It is made for a specific projhect I'm working and as such not
>>> yet usable for more general cases, but it could be a starting point, if
>>> the dependencies don't conflict with astropy politics.
>>>
>>> Especially, I am happy about the choice of Pandas for managing a quite
>>> complex data structure (the fitted and/or guessed values of an arbitrary
>>> number of transitions for an arbitrary number of rows or collapsed rows
>>> of a spatially resolved spectrum) of a), but also with the Traits-based
>>> interactive interface to build complex line profiles from single
>>> gaussians, good for fitting-by-eye and giving good initial guesses for
>>> fitting of complex line profiles. It hooks directly up to a wrapper I've
>>> made for lmfit, but given the modularity, it should be relatively easy
>>> to change to other backends.
>>>
>>> It's still a work-in-progress, but there are some screenshots here:
>>> http://flic.kr/s/aHsjGaEMGg .
>>> I know the choice and number of dependencies may be prohibitive but it
>>> saved a lot of work on the GUI, and Pandas means the difference between
>>> sanity and madness when it comes to keeping track of so many parameters.
>>>
>>> Cheers,
>>> Emil
>>>
>>>
>>>
>>>
>>> ________________________________________________________
>>> Jonathan D. Slavin Harvard-Smithsonian CfA
>>> jslavin at cfa.harvard.edu <mailto:jslavin at cfa.harvard.edu> 60 Garden
>>> Street, MS 83
>>> phone: (617) 496-7981 <tel:%28617%29%20496-7981> Cambridge, MA
>>> 02138-1516
>>> fax: (617) 496-7577 <tel:%28617%29%20496-7577> USA
>>> ________________________________________________________
>>>
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>>
>> --
>> Erik
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
More information about the AstroPy
mailing list