[SciPy-Dev] GSOC - sparse improvements, dtypes introduction
Wed Apr 17 15:36:26 CDT 2013
I've started preparing a proposal relating to sparse matricies, however
this is subject to change.
To get aquainted with the code I've been exploring a few bugs related to
the sparse module. I'm trying to figure out how to add support to the
toarray() method for bool matricies (see #1153
http://projects.scipy.org/scipy/ticket/1533 ) and written up what I've
found on my blog. However I ran into a bit of a wall at the SWIG wrapper.
Which I have not had time to explore today. In particular, where is the
class T is coming from in
My blog is here: http://cwl.cx
On Wed, Apr 17, 2013 at 2:59 PM, Ralf Gommers <firstname.lastname@example.org>wrote:
> On Tue, Apr 16, 2013 at 5:59 PM, Blake Griffith <
> email@example.com> wrote:
>> The sparse matrix issues are the most interesting to me. I am reading up
>> on issues with the package and testing them. However are there already
>> enough people working on this?
> Hi Blake, welcome. In my opinion it would be good to have a GSoC project
> on this. One other student (Izzy) has expressed interest in it so far, but
> I haven't seen a follow-up to his first email yet. Daniel Smith also wants
> to continue improving this functionality outside of GSoC, but two is not a
> I haven't yet seen a situation where several students want to work on the
> same topic, and we have no clear rules/policy. So I'll just point out a few
> things that may be helpful in choosing a project:
> - the projects listed on the ideas page aren't the only ones that we'll
> consider. if you have another idea related to any of the main Scipy
> submodules, that's perfectly fine. Given the interests of mentors and core
> developers, I'd say these are good modules to work on (others are too small
> or too much in need of maintenance):
> sparse, optimize, stats, signal, interpolate, spatial, linalg, special.
> - the application process is competitive. We'll have to rank proposals
> anway, if we do get two proposals on the same topic we'll still rank them
> according to the proposal quality, interaction with applicants on the
> mailing list and the PRs made so far.
> I'm trying to get a feeling for how much of a scope these bugs have, and
>> what would be worthy of writing a proposal about.
>> It seems like formulating a bool-handling specification would overlap a
>> bit with the larger issues around dtype handling. Maybe there is a
>> reasonable way to combine these without taking on too much work?
> I'm not sure about that. If you're referring to the "Pythonic dtypes"
> idea, then I think those are fairly orthogonal. The dtypes project would
> likely be the more challenging of the two.
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev