[AstroPy] AstroPy Digest, Vol 81, Issue 12
Thøger Emil Rivera-Thorsen
thoger.emil at gmail.com
Thu Jun 20 17:08:12 EDT 2013
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20130620/932b19c9/attachment.html>
More information about the AstroPy
mailing list