[AstroPy] Summer scholar

Tue Aug 3 15:18:46 EDT 2010

I definitely agree that scipy.ndimage needs some work... but a
re-write/fixup is probably a perfect Google Summer of Code project...
then hopefully whomever ended up as the mentor could then take
responsibility as the maintainer even if they didn't have time to
really dig into the code as much as the student would.

Also, regarding Rene's suggestions: Those are definitely usefule
tasks, and re-writing astrolib functions is a straightforward way to
have a well-defined task, but for a physics student (which likely
means no IDL background), that requires learning two languages.
that's a pretty big lead-up to getting anything really at all done...
and is it really a good idea  to spoil a fresh new student's mind by
forcing them to first learn IDL before python :) ?

It does depend on the student, but for something with a decent
algorithmic description (e.g. daophot, for which the papers pretty
much say it all), it might be better to define a task, and then let
the student do it from the ground up in a more pythonic fashion.  By
that I mean both the improvements Rene described that are available
using numpy tricks, as well as following python constructs
(object-oriented, proper exceptions, etc) instead of being tied to an
IDL-style function-calls-only way of thinking.

I would also point out, for those that are interested, that there is
groundwork already in place for PSF and aperture photometry in
astropysics (in the phot module -
http://packages.python.org/Astropysics/coremods/phot.html).  Not much
of it is really in a generically workable state yet, but many of the
pieces (background estimation, PSF model classes, an object-oriented
pipeline for ccdproc tasks, etc) are in place.  It mostly needs to be
put together and polished, so maybe that's a task for a summer
student, either within astopysics itself, or using those as a starting
point...

On Tue, Aug 3, 2010 at 11:17 AM, James Turner <jturner at gemini.edu> wrote:
> Yeah, the whole of ndimage needs rewriting (the code is also
> somewhat impenetrable and doesn't have a proper maintainer). That's
> a fairly daunting task and no-one has had time to do it so far. A lot
> of us need that code, so sooner or later I think someone may have to
> bite the bullet... I wish we had the time.
>
> Cheers,
>
> James.
>
>
> Jonathan Slavin wrote:
>> One thing that I'd like (don't know if a summer student could do it) is
>> to improve on the multidimensional filtering/smoothing in scipy. We had
>> some discussions about this a little while back.  Specifically the
>> ndimage.filters.uniform_filter and others in that module are implemented
>> in multiple dimensions via a series of 1-D filters in each dimension --
>> which is not the same as a truly multi-dimensional filter.  Maybe this
>> is not something there is much interest in, though anyone who wants to
>> remove some noise in a 2-D image might be interested.
>>
>> Jon Slavin
>>
>> On Tue, 2010-08-03 at 12:00 -0500, astropy-request at scipy.org wrote:
>>
>>> Message: 1
>>> Date: Tue, 3 Aug 2010 00:04:37 -0400
>>> From: Rene Breton <superluminique at gmail.com>
>>> Subject: Re: [AstroPy] Summer scholar
>>> To: astropy at scipy.org
>>> Message-ID: <17371E6A-230E-4B3C-8977-115C0041E03B at gmail.com>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Hi everyone,
>>>
>>>
>>> Thanks for sharing your tips/library Stefano. Indeed a matching
>>> routine would be very nice to have so people should definitely aim to
>>> have something that makes use of several criteria such as distance and
>>> magnitude (in a more generic way). The Groth/Stetson algorithm seems
>>> very good but maybe yours is similar or can do better. Worse case,
>>> both can be put in under different names a little bit like the
>>> different root finding algorithms in scipy.optimize. You can never
>>> have enough algorithms to get around pathological problems.
>>>
>>> Now, regarding Wolfgang's post, I very much agree with his ideas. I
>>> have to say that I've already implemented the "find" from "find.pro"
>>> in IDL's astrolib, which works really well in order to identify point
>>> sources. At the same time, I've modernized the program so that it
>>> takes advantage of numpy's array algebra, hence there are no slow "for
>>> loops". Maybe other algorithms could be worked out but this one
>>> certainly works well and it would be a shame to re-invent the wheel
>>> and have someone redo it. I think it should have been committed in the
>>> "pyastrolib" project that I was part of. If not, I'm very happy to add
>>> it here.
>>>
>>> I'm also not very far from having a re-brewed "aper" function working,
>>> from "aper.pro" in IDL's astrolib but there are a couple of function
>>> dependencies that I haven't had try to code. So maybe the students
>>> could start from there in their coding.
>>>
>>> Here are two ideas that I'd like to throw in for the student project,
>>> but they also apply in a more general way:
>>> 1. IDL's astrolib is a good start. The phot/daophot stuff from IDL's
>>> astrolib is generally pretty good, though it would gain to be
>>> modernized (and make use of array operations for instance). Since IDL
>>> and python are arguably similar, it would probably be not too
>>> difficult for someone with minimal experience to port some IDL code to
>>> python. Then one can optimize it.
>>> 2. Working on new photometry algorithms. Despite students may have
>>> limited programming background, they might be clever physicists. There
>>> are different algorithm using maximum entropy and such that can try to
>>> optimized the number of fitted sources. Among other interesting things
>>> would be algorithms/functions to derive photometric upper limits. This
>>> is what annoys me most and IDL's astrolib totally misses it. For PSF
>>> photometry, a routine that adds fake stars and tries to retrieve their
>>> flux in order to asses upper limits would be awesome. Something should
>>> also be done for aperture photometry.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Rene
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>

-- 
Erik Tollerud