[Matrix-SIG] Numpy in Viper

[skaller]

Konrad Hinsen wrote:
> 
> >       Functional operations, such as 'map' and 'reduce'
> > do not use indexing; that is, they represent loops, but
> > the loops are not written explicitly. Therefore, the 'indexing'
> > scheme must be embodied in the data structure they are applied to.
> 
> Not necessarily; in J, you would add a modifier to the map operation
> to give it some specific rank. 

	You are right. In fact, the very point of FISh is that
the _same_ modifier can equally well be applied to either the
data _or_ to the operator. Indeed, it is the 'commutativity'
which is the heart of the strengthened polymorphism FISh makes
available.

> OK, then the (map undim) interpretation is the J way of doing it. In
> NumPy, you can only modify the array shape. For mapping a
> two-dimensional object, you have to reshape the array, rolling the
> mapped dimensions into one, then apply map(), and then reshape again.
> A more general map() could be implemented without breaking any
> compatibility, but I don't see an easy way to provide a general
> mechanism for deriving structural operations.

	I already know how to do this, the issue here
is compatibility. There is no doubt the FISh functionality
is superior _technically_. However, compatibility is always
very important.

	The questions are:

	a) is it worth the effort for Python to provide native arrays

If YES: (my belief)

	b) should NumPy be ignored in favour of the FISh mechanism?

If NO: (my belief)

	c) should NumPy be supported but deprecated?

If NO: (I am not sure: hence questions on this forum)

	d) Should we attempt to make the two mechanisms compatible

It is my belief that (d) would be the best option IF it is, in fact
possible. (c) is the next best option.

> >       Polymorphism. In 'classic' functional programming
> > languages, 'map' is type polymorphic in the sense that in
> 
> Fine, but the question was about a *practical* application, not
> one of principle or elegance (which doesn't mean I don't care,
> but it's good idea to keep in mind that programing languages
> are made to solve real-life problems).

	Sigh. Would you go back to writing machine code?
What is the 'practical' application of a high level language?

	You are asking the same question. I'm sure you already
know the answer. It is why you write Python not C or Fortran.
Elegance is vital. It is the very heart of computing.
It is, indeed, just another word for abstraction :-)

-- 
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller