Proposal: add vector arithmetic to array module

[Chris Barker]

Paul Rubin wrote:
> Are you proposing to eliminate the array module?  That's a serious
> question--NumPy pretty much duplicates it, after all--any missing
> array module features can easily be merged into NumPy.

The only reason I would keep the array module around is for backwards
compatability, but that's just my opinion, and the array module does
have support for a few things that Numeric doesn't (fromfile, tofile,
and append come to mind). If all you want is a way to efficiently store
a homogenous sequence, the the array module is a reasonable choice.

But that is not all you want: you want o be able to do element-wise math
on arrays as well (note that there is a PEP about element-wise
operations on sequences on general: one that I strongly support). I
think Tim Peters is right: it is the thin edge of the wedge, once you
have elementwise math operation, you're likely tho then ask why the
array's can't be 2-d (or higher dimensions), then you'll want to be able
to use math functions like sin and cos on the whole array, and then
you'll have Numeric!

> > BTW, MacPython includes Numeric, and it is part of the extended module
> > support of ActiveState Python, so it's really not hard for your users to
> > download.
> 
> What if they're not using Macintoshes?

Then they can use the ActiveState distribution (Windows and Linux,
anyway) and run pyppm to install Numeric (I'n not sure of the pyppm
command, I havn't used it myself)

> Actually, if we're discussing OS-specific distributions, it would be
> good to be able to distribute Windows apps WITHOUT needing the user to
> install Python.  That is, I'd like to release a single .exe that
> includes my .pyc files, the Python interpreter core, and the minimal
> set of libraries needed to make my app run.  Is that feasible with the
> stuff you're describing?  I'm a near-total Windows ignoramus.

That's what Py2exe and McMillan's installer do (Installer works on
Linux, as well, I believe) Everything gets put into one *.exe file
except the dlls, as those have to be separate as far as the os is
concerned. It's a pretty nifty approach.


Paul Rubin wrote:
> No, NumPy is NOT what I want:
> 
> 1) doesn't come with Python

I do agree that that is an issue, but not as big a one as you think it
is. Frankly, despite the "batteries included" philosophy, I think it is
very hard to develop a substantial Python app without using a non-lbrary
module or two.

> 2) not maintained by Python maintainers

It is well maintained, which is good enough for me.

> 3) Only handles floating point data, not integer.  

Not true. Numeric arrays can be any one of a number of types (all the C
standard types, plus some more: Complex (double) Complex (Single),
Python Float(C double), C float, Unsigned Int8, Int8, Int16, Int32,
character: that's a pretty full set)

> For example
>    it doesn't provide vector boolean operations (I just remembered this--
>    so earlier when I said I'd use it if it was part of standard Python,
>    I was in error).

Is this what you mean?

>>> a = array((1,2,3,4))
>>> b = array((2,2,2,2))
>>> a > b
array([0, 0, 1, 1])

or this?

>>> a & 2
array([0, 2, 2, 0])
>>> a & b
array([0, 2, 2, 0])

> Anyway, NumPy is ridiculous overkill if all I want to be able to do
> is quickly xor two strings together, something like
>   a = array.array('b', str1)
>   array.xor(a, a, array.array('b', str2))

like:
>>> a = array(str1,'b')
>>> a
array([ 97,  32, 115, 116, 114, 105, 110, 103],'b')
>>> b = array(str2,'b')
>>> a ^ b
array([ 0, 78, 28,  0, 26, 12, 28, 71],'b')

or:

>>> logical_xor(a,b)
array([0, 0, 0, 0, 0, 0, 0, 0],'b')
>>>

As for overkill: do you want batteries included or don't you? It seems
you are asking for: "The functions I happen to need at the moment, and
nothing more". That's not really a good way to determione a feature set
to be added to a standard library.

> Documentation good.  PDF documentation bad.  I see there's an HTML
> version of the docs on pfdubois' site (it's not in the Sourceforge
> site) but it's not clear where the doc sources are.  Any idea?

No, Paul seems to keep the doc sources fairly close to his chest; I
don't know why.

> But it's bizarre to have to make multiple OS-specific
> distributions of an app written entirely in Python and that uses no
> complicated system calls.

yes, it is unfortunate, but is there a better alternative in ANY
language? Frankly, I am an advocate of a "Complete Python" distribution.
One that would have all the major, well supported packages. It would be
pretty big, but bandwidth and disk space are in much greater supply than
they used to be, so I don't think folks would mind. ActivePython is a 7
MB download, I'm not sure doubling that would make all that much
difference. It would be a whole lot easier than going to different
places to get all the modules you need.
 
> I think what's really needed is something like JAR files, for packaging
> Python apps.  Maybe they could be called CAN files (snakes in a can) <wink>.
> There was some discussion of this earlier so maybe something will happen.

I think there are a lot of folks that want something like this...I
imagine it will happen eventually.

> I thought "batteries included" was already supposed to be part of Python's
> philosophy, not something that there needed to be a push to create.

Batteries, yes. Accessories, no. There is, quite reasonably, a very high
standard for what will be added to the standard library. It needs to be
robust, broadly useful, fit well with Python, and be maintainable by the
core Python team. There is no system in place to centrally maintain all
the added packages that one might want in a "Complete" python. It's a
bit if a conundrum. If you want to help with the "Complete Python"
project, let me know. I envision something like a Linux distribution on
a smaller scale. RedHat, Suse, Debian et.al. do not maintain the kernal,
or, for that matter most of the other packages. What they do is put them
all together into a cohesive whole. That's what Python needs.
ActiveState is making a start at this, by the way.

> Generally, adding functionality to an existing module is easier.
> Especially when, as in the particular functionality we're discussing,
> it's not really "a bunch".  I don't know if that's the answer you
> wanted <wink>.

The "bunch" is debatable. What you want is array-oriented functionality:
You may only have a need for a small set of functions at the moment, but
once you get used to it, you are very likely to want more, and even if
you don't, others will. That's why NumPy was born.

You really should give NumPy a shot...it is too good to dismiss, and
worth the added effort of installing and distributing it.

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------