[Matrix-SIG] Numerical python on SourceForge?

[Travis Oliphant]

> 
> 	There is _currently_ no risk at all of an incompatibility with
> Viper, since Viper does not even support the array module.
> Viper doesn't have any array handling at all.
> 
> 	My problem is that NumPy doesn't _quite_ provide the
> technology required for Fish, which is the best array handling around.
> In particular, incorporation of Fish 1 style arrays into Viper,
> if it is possible, would provide it with the fastest array 
> handling in the world.

Best is a pretty subjective measure.  Fish may be fast but is it
convenient to use in an interactive setting?  This is a more difficult
balance to achieve.

> 
> 	Fish generates, compiles, and executes optimal code for array
> algorithms. This is MUCH faster than any subroutine library could
> ever be. Fish is also suitable for both vectorisation and
> distributed parallel processing.

What does it mean to generate and compile optimal code?  Everytime I do an
array operation the compiler is called?  How does that work in an
interactive session.  What kinds of cross-platform issues are there?

> 
> 	So there is an opportunity, perhaps, to make Python/Viper
> the premier _industrial_ array processing language (outperforming
> normal usage of fortran and C).

That sounds very good, but it would sound even better if it would not
require drastic changes to the basic NumPy syntax.  
> 
> 	The style of Fish array handling integrated with Python
> would be to use Python syntax to write array algorithms,
> NOT subroutines for things like componentwise addition.
> 
> 	The reason is that such code can be 'inlined'
> and optimised in a way that is impossible with 'opaque' routines.
> Of course, some standard routines like componentwise addition
> would be provided, and have the same syntax (probably) as used
> by NumPy.
> 
> 	Fish currently uses an ML like front end, and it is not
> clear that a Python like syntax can be used instead.
> 

ML-like front ends have a hard time capturing the attention of
many scientists and engineers for day to day Numeric work.  I have not had
much experience with them, but there is a reason that MATLAB is popular.

> 	If NumPy has a problem, it is that the 'type' of
> arrays is deficient: it is NOT enough to support just
> some numeric cases and PyObject: it is _essential_ that
> the type be recursive -- that is, NumPy arrays be allowed
> as well.
> 

NumPy arrays are allowed currently.  They are just another object that can
be placed in an array.   What do you mean?

> 	I'd like to see the 'type-code' used in NumPy
> be replaced by a proper object representing an array shape:
> floats, PyObjects, etc, are degenerate cases of this.
> 

I'm not sure what you mean here either.  Could you sketch your idea of
what the C structure of the NumPy array should look like?

> 	I'm not sure this change can be made compatible
> with NumPy -- but it sound feasible [the existing type
> codes are a special encoding of degenerate cases of the
> more general types.

Again an example would help me see what you mean.


Travis