[Numpy-discussion] GSOC 2013

[Todd]

On Mon, Mar 4, 2013 at 9:41 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
>
> On Tue, Feb 26, 2013 at 11:17 AM, Todd <toddrjen at gmail.com> wrote:
>
>> Is numpy planning to participate in GSOC this year, either on their own
>> or as a part of another group?
>>
>
> If we participate, it should be under the PSF organization. I suspect
> participation for NumPy (and SciPy) largely depends on mentors being
> available.
>
>
>> If so, should we start trying to get some project suggestions together?
>>
>
> That can't hurt - good project descriptions will be useful not just for
> GSOC but also for people new to the project looking for ways to contribute.
> I suggest to use the wiki on Github for that.
>
> Ralf
>
>
>
>
I have some ideas, but they may not be suitable for GSOC or may just be
terrible ideas, so feel free to reject them:

1. A polar dtype.  It would be similar to the complex dtype in that it
would have two components, but instead of them being real and imaginary,
they would be amplitude and angle.  Besides the dtype, there should be
either functions or methods to convert between complex and polar dtypes,
and existing functions should be prepared to handle the new dtype.  I it
could be made to be able to handle an arbitrary number of dimensions this
would be better yet, but I don't know if this is possible not to mention
practical.  There is a lot of mathematics, including both signal processing
and vector analysis, that is often convenient to work with in this format.

2. We discussed this before, but right now subclasses of ndarray don't have
any way to preserve their class attributes when using functions that work
on multiple ndarrays, such as with concatenate.  The current
__array_finalize__ method only takes a single array.  This project would be
to work out a method to handle this sort of situation, perhaps requiring a
new method, and making sure numpy methods and functions properly invoke it.

3. Structured arrays are accessed in a manner similar to python
dictionaries, using a key.  However, they don't support the normal python
dictionary methods like keys, values, items, iterkeys, itervalues,
iteritems, etc.  This project would be to implement as much of the
dictionary (and ordereddict) API as possible in structured arrays (making
sure that the resulting API presented to the user takes into account
whether python 2 or python 3 is being used).

4. The numpy ndarray class stores data in a regular manner in memory.  This
makes many linear algebra operations easier, but makes changing the number
of elements in an array nearly impossible in practice unless you are very
careful.  There are other data structures that make adding and removing
elements easier, but are not as efficient at linear algebra operations.
The purpose of this project would be to create such a class in numpy, one
that is duck type compatible with ndarray but makes resizing feasible.
This would obviously come at a performance penalty for linear algebra
related functions.  They would still have consistent dtypes and could not
be nested, unlike python lists.  This could either be based on a new
c-based type or be a subclass of list under the hood.

5. Currently dtypes are limited to a set of fixed types, or combinations of
these types.  You can't have, say, a 48 bit float or a 1-bit bool.  This
project would be to allow users to create entirely new, non-standard dtypes
based on simple rules, such as specifying the length of the sign, length of
the exponent, and length of the mantissa for a custom floating-point
number.  Hopefully this would mostly be used for reading in non-standard
data and not used that often, but for some situations it could be useful
for storing data too (such as large amounts of boolean data, or genetic
code which can be stored in 2 bits and is often very large).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130304/359c1f03/attachment.html>