numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] big picture? One proposal

[Rick W. <rl...@st...>]

On Fri, 8 Mar 2002, Konrad Hinsen wrote:

> "Perry Greenfield" <pe...@st...> writes:
> 
> > Rick White has also convinced me that this alone isn't sufficient.
> > There are numerous occasions where people would like to use matrix
> > multiply, even in a predominately "array" context, enough so that this
> > would justify a special operator for matrix multiplication. If the 
> 
> Could you summarize those reasons please? I know that there are
> applications of matrix multiplication in array processing, but in my
> experience they are rare enough that writing dot(a, b) is not a major
> distraction.

A couple of quick examples: I do lots of image processing (e.g. deconvolution)
using arrays.  It is often helpful to take the outer product of two 1-D
vectors; e.g. if there is a separable function f(x,y) = g(x)*h(y), you can
compute separate g & h vectors and then combine them with outer product (a
special case of matrix multiply) to get the desired 2-D image.

Another example: when I'm working with either 2-D images or 1-D vectors, it
is helpful to be able to compute projections using a set of basis vectors
(e.g. for singular value decomposition, eigenvectors, etc.)  This is most
easily expressed using matrix multiplies - but most uses of the data still
treat them as simple arrays instead of matrices.  Being able to group these
operations together is helpful both for readability of the code and for
efficiency of execution.

Having said that, I think I actually agree with Konrad that these sorts of
operations are rare enough (in the data processing context) that it is no
great burden to write them using function calls instead of operators.  If we
could agree on a matrix-multiply operator, that would be nice -- but if we
can't, I can live with that too.  For my purposes, I certainly don't see the
need to add special operations to do things like transpose.  Those should be
limited to a separate matrix class as Konrad proposes and should be
available as function calls for arrays.
					Rick

------------------------------------------------------------------
Richard L. White    rl...@st...    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD

Re: [Numpy-discussion] big picture? One proposal

[Pearu P. <pet...@ma...>]

On Fri, 8 Mar 2002, Konrad Hinsen wrote:

<snip>
> Unfortunately, I have the impression that there are two schools of
> thought in collision here (and not just when it comes to programming).
> There is the "mathematical" school that defines matrices and arrays
> as abstract entities with certain properties and associated operations.
> And there is the "engineering" school that sees arrays as a convenient
> data structure to express certain operations, of which "matrix operations"
> are a subset.

I see arrays as a convenient data structure (being implemented in
computer programs) to hold matrices (being members of a mathematical
concept).
I guess that my views are narrow-minded (but willing to widen it)
regarding to consider arrays as a mathematical concept too. Just in
mathematics I never (need to) use arrays in that way (my fields are
mathematical analysis, integrable systems, and not computer science nor
engineering). So, I also belong to the school of "mathematics", but may
be into a different one.

<snip>
> That's another point where I disagree. I use Python for many different
> uses, numerics is only one of them (though the most important one).
> Uniformity of style is an important value for me.

Me too. Just I am not too crazy about the constant style but more of if
something can be accomplished efficiently. To be honest, I don't like
programming  in Python because it has a nice style, but because I can
accomplish a lot with it in a very efficient way (and not only by using
efficient algorithms). Writing, for example, Numeric.transpose(a) instead
of a**T, a.T, a`, or whatever just reduces this efficiency.

I also realize and respect that for computer scientists (that I presume
the developers of Python are) it is crucial to have consistent style for
their reasons. Sometimes this style makes some site-specific simple tasks
too verbose to follow.

> Moreover, I claim that Python *does* provide a good solution, it is
> merely a very different one.

So, what is it?

<snip>
> Does that work? I'd expect that a**T would first call .__pow__(T)
> which quite probably crashes... (Not that it matters to me, I find
> this almost as abusive as the matrix attributes.)

Yes, it works:
>>> from Numeric import *
>>> class T: __rpow__ = lambda s,o: transpose(o)
...
>>> print array([[1,2],[3,4]]) ** T()
[[1 3]
 [2 4]]

And I don't understand why it is abusive (because it is a different
approach?). It's just an idea.

Pearu

Re: [Numpy-discussion] big picture? One proposal

[Konrad H. <hi...@cn...>]

> situation. My general point is that a _good_ solution is simple,
> if a solution is not simple, then it is probably a bad solution.

Agreed. So we just need to agree on what is "simple".

> I find separating array and matrix instances (in a sense of raising
> exception when doing <matrix> <op> <array>) not a very simple solution:
>   New concepts are introduced that actually do not solve the simplicity
> problem of representing matrix operations. As I see it, they

I disagree there, separating the concepts of matrix and array *does*
solve the simplicity problem in my opinion. Matrices use operators for
common matrix operations, and arrays use the same operators for common
array operations.

> only introduce restrictions and the main assumption behind the rationale
> is that "users are dumb and they don't know what is best for them".

No, not at all. On the contrary, the rationale is "users are smart and
know that arrays and matrices are different"  ;-)

Unfortunately, I have the impression that there are two schools of
thought in collision here (and not just when it comes to programming).
There is the "mathematical" school that defines matrices and arrays
as abstract entities with certain properties and associated operations.
And there is the "engineering" school that sees arrays as a convenient
data structure to express certain operations, of which "matrix operations"
are a subset.

As a student, I had a friend who studied mechanical engineering, and
his math exercises made me go mad more than once. When I read "...the
vector of the masses...", I just had to scream ;-)  Many engineering
textbooks have the same effect on me.

Now obviously I belong to the "mathematical" school, but I don't
expect to convert everyone else to it. So my arguments will remain
pythonic and pragmatic: the "mathematical" approach solves the problem
without asking for new operators, and thus has a better chance of
getting realized.

> This is how I interpret the raised exception as behind the scenes matrix
> and array are the same (in the sense of data representation). 

But data representation and data semantics are two different things.
Readibility of code depends on semantics, not on internal
representations or even implementation. Using the same representation
merely implies that conversion should be efficient, but not
necessarily implicit.

> The main objection to this proposal seems to be that it deviates from a
> good pythonic style (ie don't mess with attributes in this way).
> I'd say that if python does not provide a good solution to our problem,
> then we are entitled to deviate from a general style. After all, in doing

That's another point where I disagree. I use Python for many different
uses, numerics is only one of them (though the most important one).
Uniformity of style is an important value for me.

Moreover, I claim that Python *does* provide a good solution, it is
merely a very different one.

> numerics the efficiency issue has a rather high weight. And a generally
> good style of Python cannot always support that.

Computational efficiency is not the issue here. If that's all you
want, call a BLAS routine for matrix multiplication with two array
arguments - doable today, without any modification of whatsoever.
Even Fortran programmers do that, instead of suggesting that Fortran
2002 should add a "multiply-by-calling-BLAS" operator.

> define
> 
> T = TransposeOp()
> H = TransposeOp(conjugate=1)

Does that work? I'd expect that a**T would first call .__pow__(T)
which quite probably crashes... (Not that it matters to me, I find
this almost as abusive as the matrix attributes.)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] big picture? One proposal

[Pearu P. <pe...@ce...>]

Hi,

On Fri, 8 Mar 2002, Konrad Hinsen wrote:

<removed relevant comments>

> > Numeric community is united on this, I think Guido would be receptive.
> > We might suggest a particular operator symbol or pair (triple) but 
> 
> Actually I feel quite safe: there might be a majority for another
> operator, but I don't expect we'd ever agree on a symbol :-)

Thanks Konrad for this excellent point. Seeing all these proposals about
solving our matrix-array issues makes also me feel safer with the current
situation. My general point is that a _good_ solution is simple,
if a solution is not simple, then it is probably a bad solution.

I find separating array and matrix instances (in a sense of raising
exception when doing <matrix> <op> <array>) not a very simple solution:
  New concepts are introduced that actually do not solve the simplicity
problem of representing matrix operations. As I see it, they
only introduce restrictions and the main assumption behind the rationale
is that "users are dumb and they don't know what is best for them".
This is how I interpret the raised exception as behind the scenes matrix
and array are the same (in the sense of data representation). 

Let me remind at least to myself that the discussion started from a
proposal that aimed to write matrix multiplication of arrays

  Numeric.dot(a,b)

in somewhat simpler form. Current solution is to use Matrix class that
being just a wrapper of arrays, redefines __mul__ method; and after
one has defined
  a = Matrix.Matrix(a)
the matrix multiplication of arrays looks simple:
  a * b

Travis's proposal was to reduce the first step and have it inside an
expression in a short form:

  a.M * b

(there have been two implementation approaches proposed for this: (i) a.M
returns a Matrix instance, (ii) a.M returns the same array with a
temporarily set bit saying that the following operation is somehow
special).
To me, this looks like a safe solution. Though it is a hack, at least it
is simple and understandable in anywhere where it is used (having a * b
where b can be either matrix or array, it is not predictable from just
looking the code what the result will be -- not very pythonic indeed).

The main objection to this proposal seems to be that it deviates from a
good pythonic style (ie don't mess with attributes in this way).
I'd say that if python does not provide a good solution to our problem,
then we are entitled to deviate from a general style. After all, in doing
numerics the efficiency issue has a rather high weight. And a generally
good style of Python cannot always support that.


I guess I am missing here a goal to get Numeric or numarray joined
to Python. With this perspective the only efficient solution seems
to be introducing a new operator (or new operators). Few candidates have
been proposed:

 a ~* b       - BTW, to me this looks like dot(conjugate(a),b).
 a (*) b      - note the in situ version of it: a (*)= b
 a (**) b     - looks ugly enough? ;-)
Actually, why not

 a [*] b, a {*} b

for direct products of matrices (BTW (*) seems more appropriate here). So,
my ideal preference would be:

  a .* b   - element-wise multiplication of arrays, 2nd pref.: a * b
   a * b   - matrix multiplication of arrays, 2nd preference: a [*] b
  a (*) b  - direct matrix multiplication (also know as tensor product)
             of arrays
    a~     - conjugate of arrays
    a`     - transpose of arrays

This looks great but requires many new features to Python (new operators, 
the concept of right-hand unary operator).

I don't think that Python should introduce these new operators just
because of Numeric community. It is fine if they get used in other fields
as well that suffer from the lack of operators.


About unary operations: transpose and conjugate. BTW, in complex linear
algebra their composition is equally frequent operator. Let me propose the
following solution: to have

  a ** T  for Numeric.transpose(a)
  a ** H  for Numeric.transpose(Numeric.conjugate(a))

define

T = TransposeOp()
H = TransposeOp(conjugate=1)

where

class TransposeOp:
    def __init__(self, conjugate=0):
         self.conjugate = conjugate
    def __rpow__(self,arr):
         if self.conjugate:
             return Numeric.transpose(Numeric.conjugate(a))
         return Numeric.transpose(arr)

Looks Pythonic to me;-)

Regards,
	Pearu

Re: [Numpy-discussion] big picture? One proposal

[Konrad H. <hi...@cn...>]

"Perry Greenfield" <pe...@st...> writes:

> That still leaves the question of how to do the conversions, i.e., one
> of the following options
...
> I strongly prefer the first (functional) form.

Me too. I wouldn't call it "functional" though, it's exactly the way
object constructors are written.

> Rick White has also convinced me that this alone isn't sufficient.
> There are numerous occasions where people would like to use matrix
> multiply, even in a predominately "array" context, enough so that this
> would justify a special operator for matrix multiplication. If the 

Could you summarize those reasons please? I know that there are
applications of matrix multiplication in array processing, but in my
experience they are rare enough that writing dot(a, b) is not a major
distraction.

Maybe we need to take another step back as well: Python is a
general-purpose language, with several specialized subcommunities such
as ours, some of them even more important in size. Most likely they
are having similar discussions. Perhaps the database guys are
discussing why they need two more special operators for searching and
concatenating databases.

I don't think such requests are reasonable. It is tempting to think
that it doesn't matter, if you don't need that operator, you just
don't use it. But a big advantage of Python is readability. If we get
our (well, *yours*, I don't want it ;-) matrix multiply operator, a
month later someone will decide that it's just great for his database
application, and the database community will have to get used to it as
well.

> Numeric community is united on this, I think Guido would be receptive.
> We might suggest a particular operator symbol or pair (triple) but 

Actually I feel quite safe: there might be a majority for another
operator, but I don't expect we'd ever agree on a symbol :-)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

RE: [Numpy-discussion] big picture? One proposal

[Perry G. <pe...@st...>]

Eric makes a good point about stepping back and thinking about these
issues in a broader context. Along these lines I'd like to make
a proposal and see what people think. I think Konrad made a very 
good point about matrix vs array representation. If we made it illegal
to combine them in expressions without explicit conversions, we could
prevent much confusion about what kind of operations would be performed.
An attempt to use one kind of in place of an other would trigger
an exception and thus users would always know when that was a problem.
Implementing this behavior in numarray would be simple, as would having
both share the same implementation for common operations (without any
extra performance penalty).

That still leaves the question of how to do the conversions, i.e., one
of the following options

matrix(a) * b  # matrix multiply of array (a) with matrix (b)
a.M * b
a.M() * b

likewise:

a * array(b)   # element-wise multiply of array (a) with matrix (b)
a * b.A
a * b.A()

I strongly prefer the first (functional) form.

Rick White has also convinced me that this alone isn't sufficient.
There are numerous occasions where people would like to use matrix
multiply, even in a predominately "array" context, enough so that this
would justify a special operator for matrix multiplication. If the 
Numeric community is united on this, I think Guido would be receptive.
We might suggest a particular operator symbol or pair (triple) but 
leave him some room to choose alternatives he feels are better for
Python (he could well come up with a better one). It would be nice
if it were a single character (such as @) but I'd be happy with many
of the other operator suggestions (~*, (*), etc.)

Note that this does not imply we don't need a seperate matrix object.
I think it is clear that simply providing a matrix multiply operator
is not going to answer all their needs.

As to the other related issues that Eric raises, in particular:
operators for transpose and complex conjugate, I guess I don't see
these as so important. Both of these are unary operators, and as such
either of the following options does not seem to be notationally much
worse (whereas using binary functions in place of binary operators is
much less readable)

transpose(x)    conjugate(x)
x.transpose()   x.conjugate()
x.T()           x.C()
x.T             x.C

(Personally, I prefer the first two)

Perry

Re: [Numpy-discussion] Adding a flag to allow integer array access and masking

[Konrad H. <hi...@cn...>]

> Are you suggesting something like:
> 
> b = IndexArray([1,3,10,100])
> 
> a[b]?

Exactly. With IndexArray being some special object (if only a thin
wrapper), that prints differently from a simple array and can be
type-tested.

> This is really not much different than.
> 
> a[[1,3,10,100],IndexArray]

Except that in the first case, there is exactly one indexing object
per axis, the operation can be a different one along each axis, and
the index object carries specifies its own meaning. But the effect
is the same, of course.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Adding a flag to allow integer array access and masking

[Travis O. <oli...@ee...>]

> No, I basically agree, I just don't have that need immediately and
> therefore am less motivated to work on it.
>
> My preferred solution would be to use special objects (in the spirit
> of the slice object) for special indexing methods, rather than special
> cases of existing objects. The advantage is that any number of those
> can be added over time as the need arises, and there is never a risk
> of changing the meaning of existing code.
>


Thanks for the comments you have made.  I always appreciate them.

Are you suggesting something like:

b = IndexArray([1,3,10,100])

a[b]?

This is really not much different than.

a[[1,3,10,100],IndexArray]

which is essentially what I've suggested (I was looking for shortcuts),
but in principle

IndexArray could be a class with a method that the code in Numeric
interfaces with.

> However, I do think that this should be thought out and discussed
> carefully, but unfortunately I won't be able to help much due to lack
> of time.
>

Thanks for participating thus far.

-Travis

RE: [Numpy-discussion] Numerical Python and LAPACK on 64-bit machines

[Paul F D. <pa...@pf...>]

If someone is going to make the change they should change the source to
use FortranInt or some similar typedef so that one ifdef could be used
to change it.

I believe the current lapack/blas were made by an automatic conversion
tool. It is easy to make a case that they shouldn't even be in the
distribution, that rather a user should install their own library.
However, this is a problem on Windows, where many users do not have a
development environment, and in general, because it makes the
instructions for installing more complicated. So we have sort of felt
stuck with it.

I have no real way of convincing myself that the proposed change won't
break some other platform, although it seems unlikely. 

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of Roman
Geus
Sent: Thursday, March 07, 2002 1:21 AM
To: num...@li...
Subject: Re: [Numpy-discussion] Numerical Python and LAPACK on 64-bit
machines


Hello,

Pearu Peterson wrote:
> 
> Hi,
> 
> On Wed, 6 Mar 2002, Roman Geus wrote:
> 
> > So, what really needs to be changed (at least for this machine) is 
> > how Numerical Python calls BLAS/LAPACK. It also needs to use 32bit 
> > integers. So this means using 'int' instead of 'long int'.
> 
> Having wrapped a lot of Fortran codes to Python, I agree, that 
> Numerical Python should use 'int' instead of, 'long'. Though I have 
> little influence to make this change to happen in Numeric but just 
> agreeing with you.
> 
> Pearu

What would be the best way to convince the NumPy developers to use 'int'
instead 'long' for Fortran integers?

I would be willing to help making the necessary changes.

-- Roman

_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] adding a .M attribute to the array.

[Konrad H. <hi...@cn...>]

> I believe the correct solution is a major upgrade to Matrix.py along the
> lines of what is done in MA; that is, to craft an object that uses
> Numeric for its implementation but which defines all its own operators
> in a manner that is semantically sensible for the type of object it is. 

That is exactly my idea as well. However, from a quick glance at MA,
it seems that this solution could suffer from performance problems
when done in Python. What are the real-life experiences with MA in
that respect?

I suppose the new type inheritance mechanisms in Python 2.2 could help
to make this more efficient, but I haven't used them for anything yet.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Konrad H. <hi...@cn...>]

> How do the new Iterator mechanisms now active in Python 2.2 play into
> these ideas of indexing objects?  Can we get these kinds of slices by
> providing appropriate iterator objects and references?

An iterator needs to be called for each element, which is probably too
slow for a general "extended indexing" solution. But an iterator
yielding boolean values could perhaps be a useful class of index
object in some cases.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] big picture?

