[Matrix-SIG] Numerical python on SourceForge?
Mon, 10 Jan 2000 14:46:13 -0500 (EST)
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.
Dr. Paul Barrett Space Telescope Science Institute
Phone: 410-516-6714 ESS/DPT
FAX: 410-516-8615 Baltimore, MD 21218