[Matrix-SIG] Numerical python on SourceForge?

[skaller]

Janko Hauser wrote:
> 
> If a restructuring of the development model is considered, I would
> like to raise some more questions. I agree with Travis that a
> decision regarding the inclusion of parts of NumPy into python should
> be made. Questions under this topic are:
> 
> - What parts? Is it important to be compatible with jpython or viper?
>   If nD-arrays go into the core, become they part of the language?

	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.

	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.

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

	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.

	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.

	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 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.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850