[Andrew P. L. <bs...@al...>]

On Thu, 7 Mar 2002, eric wrote:

>     1.  Matrix Multiply -- should we ask for ~*?
>     2.  Transpose -- In a perfect world, we'd have an operator for this.
>     3.  complex conjugate -- An operator for this would also be welcome

I, personally, don't find the arguments particularly compelling for extra
operators for numeric stuff.  While extra operators may make code more
"math-like", "MATLAB-like" or "Fortran-like", it won't help with
efficiency.  If I have code to compute A*x+B*y+C, I'm going to have to
call out the A*x+Z and Z=B*y+C primitives as functions anyway.  No set of
binary operators will work out that optimization.

Requesting domain specific operators actually scares me.  The main problem
is that it is *impossible* to remove them if your choices later turn out
to be confusing or wrong.  If operators must be added, I would rather see
a generic operator mechanism in place in Python.

Choice 1 would be a fixed set of operators getting allocated (~* ~+ ~-
etc.) which the core language *does not use*.  Then any domain can
override with their special meaning without collapsing the base language
under the weight of domain specific extensions.  Now the specific domains
can make their changes and only break their own users rather than the
Python community at large.

Choice 2 would be for a way for Python to actually adjust the
interpretation semantics and introduce new operators from inside code.
This is significantly trickier and more troublesome, but has the potential
of being a much more generally useful solution (far beyond the realm of
numerics).  Furthermore, it allows people to make code look like whatever
they choose.

-a

Re: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Andrew P. L. <bs...@al...>]

On Thu, 7 Mar 2002, Konrad Hinsen wrote:

> So I am certainly agains "magic" objects, but different kinds of
> indexing objects, provided that they can be inspected/printed in the

How do the new Iterator mechanisms now active in Python 2.2 play into
these ideas of indexing objects?  Can we get these kinds of slices by
providing appropriate iterator objects and references?

-a

Re: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Konrad H. <hi...@cn...>]

Travis Oliphant <oli...@ee...> writes:

> > (a) To a person who only uses Numpy occasionally, it is not obvious
> > that an argument is "magic".   That makes the code less readable.
> 
> That can be a "problem", but it is a "problem" in many languages that
> currently are in wide-spread use in numerical computing.
> Apparently, the convenience outweighs the perceived concern.  Currently,

But some people, like me, prefer Python to other languages for exactly
that reason. I'll give up shortness for clarity any time.

So I am certainly agains "magic" objects, but different kinds of
indexing objects, provided that they can be inspected/printed in the
code, are nothing magic to me. At the moment, each axis index can be
an integer, a range, and a slice. Adding a "boolean mask" to this
seems like a natural extension. And even "reduction" operations such
as Paul mentioned make perfect sense.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Adding a flag to allow integer array access and masking

[Konrad H. <hi...@cn...>]

Travis Oliphant <oli...@ee...> writes:

> Well, I affirm that this is one of the drawbacks of Numeric as compared
> with other array-oriented environments.  We definitely need a way to index
> an array using integers and masks.
> 
> I guess if nobody else feels this way, then I'm alone in my discomfort.

No, I basically agree, I just don't have that need immediately and
therefore am less motivated to work on it.

My preferred solution would be to use special objects (in the spirit
of the slice object) for special indexing methods, rather than special
cases of existing objects. The advantage is that any number of those
can be added over time as the need arises, and there is never a risk
of changing the meaning of existing code.

However, I do think that this should be thought out and discussed
carefully, but unfortunately I won't be able to help much due to lack
of time.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] Numerical Python and LAPACK on 64-bit machines

[Roman G. <ge...@in...>]

Hello,

Pearu Peterson wrote:
> 
> Hi,
> 
> On Wed, 6 Mar 2002, Roman Geus wrote:
> 
> > So, what really needs to be changed (at least for this machine) is how
> > Numerical Python calls BLAS/LAPACK. It also needs to use 32bit integers.
> > So this means using 'int' instead of 'long int'.
> 
> Having wrapped a lot of Fortran codes to Python, I agree, that Numerical
> Python should use 'int' instead of, 'long'. Though I have little
> influence to make this change to happen in Numeric but just agreeing with
> you.
> 
> Pearu

What would be the best way to convince the NumPy developers to use 'int'
instead 'long' for Fortran integers?

I would be willing to help making the necessary changes.

-- Roman

Re: [Numpy-discussion] adding a .M attribute to the array.

[Konrad H. <hi...@cn...>]

"eric" <er...@en...> writes:

> Matrix.Matrix objects. This attribute approach will work, but I
> wonder if trying the "adding an operator to Python" approach one
> more time would be worth while. At Python10 developer's day, Guido

If it were only one operator, perhaps, although I might even give up
on Python completely if starts to use Perlish notations like ~@!.

But if you really want to have a short-hand syntax for the common
matrix operations, you'd need multiplication, division (shorthand for
multiplying by inverse), power, transpose and hermitian transpose.

If you want to go the "operator way", the goal should rather be
something like APL, with composite operators. Matrix multiplication
would then be a special case of a reduction operator that uses
multiplication and addition (in APL this is written as "+.x"). Note
that I am *not* suggesting this, my opinion is still that matrices and
arrays should be semantically different types.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] adding a .M attribute to the array.

[Konrad H. <hi...@cn...>]

"Perry Greenfield" <pe...@st...> writes:

> Not an unreasonable position. Are you also arguing that the two types
> should know about each other and raise an exception if there is an
> attempt to mix them in operations?

No need to know about each other, they'd be different types and
therefore by default incompatible. There should of course be some
explicit conversion facility.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] OverflowError: math range error

[Nils W. <nw...@me...>]

Hi,


>gdb /usr/bin/python
GNU gdb 20010316
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-suse-linux"...(no debugging symbols
found)...
(gdb) run fredholm.py
Starting program: /usr/bin/python fredholm.py
(no debugging symbols found)...[New Thread 1024 (LWP 13596)]
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
Traceback (most recent call last):
  File "fredholm.py", line 2, in ?
    from LinearAlgebra import *
  File "/usr/lib/python2.1/site-packages/Numeric/LinearAlgebra.py", line
10, in ?
    import MLab
  File "/usr/lib/python2.1/site-packages/Numeric/MLab.py", line 17, in ?
    import RandomArray
  File "/usr/lib/python2.1/site-packages/Numeric/RandomArray.py", line
30, in ?
    seed()
  File "/usr/lib/python2.1/site-packages/Numeric/RandomArray.py", line
24, in seed
    ndigits = int(math.log10(t))
OverflowError: math range error
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
Program exited with code 01.
(gdb)

Any idea ?

Thanks in advance.

Nils

[Numpy-discussion] big picture?

[eric <er...@en...>]

While we're discussing several big issues, it would be worthwhile to step back
and get an idea of what people feel is still missing for numeric computation in
the Python language and also what is missing from Numeric itself.  I'm not
talking about libraries here, but issues with notation and array functionality
that you run into in day-to-day programming.  Things are pretty dang good right
now, but there are some areas (array indexing, matrix multiply, etc.) that some
people see as sub-optimal or better implemented in other langauges.  A list will
provide a "big picture" of where we want to go (maybe we are there...) and also
help us pick our battles on language changes, etc.

So, what mathematical expressions are commonly used and yet difficult to write
in Python?  I don't mean integrals divergence, etc.  I mean things like matrix
multiply and transpose.  Here is a beginning to the list:

    1.  Matrix Multiply -- should we ask for ~*?
    2.  Transpose -- In a perfect world, we'd have an operator for this.
    3.  complex conjugate -- An operator for this would also be welcomed.
    4.  Others??

These three have all been discussed on this list or on the SciPy list in the
last month, so they are obvious.  I don't think there is a solution for 2 and 3
besides using the current function or method calls (but they are still on my
list).  As I mentioned in my last post, 1 might be fixable.

As far as core Numeric functionality:

    1.  Array indexing with arrays.
    2.  .M attributes -- an alternative to (1) in language changes.

And I'll add a third, that I'd like.

    3. tensor notation indexing as in the Blitz++ array library
        http://www.oonumerics.org/blitz/manual/blitz03.html#l75
        NewAxis and Ellipses allow for the same functionality, but
        the tensor notation is much easier to read.  This requires
        yet more indexing trickery though...

Please limit this thread to language changes or Numeric enhancements.  Desired
changes to the current behavior or interface of Numeric should be saved for a
different discussion.


thanks,
eric

--
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
(512) 536-1057

Re: [Numpy-discussion] adding a .M attribute to the array.

[eric <er...@en...>]

Boy did this one get a rise!  Nice to hear so many voices.

I also feel we need a more compact notation for linear algebra and would like to
be able to do it without explicitly casting arrays to Matrix.Matrix objects.
This attribute approach will work, but I wonder if trying the "adding an
operator to Python" approach one more time would be worth while.  At Python10
developer's day, Guido explicitly mentioned the linear algebra operator in a
short comment saying something to the affect that, if the numeric community
could agree on an appropriate operator, he would strongly consider the addition.
He also mentioned the strangness of the 2 PEPs proposed on the topic at a coffee
break...  I noticed the status of both PEPs is "deferred."

http://python.sourceforge.net/peps/pep-0211.html

    This one proposes the @ operator for outer products.

http://python.sourceforge.net/peps/pep-0225.html

    This one proposes decorating the current binary ops with some
    symbols to indicate that they have different behavior than
    the standard binary ops.  This is similar to Matlab's use of
    * for matrix multiplication and .* for element-wise multiplication
    or to R's use of * for element-wise multiplication and %*% for
    "object-wise" multiplication.

    It proposes prepending ~ to operators to change their behavior so
    that ~* would become matrix multiply.

    The PEP is a little more general, but this gives the flavor.

My hunch is that some form of the second (perhaps drastically reduced) would
meet with more success.  The suggested ~* or even the %*% operator are both
palitable.  Such details can be decided later.  The question is whether there is
sufficient interest to try and push the operator idea through?  It would take
much longer than choosing something we can do ourselves (like .M), but the
operator solution seems more desirable to me.

eric


----- Original Message -----
From: "Travis Oliphant" <oli...@ie...>
To: <num...@li...>
Sent: Tuesday, March 05, 2002 11:44 PM
Subject: [Numpy-discussion] adding a .M attribute to the array.


>
> Recently there has been discussion on the list about the awkwardness of
> matrix syntax when using Numeric Python.
>
> Matrix expressions can be awkard to express in Numeric which is a negative
> mark on an otherwise excellent computing environment.
>
> Currently part of the problem can be solved by working with Matrix objects
> explicitly:
>
> a = Matrix.Matrix("[1 2 3; 4 5 6]")     # Notice the strings.
>
> However, most operations return arrays which have to be recast to matrices
> using at best a character with parenthesis:
>
> M = Matrix.Matrix
>
> M(sin(a)) * M(cos(a)).T
>
> The suggestion was made to add ".M" as an attribute of arrays which returns a
> matrix.  Thus, the code above can be written:
>
> sin(a).M * cos(a).M.T
>
> While some aesthestic simplicity is obtained, the big advantage is in
> consistency.  Somebody else may decide that
>
> P = Matrix.Matrix  is a better choice.  But, if we establish that
>
> .M  always returns a matrix for arrays < 2d, then we gain consistency.
>
> I've made this change and am ready to commit the change to the Numeric tree,
> unless there are strong objections.   I know some people do not like the
> proliferation of attributes, but in this case the notational convenience it
> affords to otherwise overly burdened syntax and the consistency it allows
> Numeric to deal with Matrix equations may be worth it.
>
> What do you think?
>
> -Travis Oliphant
>
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Travis O. <oli...@ee...>]

> > > # 1000 lines later...
> > > access(a, _I) # Whoops all my assumptions were wrong...
> >
> > I have no idea, what your concern is here.  This would result in an error
> > currently and under the scheme I suggested.
>
>
> Then, perhaps you should explain again.

No you grasp it, I think your example contained errors (you only called
access with two arguments rather than the three expected by the interface,
for example).

Thank you for explaining your concerns in more detail, below.
>
> If so, I think that's a bad idea from a human-interface point of view,
> because
>
> (a) To a person who only uses Numpy occasionally, it is not obvious
> that an argument is "magic".   That makes the code less readable.

That can be a "problem", but it is a "problem" in many languages that
currently are in wide-spread use in numerical computing.
Apparently, the convenience outweighs the perceived concern.  Currently,
whenever you use variables to index arrays you know that something is
going on that you can't see by just looking at it (i.e. something fancy).

For example, you can currently write

a[b]

and have this do different things depending on whether b is a sequence or
a slice object or an integer.   I don't see how the addition of another
check drastically changes the current state.

I actually think the flexiblility is a good thing and it makes Python very
powerful.

It comes down to trusting people to write code you can understand (if
you have any reason to interface with them in the first place).

My programming philosophy definitely leans toward empowering people, even
if it means they can do something stupid later.

>
> (b) It is possible to write code where one can pass in the "magic" value
> in a variable, and no simple inspection of the code will tell if it is
> magic
> or not.

This is already possible (and frequently used), now.

> Using an explicit function or method call fixes (a) by telling the naive
> user
> that "this is not normal array access here."
>

You are focusing on the naive user at the expense of convenience for the
power user.  I think this is appropriate sometimes, but not when we are
talking about a language that somebody will use constantly for many years
to implement their daily work.

I think it makes the code much more readable and therefore understandable
and maintainable to overload the [] operator rather than use a method
call..

MATLAB's big advantage over Numeric Python right now is that it allows
this sort of indexing already which Python users currently have to
implement using a function call.


 > It also fixes (b) by making it more obvious that fancy
stuff is going > on.
>

Whenever you see

a[b] instead of

a[1:3,4]

you alread know that something fancy is going on... Nothing would change
here.

[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Greg K. <gp...@be...>]

> Are you opposed to anything going inside the [] operator to help indicate
> how the objects inside should be interpreted

I'm opposed to overloading any operator so that it becomes confusing.
Confusion is generated when a look at a small part of code
(a line or two) does not tell you what the code is doing.

This is a real problem for languages like Python and Perl, where
any variable can contain any data, IF the code behaves in
different ways, dependent on the data type.

"Different" is defined by the user, and it roughly translates
into the amount of coffee you have to drink to fix the code,
if the input data changes it's type.

> > Besides, you know some idiot is going to eventually write
> > code that looks like this:
> >
> > def access(a, b, x):
> >       return a[b, x]  # I think that a must be a 2-D array...
> >
> > # 1000 lines later...
> > access(a, _I) # Whoops all my assumptions were wrong...
> 
> I have no idea, what your concern is here.  This would result in an error
> currently and under the scheme I suggested.


Then, perhaps you should explain again.

I assumed you were proposing a magic second argument to [] that would
cause the first argument to be interpreted differently.

If so, I think that's a bad idea from a human-interface point of view,
because

(a) To a person who only uses Numpy occasionally, it is not obvious
that an argument is "magic".   That makes the code less readable.

(b) It is possible to write code where one can pass in the "magic" value
in a variable, and no simple inspection of the code will tell if it is
magic 
or not.

Using an explicit function or method call fixes (a) by telling the naive
user
that "this is not normal array access here."
It also fixes (b) by making it more obvious that fancy stuff is going
on.

RE: [Numpy-discussion] adding a .M attribute to the array.

[Paul F D. <pa...@pf...>]

Travis wrote:

To me, matrices are just arrays of rank <=2  which should be interpreted
with their specific algebra.


-- If a class is roughly data plus behaviors, a matrix is not simply an
array of rank <=2. You can express the concept of a matrix most cleanly
as a separate class.

Adding an argumentless member function .M to "convert" from one class to
the other, and not make the other class explicit, is a bit weird. But if
the other class "Matrix" is explicit, you needn't give it a privleged
status with respect to Numeric.array by having a member function in
Numeric.array that amounts to a Matrix constructor. The only real
motivation for that seems to me to be the feeling that M(x) is somehow
less clear than x.M. Note that except for a tricky property behavior,
you really ought to have to write the latter as x.M(). 

As I said, I think we can beef up Matrix to make the linear algebra
freaks happy, even to making things like transpose(A)*(B) as optimized
operations.

RE: [Numpy-discussion] adding a .M attribute to the array.

[Travis O. <oli...@ee...>]

> > Other suggestions?
>
> Here is one suggestion that is based on the observation that all we need
> is an easy way to tell that the following operation should be applied
> as a matrix operation. So, the suggestion is to provide an attribute or a
> member function that returns an array (note, not a Matrix instance) that
> has a bit, called it asmatrix, set true but _only_ temporally. The bit is
> cleaned on every operation. And before applying an operation, the
> corresponding method (currently there seem to be only four relevant
> methods: __mul__, __pow__ and their r-versions) checks if either of
> the operants has asmatrix bit true, then performs the corresponding matrix
> operation, otherwise the default element-wise operation. And before
> returning, it cleans up asmatrix bit.
>

Frankly, I like this kind of proposal.  I disagree with Konrad about the
separation between arrays and matrices.   From my discussions with other
people, it sounds like this is actually a point of disagreement for many
in the broader community.

To me, matrices are just arrays of rank <=2  which should be interpreted
with their specific algebra.


> For the sake of an example, let .m be Numeric array attribute that when
> accessed sets asmatrix=1 and returns the array.
> Examples:
>
>   a * b       - is element-wise multiplication
>   a.m * b, a * b.m   - are matrix multiplications, the resulting
>                        array, as well a and b, have asmatrix=0
>   a.m ** -1   - is matrix inverse
>   sin(a)      - element-wise sin
>   sin(a.m)    - matrix sin
>
> To summarize the main ideas:
>  * array has asmatrix bit that most of the time is false.
>  * there is a way to set the asmatrix bit true, either by .m or .M
>    attributes or .m(), .M(), .. methods that return the same array.
>  * __mul__, __pow__, etc. methods check if either operant has asmatrix
>    true, then performs the corresponding matrix operation, otherwise
>    the corresponding element-wise operation.
>  * all operations clean asmatrix bit.
>


Again, I wouldn't mind it, but I suspect the more aesthetically critical
on the list will dislike it because it blurs the (currently clumsy)
distinction between arrays and Matrices that I'm beginning to see people
actually like.

-Travis