[Matrix-SIG] Numerical python on SourceForge?

[Paul Barrett]

In the same vein of this discussion, I would also like to see several
fundamental enhancements to Numerical python:

1) I've yet to become competent using the Object type in Numeric.
   I've seen the example in the documentation of creating an array of
   Objects by ingesting a list of tuples, but have yet to understand
   how to create such an array from a string or file, which appears to
   me to be a more common - and faster - way of ingesting the data.
   As a result I've implemented my own C-type called 'record' which is
   basically a generalization of the struct module to arrays.  The
   record module enables quick and efficient access to sub-arrays and
   subfields of the record.  The implementation - though pretty basic
   at this time - is very similar to Numeric.  Instead of specifying a
   single type code, you specify a list of type codes.  Therefore it
   would seem logical to merge my record module into Numeric, assuming
   Numeric cannot do what my module can.  I'm hoping that this is what
   Max Skaller is suggesting.

2) The issue of up-casting of types has been mentioned in the Matrix
   SIG many moons ago.  This is still a very important issue for me
   and others in the astronomical community.  Astronomical images of
   16 million pixels and larger are now routinely being taken.  The
   analysis of such images - at least on a first look basis - are not
   very complicated, therefore simple array manipulation methods are
   quite satisfactory.  Yet the problem that we have is storing and
   manipulating this images in memory.  We're talking 128 MB of RAM
   for just storing a double precision 16M pixel image, when 64 MB or
   less will do.  I see two solution here: 1) add an option to prevent
   up-casting, 2) memory mapping of these large arrays, or 3) both.  I
   will likely have to implement my own Numeric module if this issue
   is not implemented satisfactorily.

3) Enable Numeric arrays to accept another array as an array
   argument.  This would enable a more efficient implementation of
   scatter/gather behavior.  This issue appears to be more of a Python 
   language syntax issue that an implementation issue, I believe.

I'm open to other suggestions on these issues as long as they give
similar results and the syntax is not overly cumbersome.  I've had
little time to work on these issues in the past, but hope to find some
time in the next few months to investigate these issues in greater
detail.  To reiterate, for Numerical Python to be useful to the
astronomical community, these issues will have to be dealt with and the 
soon they are, the better.

 -- Paul

-- 
Dr. Paul Barrett       Space Telescope Science Institute
Phone: 410-516-6714    ESS/DPT
FAX:   410-516-8615    Baltimore, MD 21218