[Matrix-SIG] Numerical python on SourceForge?
Sun, 9 Jan 2000 22:43:34 -0600 (CST)
> 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.