Re: [Numpy-discussion] New Operators in Python

[dmitrey]

Hallo!

1)Isn't it possible to add .A & .M attributes to the array & matrix 
instances? I would find them very useful for some cases more convenient 
than asarray() or mat(). Let x.A just do nothing if x is array and x.M 
do nothing if x i matrix.

2)And if y=flat(x), what about y.R and y.C for to making y row-ndarray & 
column-ndarray (for to further convenient error-safe multiplication to 
2-dim arrays)? + maybe the same thing for ndarray & matrix instances?

3)What about new dotwise & matrix operators - after reading the 
discussion I would better wait for unicode instead of implementing 
2-symbol operators, for to make it once & forever.

WBR, D.

Bill Baxter wrote:
> On 3/26/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>   
>> What might work better is simply some sort of sign that causes a function to
>> be parsed as infix, x @dot y for instance, although Python already uses @
>> for other things. I don't know what symbols are left unused at this point,
>> maybe ! , $, and ~.
>> 
>
> I'm not really an expert on compilers, but from what I understand, the
> biggest problem with adding new operators is defining precedence.
> Without it, the interpreter won't know what to do with something like
> A @dot B @plus C.  Currently the interpreter only has to look at what
> the tokens are to build a parse tree out of something like A*B+C.  It
> doesn't matter what the types of A B and C are, that's always parsed
> as (A*B)+C.  If you add a @dot operator where do you define its
> precedence?  On the class that defines the operator?  What if two
> classes define the same operator with different precedences?  It gets
> to be a big ambiguous mess.
>
> So if you're going to add new operators they pretty much need to have
> globally predetermined precedence to allow the parser to remain sane.
> I think it's ML or Haskell that lets you define any operator you want
> out of the core operator tokens (eg "*+*") but IIRC the first char
> determines the precedence.  So *+* has the same precedence as "*".
> Requiring the new operator to include an existing operator char seems
> like a reasonable strategy since it gives a simple rule-based
> mechanism for determining precedence that is easy for both the parser
> and for users.
>
> --bb
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>   

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Alan G Isaac]

Oooops, they should match of course. ::
>>> X[1]
array([3,4])
>>> X[1,:]
matrix([[3, 4]])

But again the point is:
indexing for submatrices should produce matrices.
Normal Python indexing should access the constituent arrays.

Cheers,
Alan Isaac




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Alan G Isaac]

>> On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote: 
>>> finds itself in basic conflict with the idea that 
>>> I ought to be able to iterate over the objects in an 
>>> iterable container.  I mean really, does this not "feel" 
>>> wrong? ::
>>> for item in x: print item.__repr__()
>>> ...
>>> matrix([[1, 2]])
>>> matrix([[3, 4]]) 


On Mon, 26 Mar 2007, Bill Baxter apparently wrote: 
> So you're saying this is what you'd find more pythonic? 
 X[1] 
> matrix([2,3]) 
 X[:,1] 
> matrix([[3, 
> 4]]) 
> Just trying to make it clear what you're proposing. 


No; that is not possible, since a matrix is inherently 2d.
I just want to get the constituent arrays when I iterate
over the matrix object or use regular Python indexing, but 
a matrix when I use matrix/array indexing.  That is ::

>>> X[1] 
array([2,3]) 
>>> X[1,:] 
matrix([[3, 4]]) 

That behavior seems completely natural and unsurprising.


> Probably about half the bugs I get from mixing and matching matrix and 
> array are things like 
>row = A[i] 
>... 
>z = row[2]
> Which works for an array but not for a matrix. 


Exactly!
That is the evidence of a "bad surprise" in the current 
behavior.  Iterating over a Python iterable should provide 
access to the contained objects.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Bill Baxter]

On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> >> finds itself in basic conflict with the idea that I ought
> >> to be able to iterate over the objects in an iterable
> >> container.
>
> >> I mean really, does this not "feel" wrong? ::
>
> >> >>> for item in x: print item.__repr__()
> >> ...
> >> matrix([[1, 2]])
> >> matrix([[3, 4]])
>
>
> On Mon, 26 Mar 2007, Bill Baxter apparently wrote:
> > This may sound silly, but I really think seeing all those
> > brackets is what makes it feel wrong.
>
>
> I appreciate the agreement that it feels wrong, but
> I dispute the analysis of this symptom.  What makes it "feel
> wrong", I contend, is that experience with Python make this
> a **surprising** behavior.  And that is precisely why
> I suggest that this may point to a design issue.

So you're saying this is what you'd find more pythonic?

>>> X[1]
matrix([2,3])
>>> X[:,1]
matrix([[3,
4]])
Just trying to make it clear what you're proposing.

Probably about half the bugs I get from mixing and matching matrix and
array are things like
   row = A[i]
   ...
   z = row[2]
Which works for an array but not for a matrix.
I think Matlab makes it more bearable by having a single value index
like X[i] be equivalent to X.flat()[i].  So X[2] is the same for row
or col vec in Matlab.  Now that I think about it, that's probably the
main reason I feel more comfortable with array than matrix in Numpy.
If I have a vector, I should only need one index to get the ith
component.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Bill Baxter]

On 3/26/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> What might work better is simply some sort of sign that causes a function to
> be parsed as infix, x @dot y for instance, although Python already uses @
> for other things. I don't know what symbols are left unused at this point,
> maybe ! , $, and ~.

I'm not really an expert on compilers, but from what I understand, the
biggest problem with adding new operators is defining precedence.
Without it, the interpreter won't know what to do with something like
A @dot B @plus C.  Currently the interpreter only has to look at what
the tokens are to build a parse tree out of something like A*B+C.  It
doesn't matter what the types of A B and C are, that's always parsed
as (A*B)+C.  If you add a @dot operator where do you define its
precedence?  On the class that defines the operator?  What if two
classes define the same operator with different precedences?  It gets
to be a big ambiguous mess.

So if you're going to add new operators they pretty much need to have
globally predetermined precedence to allow the parser to remain sane.
I think it's ML or Haskell that lets you define any operator you want
out of the core operator tokens (eg "*+*") but IIRC the first char
determines the precedence.  So *+* has the same precedence as "*".
Requiring the new operator to include an existing operator char seems
like a reasonable strategy since it gives a simple rule-based
mechanism for determining precedence that is easy for both the parser
and for users.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Steven H. Rogers]

Bill Baxter wrote:
> 
> Until we get to the point that it's actually harder to find a
> non-Unicode console/editor than a Unicode one, I think the idea of
> using Unicode symbols as part of the syntax of a general purpose
> language is a bad one.

Given that most editors lack good Unicode support, it can be used as an 
alternate syntax, but not the only syntax.  For the foreseeable future, 
both syntaxes would have to be supported.  All that is needed is *one* 
reasonable editor with sufficient support for a Unicode Python syntax, 
and others will follow.  Since Idle is often used by Python beginners, 
it would be a good candidate.

> 
> I'm looking forward to see what becomes of Fortress, but it's
> basically still an experiment at this point.
> 
I think Fortress is more than an experiment, though it is still a long 
way from being useful for real work.

# Steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] subversion site down

[Jeff Strunk]

Thank you for letting me know. I restarted the server at 5:30pm central.

-Jeff

On Sunday 25 March 2007 1:42 pm, Christopher Hanley wrote:
> Hi,
>
> It appears that the subversion server is down for numpy.
>
> Chris
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Alan G Isaac]

> On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote: 
>> finds itself in basic conflict with the idea that I ought 
>> to be able to iterate over the objects in an iterable 
>> container. 

>> I mean really, does this not "feel" wrong? :: 

>> >>> for item in x: print item.__repr__() 
>> ... 
>> matrix([[1, 2]]) 
>> matrix([[3, 4]]) 


On Mon, 26 Mar 2007, Bill Baxter apparently wrote: 
> This may sound silly, but I really think seeing all those 
> brackets is what makes it feel wrong.


I appreciate the agreement that it feels wrong, but 
I dispute the analysis of this symptom.  What makes it "feel 
wrong", I contend, is that experience with Python make this 
a **surprising** behavior.  And that is precisely why 
I suggest that this may point to a design issue.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Alan G Isaac]

> Alan G Isaac wrote: 
>> So this :: 
>> >>> x[1] 
>> matrix([[1, 0]]) 
>> feels wrong.  (Similarly when iterating across rows.) 
>> Of course I realize that I can just :: 
>> >>> x.A[1] 
>> array([1, 0]) 


On Sun, 25 Mar 2007, "Colin J. Williams" apparently wrote: 
> An array and a matrix are different animals.  Conversion 
> from one to the other should be spelled out. 


But you are just begging the question here.
The question is: when I iterate across matrix rows,
why am I iterating across matrices and not arrays.
This seems quite out of whack with general Python practice.

You cannot just say "conversion should be explicit"
because that assumes (incorrectly actually) that
the rows are matrices.  The "conversion should be explicit"
argument actually cuts in the opposite direction of what
you appear to believe.

Cheers,
Alan Isaac




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Charles R Harris]

On 3/25/07, Bill Baxter <[EMAIL PROTECTED]> wrote:


On 3/26/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Joe Harrington wrote:
> >
> > On the other hand, Python, IDL, and Matlab are attractive to us mainly
> > because their syntaxes allow us to see the math, understand it on
> > inspection, and verify its correctness.  The math we write in these
> > languages looks as much like the math we do on paper as ASCII will
> > allow.  (Obviously, we also choose them because we don't like writing
> > loops and declaring variables.)
> >
> > So, whenever I hear someone suggest using a functional syntax for a
> > concept that exists notationally, I cringe.  We're alienating a class
> > of users each time we do that.  Those are people who will never come
> > to Python.  There are extremes to which this argument cannot go - a
> > prime will never be a derivative because quotes are more important -
> > but I think that matrix multiplication is a no-brainer here.  We
> > should let the Python developers know we want it now and then follow
> > up with a syntax and implementation.
> >
> >
>
> Sun's Fortress programming language
> (http://research.sun.com/projects/plrg/faq/index.html) will include
> Unicode operators and two dimensional equations.  Something like this
> should be possible for NumPy.  The question is how much can and should
> be pushed into the Python core language.

Until we get to the point that it's actually harder to find a
non-Unicode console/editor than a Unicode one, I think the idea of
using Unicode symbols as part of the syntax of a general purpose
language is a bad one.

I'm looking forward to see what becomes of Fortress, but it's
basically still an experiment at this point.



What might work better is simply some sort of sign that causes a function to
be parsed as infix, x @dot y for instance, although Python already uses @
for other things. I don't know what symbols are left unused at this point,
maybe ! , $, and ~.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] defmatrix.py

[Charles R Harris]

On 3/25/07, Nils Wagner <[EMAIL PROTECTED]> wrote:


Hi,





BTW, I can't import scipy.sparse, I get the following error:

ImportError: cannot import name densetocsr

What am I doing wrong?

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Bill Baxter]

On 3/26/07, Colin J. Williams <[EMAIL PROTECTED]> wrote:
> Bill Baxter wrote:
> > This may sound silly, but I really think seeing all those brackets is
> > what makes it feel wrong.   Matlab's  output doesn't put it in your
> > face that your 4 is really a matrix([[4]]), even though that's what it
> > is to Matlab.  But I don't see a good way to change that behavior.
> >
> > The other thing I find problematic about matrices is the inability to
> > go higher than 2d.  To me that means that it's impossible to go "pure
> > matrix" in my code because I'll have to switch back to arrays any time
> > I want more than 2d (or use a mixed solution like a list of matrices).
> >  Matlab allows allows >2D.
> >
> > --bb
> "pure matrix" seems to me an area of exploration, does it have any
> application in numerical computation at this time?

I'm not sure what you thought I meant, but all I meant by going "pure
matrix" was having my Numpy code use the 'matrix' type exclusively
instead of some mix of 'matrix' and the base 'ndarray' type.  Things
become messy when you mix and match them because you don't know any
more if an expression like A[1] is going to give you a 1-D thing or a
2-D thing, and you can't be sure what A * B will do without always
coercing A and B.

> A list of matrices seems to be a logical structure.

Yes, and it's the only option if you want to make a list of matrices
of different shapes, but I frequently have a need for things like a
list of per-point transformation matrices.  Each column from each of
those matrices can be thought of as a vector.  Sometimes its
convenient to consider all the X basis vectors together, for instance,
which is a simple and efficient M[:,:,0] slice if I have all the data
in a 3-D array, but it's a slow list comprehension plus matrix
constructor if I have the matrices in a list -- something like
matrix([m[:,0] for m in M])
but that line is probably incorrect.

> PyMatrix deals with
> lists in building a larger matrix from sub-matrices.
>
> Suppose that we have matrices A (3, 4), B (3, 6), C (4, 2) and D (4, 8).
>
> Then E= M([[A, B], [C, D]]) gives E (7, 10).

Numpy generally tries to treat all lists and tuples as array literals.
 That's not likely to change.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Bill Baxter]

On 3/26/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Joe Harrington wrote:
> >
> > On the other hand, Python, IDL, and Matlab are attractive to us mainly
> > because their syntaxes allow us to see the math, understand it on
> > inspection, and verify its correctness.  The math we write in these
> > languages looks as much like the math we do on paper as ASCII will
> > allow.  (Obviously, we also choose them because we don't like writing
> > loops and declaring variables.)
> >
> > So, whenever I hear someone suggest using a functional syntax for a
> > concept that exists notationally, I cringe.  We're alienating a class
> > of users each time we do that.  Those are people who will never come
> > to Python.  There are extremes to which this argument cannot go - a
> > prime will never be a derivative because quotes are more important -
> > but I think that matrix multiplication is a no-brainer here.  We
> > should let the Python developers know we want it now and then follow
> > up with a syntax and implementation.
> >
> >
>
> Sun's Fortress programming language
> (http://research.sun.com/projects/plrg/faq/index.html) will include
> Unicode operators and two dimensional equations.  Something like this
> should be possible for NumPy.  The question is how much can and should
> be pushed into the Python core language.

Until we get to the point that it's actually harder to find a
non-Unicode console/editor than a Unicode one, I think the idea of
using Unicode symbols as part of the syntax of a general purpose
language is a bad one.

I'm looking forward to see what becomes of Fortress, but it's
basically still an experiment at this point.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Colin J. Williams]

Bill Baxter wrote:
> On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>>> Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
 >>> x[1]
 matrix([[1, 0]])
 feels wrong.  (Similarly when iterating across rows.)
>>
>> On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
>>> I think the point here is that if you are using matrices,
>>> then all you "should" want are matrices, just like in
>>> MATLAB:
>>> >> b = A(1, :)
>>> b =
>>>  1 2
>>
>> Yes, that is the idea behind this, which I am also
>> accustomed to from GAUSS.  But note again that the Matlab
>> equivalent ::
>>
>> >>> x=N.mat('1 2;3 4')
>> >>> x[0,:]
>> matrix([[1, 2]])
>>
>> does provide this behavior.  The question I am raising
>> is a design question and is I think really not addressed
>> by the rule of thumb you offer.  Specifically, that rule
>> of thumb if it is indeed the justification of  ::
>>
>> >>> x[1]
>> matrix([[3, 4]])
>>
>> finds itself in basic conflict with the idea that I ought to
>> be able to iterate over the objects in an iterable container.
>>
>> I mean really, does this not "feel" wrong? ::
>>
>> >>> for item in x: print item.__repr__()
>> ...
>> matrix([[1, 2]])
>> matrix([[3, 4]])
> 
> This may sound silly, but I really think seeing all those brackets is
> what makes it feel wrong.   Matlab's  output doesn't put it in your
> face that your 4 is really a matrix([[4]]), even though that's what it
> is to Matlab.  But I don't see a good way to change that behavior.
> 
> The other thing I find problematic about matrices is the inability to
> go higher than 2d.  To me that means that it's impossible to go "pure
> matrix" in my code because I'll have to switch back to arrays any time
> I want more than 2d (or use a mixed solution like a list of matrices).
>  Matlab allows allows >2D.
> 
> --bb
"pure matrix" seems to me an area of exploration, does it have any 
application in numerical computation at this time?

A list of matrices seems to be a logical structure.  PyMatrix deals with 
lists in building a larger matrix from sub-matrices.

Suppose that we have matrices A (3, 4), B (3, 6), C (4, 2) and D (4, 8).

Then E= M([[A, B], [C, D]]) gives E (7, 10).

Colin W.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Colin J. Williams]

Alan G Isaac wrote:
>> Em Dom, 2007-03-25 Ã s 13:07 -0400, Alan G Isaac escreveu:
>>> >>> x[1]
>>> matrix([[1, 0]])
>>> feels wrong.  (Similarly when iterating across rows.)
> 
> 
> On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
>> I think the point here is that if you are using matrices, 
>> then all you "should" want are matrices, just like in 
>> MATLAB:
>> >> b = A(1, :)
>> b =
>>  1 2
> 
> 
> Yes, that is the idea behind this, which I am also 
> accustomed to from GAUSS.  But note again that the Matlab 
> equivalent ::
> 
> >>> x=N.mat('1 2;3 4')
> >>> x[0,:]
> matrix([[1, 2]])
> 
> does provide this behavior.  The question I am raising
> is a design question and is I think really not addressed
> by the rule of thumb you offer.  Specifically, that rule
> of thumb if it is indeed the justification of  ::
> 
> >>> x[1]
> matrix([[3, 4]])
> 
> finds itself in basic conflict with the idea that I ought to 
> be able to iterate over the objects in an iterable container.
> 
> I mean really, does this not "feel" wrong? ::
> 
> >>> for item in x: print item.__repr__()
> ...
> matrix([[1, 2]])
> matrix([[3, 4]])
> 
> Cheers,
> Alan Isaac
> 
> 
Perhaps this would be clearer with:

>>> for rowVector in x: print item.__repr__()
 ...
 matrix([[1, 2]])
 matrix([[3, 4]])

Colin W.


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Steven H. Rogers]

Joe Harrington wrote:
> 
> On the other hand, Python, IDL, and Matlab are attractive to us mainly
> because their syntaxes allow us to see the math, understand it on
> inspection, and verify its correctness.  The math we write in these
> languages looks as much like the math we do on paper as ASCII will
> allow.  (Obviously, we also choose them because we don't like writing
> loops and declaring variables.)
> 
> So, whenever I hear someone suggest using a functional syntax for a
> concept that exists notationally, I cringe.  We're alienating a class
> of users each time we do that.  Those are people who will never come
> to Python.  There are extremes to which this argument cannot go - a
> prime will never be a derivative because quotes are more important -
> but I think that matrix multiplication is a no-brainer here.  We
> should let the Python developers know we want it now and then follow
> up with a syntax and implementation.
> 
> 

Sun's Fortress programming language 
(http://research.sun.com/projects/plrg/faq/index.html) will include 
Unicode operators and two dimensional equations.  Something like this 
should be possible for NumPy.  The question is how much can and should 
be pushed into the Python core language.

# Steve
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Colin J. Williams]

Alan G Isaac wrote:
> One thing keeps bugging me when I use numpy.matrix.
> 
> All this is fine::
> 
> >>> x=N.mat('1 1;1 0')
> >>> x
> matrix([[1, 1],
> [1, 0]])
> >>> x[1,:]
> matrix([[1, 0]])
> 
> But it seems to me that I should be able
> to extract a matrix row as an array.

This can easily be done:
*** Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit 
(Intel)] on win32. ***
 >>> import numpy as _n
 >>> A= _n.mat([[1, 2], [3, 4]])
 >>> A[1]
matrix([[3, 4]])
 >>> A[1].getA1()
array([3, 4])

An array and a matrix are different animals.  Conversion from one to the 
other should be spelled out.

As you have done below.

Colin W.

> So this ::
> 
> >>> x[1]
> matrix([[1, 0]])
> 
> feels wrong.  (Similarly when iterating across rows.)
> Of course I realize that I can just ::
> 
> >>> x.A[1]
> array([1, 0])
> 
> but since the above keeps feeling wrong I felt I should 
> raise this as a possible design issue, better discussed
> early than latter.
> 
> Cheers,
> Alan Isaac

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] header file location upon installation

[Robert Kern]

Daniel Wheeler wrote:
> Hi,
> 
> Should the header files in 
> 
> .../lib/python2.4/site-packages/python/numpy/core/include/
> 
> be copied to
> 
>.../include/python2.4/numpy/
> 
> upon installation of numpy?

No. For reasons that we've discussed several times here, the only reliable place
to keep headers is in the package itself. Some users don't have write access to
sys.prefix and some users use eggs and/or have multiple versions of numpy
installed at any one time.

For building extensions, either use numpy.distutils, which will take care of
everything for you, or use numpy.get_include() to get the directory with 
headers.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Bill Baxter]

On 3/26/07, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
> >> >>> x[1]
> >> matrix([[1, 0]])
> >> feels wrong.  (Similarly when iterating across rows.)
>
>
> On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
> > I think the point here is that if you are using matrices,
> > then all you "should" want are matrices, just like in
> > MATLAB:
> > >> b = A(1, :)
> > b =
> >  1 2
>
>
> Yes, that is the idea behind this, which I am also
> accustomed to from GAUSS.  But note again that the Matlab
> equivalent ::
>
> >>> x=N.mat('1 2;3 4')
> >>> x[0,:]
> matrix([[1, 2]])
>
> does provide this behavior.  The question I am raising
> is a design question and is I think really not addressed
> by the rule of thumb you offer.  Specifically, that rule
> of thumb if it is indeed the justification of  ::
>
> >>> x[1]
> matrix([[3, 4]])
>
> finds itself in basic conflict with the idea that I ought to
> be able to iterate over the objects in an iterable container.
>
> I mean really, does this not "feel" wrong? ::
>
> >>> for item in x: print item.__repr__()
> ...
> matrix([[1, 2]])
> matrix([[3, 4]])

This may sound silly, but I really think seeing all those brackets is
what makes it feel wrong.   Matlab's  output doesn't put it in your
face that your 4 is really a matrix([[4]]), even though that's what it
is to Matlab.  But I don't see a good way to change that behavior.

The other thing I find problematic about matrices is the inability to
go higher than 2d.  To me that means that it's impossible to go "pure
matrix" in my code because I'll have to switch back to arrays any time
I want more than 2d (or use a mixed solution like a list of matrices).
 Matlab allows allows >2D.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Simple multi-arg wrapper for dot()

[Bill Baxter]

On 3/25/07, Colin J. Williams <[EMAIL PROTECTED]> wrote:
> Bill Baxter wrote:
> > On 3/25/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> >> Bill Baxter wrote:
> >
> >> I don't know. Given our previous history with convenience functions with
> >> different calling semantics (anyone remember rand()?), I think it probably 
> >> will
> >> confuse some people.
> >>
> >> I'd really like to see it on a cookbook page, though. I'd use it.
> >
> > Done.
> > http://www.scipy.org/Cookbook/MultiDot
> >
> > --bb
> I wasn't able to connect to this link

Scipy.org seems to be down now.

> but I gather that the proposal was
> to used dot(A, B, C) to represent the product of the 3 arrays.

More or less, but the idea of modifying dot itself was quickly dropped.


> if A, B and C were matrices then this could more clearly be written as
> A * B * C

Yep, if they were, that would work great.
But If you're not sure if they are matrices or not you need to either
use dot to make sure you get the matrix multiply behavior, or convert
to matrices.  Actually I think converting just the first one to a
matrix suffices, so you could write it

   mat(A) * B * C

But that won't preserve the array type of the inputs.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] defmatrix.py

[Charles R Harris]

On 3/25/07, Nils Wagner <[EMAIL PROTECTED]> wrote:


Hi,

Several tests didn't pass due to the recent changes
in defmatrix.py.

Nils

==
ERROR: check_matmat
(scipy.sparse.tests.test_sparse.test_csc)
--
Traceback (most recent call last):
   File

"/usr/local/lib64/python2.5/site-packages/scipy/sparse/tests/test_sparse.py",
line 142, in check_matmat
 assert_array_almost_equal((a*bsp).todense(), a*b)
   File
"/usr/local/lib64/python2.5/site-packages/numpy/core/defmatrix.py",
line 162, in __mul__
 return N.dot(self, other)
ValueError: objects are not aligned

==
ERROR: check_rmatvec
(scipy.sparse.tests.test_sparse.test_csc)
--
Traceback (most recent call last):
   File

"/usr/local/lib64/python2.5/site-packages/scipy/sparse/tests/test_sparse.py",
line 107, in check_rmatvec
 assert_array_almost_equal(row*M, row*M.todense())
   File
"/usr/local/lib64/python2.5/site-packages/numpy/core/defmatrix.py",
line 162, in __mul__
 return N.dot(self, other)
ValueError: objects are not aligned

==
ERROR: check_matmat
(scipy.sparse.tests.test_sparse.test_csr)
--
Traceback (most recent call last):
   File

"/usr/local/lib64/python2.5/site-packages/scipy/sparse/tests/test_sparse.py",
line 142, in check_matmat
 assert_array_almost_equal((a*bsp).todense(), a*b)
   File
"/usr/local/lib64/python2.5/site-packages/numpy/core/defmatrix.py",
line 162, in __mul__
 return N.dot(self, other)
ValueError: objects are not aligned

==
ERROR: check_rmatvec
(scipy.sparse.tests.test_sparse.test_csr)

...



Looks to me like the __rmul__  operator for sparse matrices needs to be
called in these cases which have in common the form

matrix * sparse

Right now conversion to asmatrix is called on the rhs. Hmmm, I didn't want
to forgo constructs like

matrix * [[1],[2]]

I wonder what  asmatrix(sparse) is doing as it doesn't seem to raise an
error. Also, how does one call spmatrix, it doesn't seem to be a standalone
function, nor do I see how it gets into the test class as the test class
doesn't subclass anything?

SVN seems to be down, so there is nothing I can do at the moment.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] dtype confusion

[Jan Strube]

Thanks Stefan and Travis for their explanations.
First a request: Could both explanations be added to the manual, please?
Thanks.

So the problem I was having was that I thought this difference in behavior
would be caused by two different types: recarray and ndarray.
I feel that there is still some underlying behavior that I don't understand,
but for now the puzzling thing was that I thought that the new dtype simply
assigns names and aliases varname[:,0] to varname['x'], varname[:,1] to
varname['y'], and so on. I didn't expect it to fundamentally change the
array in that way, I would have expected varname.view(recarray) to do that.

Would it make sense for me then to create something like a "namedarray"
subclass of ndarray that doesn't change the dtype but simply let's you
provide names and assign them to the columns? Maybe in my case it's easier,
because all columns of the record array have the same type

I guess I'll re-read the dtypes and recarray parts of the manual now...

Thanks,
   Jan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Joe Harrington]

I strongly agree with the need for different infix operators for
matrix and array multiplication.  In IDL, I have used both in the same
code.  IDL uses * for array and # for matrix (hey, # even *looks* like
a matrix, very intuitive).  It uses ## for right-multiply (why people
don't just M-t the variable names I don't know, though maybe people
who do more linear algebra than I can say).

There's an important justification that hasn't come up yet, and that
is advocacy.  Languages are good or not good depending on how readable
and writeable they are for various purposes.  LISP is a technically
very powerful language.  It was object-oriented a zillion years before
C++.  It had and has powerful proponents within CS, such as Stallman.

But, whenever CS people try to push LISP outside their ivory tower, it
gets trashed.  The LISP dialect Guile was written as the GNU project's
extension language and nobody used it.  Now projects like GIMP have
two extension languages, Guile and Python.  Why?  LISP is great for
analyzing the flow and structure of computer code, but LISP math does
not look like real math, which makes it very difficult and
counterintuitive to use for math or math-heavy topics like graphics.
It has little syntactic sugar to make common math tasks either quick
to write or easy to understand or verify, until you've retrained your
brain.  So, even though there are tons of technical people exposed to
LISP, nobody outside CS adopts it who doesn't have to.

On the other hand, Python, IDL, and Matlab are attractive to us mainly
because their syntaxes allow us to see the math, understand it on
inspection, and verify its correctness.  The math we write in these
languages looks as much like the math we do on paper as ASCII will
allow.  (Obviously, we also choose them because we don't like writing
loops and declaring variables.)

So, whenever I hear someone suggest using a functional syntax for a
concept that exists notationally, I cringe.  We're alienating a class
of users each time we do that.  Those are people who will never come
to Python.  There are extremes to which this argument cannot go - a
prime will never be a derivative because quotes are more important -
but I think that matrix multiplication is a no-brainer here.  We
should let the Python developers know we want it now and then follow
up with a syntax and implementation.

--jh--
Prof. Joseph Harrington
Department of Physics
MAP 420
University of Central Florida
Orlando, FL 32816-2385
(407) 823-3416 voice
(407) 823-5112 fax
(407) 823-2325 physics office
[EMAIL PROTECTED]   (direct)
[EMAIL PROTECTED]   (permanent forwarding address, will work 
forever)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] subversion site down

[Christopher Hanley]

Hi,

It appears that the subversion server is down for numpy.

Chris

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Alan G Isaac]

> Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:
>> >>> x[1]
>> matrix([[1, 0]])
>> feels wrong.  (Similarly when iterating across rows.)


On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote:
> I think the point here is that if you are using matrices, 
> then all you "should" want are matrices, just like in 
> MATLAB:
> >> b = A(1, :)
> b =
>  1 2


Yes, that is the idea behind this, which I am also 
accustomed to from GAUSS.  But note again that the Matlab 
equivalent ::

>>> x=N.mat('1 2;3 4')
>>> x[0,:]
matrix([[1, 2]])

does provide this behavior.  The question I am raising
is a design question and is I think really not addressed
by the rule of thumb you offer.  Specifically, that rule
of thumb if it is indeed the justification of  ::

>>> x[1]
matrix([[3, 4]])

finds itself in basic conflict with the idea that I ought to 
be able to iterate over the objects in an iterable container.

I mean really, does this not "feel" wrong? ::

>>> for item in x: print item.__repr__()
...
matrix([[1, 2]])
matrix([[3, 4]])

Cheers,
Alan Isaac





___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] matrix indexing question

[Paulo Jose da Silva e Silva]

Em Dom, 2007-03-25 às 13:07 -0400, Alan G Isaac escreveu:

> So this ::
> 
> >>> x[1]
> matrix([[1, 0]])
> 
> feels wrong.  (Similarly when iterating across rows.)
> Of course I realize that I can just ::
> 
> >>> x.A[1]
> array([1, 0])
> 
> but since the above keeps feeling wrong I felt I should 
> raise this as a possible design issue, better discussed
> early than latter.

I think the point here is that if you are using matrices, then all you
"should" want are matrices, just like in MATLAB:


>> A = [1 2; 3 4]

A =

 1 2
 3 4

>> b = A(1, :)

b =

 1 2

>> size(b)

ans =

 1 2

>> b = A(:, 1)

b =

 1
 3

>> size(b)

ans =

 2 1

>> b = 1

b =

 1

>> size(b)

ans =

 1 1


You see, rows, columnes, and even numbers, are treated as matrices.

Paulo
 

-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: [EMAIL PROTECTED]   Web: http://www.ime.usp.br/~rsilva

Teoria é o que não entendemos o (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call practice)

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] header file location upon installation

[Daniel Wheeler]

Hi,

Should the header files in

.../lib/python2.4/site-packages/python/numpy/core/include/

be copied to

   .../include/python2.4/numpy/

upon installation of numpy? As far as I can tell this is not happening.
Just wondering what the default behavior should be.

Thanks

--
Daniel Wheeler


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] matrix indexing question

[Alan G Isaac]

One thing keeps bugging me when I use numpy.matrix.

All this is fine::

>>> x=N.mat('1 1;1 0')
>>> x
matrix([[1, 1],
[1, 0]])
>>> x[1,:]
matrix([[1, 0]])

But it seems to me that I should be able
to extract a matrix row as an array.
So this ::

>>> x[1]
matrix([[1, 0]])

feels wrong.  (Similarly when iterating across rows.)
Of course I realize that I can just ::

>>> x.A[1]
array([1, 0])

but since the above keeps feeling wrong I felt I should 
raise this as a possible design issue, better discussed
early than latter.

Cheers,
Alan Isaac


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] array multiplication with different dtypes

[Travis Oliphant]

Jan Strube wrote:
> I'm having a difficult time understanding the following behavior:
>
> import numpy as N
> # create a new array 4 rows, 3 columns
> x = N.random.random((4, 3))
> # elementwise multiplication
> x*x
>
> newtype = N.dtype([('x', N.float64), ('y', N.float64), ('z', N.float64)])
>
> # interpret the array as an array of cartesian coordinates
> x.dtype = newtype
>
> x*x
>
> --> TypeError: unsupported operand type(s) for *: ' numpy.ndarray' and 
> 'numpy.ndarray'
>
> N.__version__
> '1.0.2.dev3498'
>
> So just by assigning names to the columns, I can't multiply the arrays 
> any more?

No, it's not a bug.  It's a "missing feature"."  You have created a 
"record-array".  All of the ufuncs are undefined for arrays with fields 
(what is sometimes called a variable item-size array).  They are 
undefined for two reasons

1) It's not clear how to define them.  It is ambiguous in general.  For 
this specific case, it is probably clear what you want, but what do you 
want for the general case data-type with fields defined.This has 
never been thought out clearly.  

2) It's not trivial to implement.  Basically, handling the general case 
would require some alterations to the main ufunc code loops in order to 
pass information about the size of the array element that is presently 
not available.

Perhaps some day we will be able to add element-by-element ufuncs for 
record arrays that will basically recurse through the fields, but that 
will require some coding effort that is not on my radar for the next while.

What you can do, is maintain a view of the data as a 4x3 array of floats 
and do the multiplication with that array.  The same memory can then 
also be viewed as a length 4 1-d array of coordinates if you like. 

You can also be more explicit about what you want to do with each column 
by writing

y = x.copy()
y['x'] = x['x']*x['x']
y['y'] = x['y']*x['y']
y['z'] = x['z']*x['z']

>
> Please tell me this is a bug ;-)
Sorry,  it's not that easy.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Alan G Isaac]

On Sun, 25 Mar 2007, Paulo Jose da Silva e Silva apparently wrote: 
> Even though I can get used with using dot (or 
> matrixmultiply) to do it, I can easily see the benefit of 
> having a special operator here. 

Some newer languages are taking advantage of the 
expressiveness of Unicode for math purposes.  I believe 
somone on this list asked whether this might provide a way 
forward.  Can it (taking a long view)?  For example, it 
would be natural to use as operators the Unicode 
multiplication sign U+00D7 (×) and the Unicode dot operator 
U+22C5 (·).  

Cheers,
Alan Isaac 



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Paulo Jose da Silva e Silva]

Em Seg, 2007-03-26 às 01:08 +1000, dpn escreveu:
> With the possible inclusion of generic functions in py3k I dont really
> see the point of adding more operators. (While i do miss mat1 x mat2
> from PDL).
> 
> mat3 = mat1.mm(mat2) or the like seems to be sufficient.
> 
> I find matrix multiplication annoying in the case of SVD reconstruction:
> 
> final = matrixmultiply(matrixmultiply(u, s), v)
> 

Matrix multiplication is just too common in numerical linear algebra,
one of the main areas for numpy/scipy. Even though I can get used with
using dot (or matrixmultiply) to do it, I can easily see the benefit of
having a special operator here. This will be beneficial for
mathematicians that use numpy/scipy to prototype some ideas or to
newcomers from Matlab.

Paulo
-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: [EMAIL PROTECTED]   Web: http://www.ime.usp.br/~rsilva

Teoria é o que não entendemos o (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call practice)

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[dpn]

With the possible inclusion of generic functions in py3k I dont really
see the point of adding more operators. (While i do miss mat1 x mat2
from PDL).

mat3 = mat1.mm(mat2) or the like seems to be sufficient.

I find matrix multiplication annoying in the case of SVD reconstruction:

final = matrixmultiply(matrixmultiply(u, s), v)

A minor gripe though. I'm more inclined to err on the side of clean
python rather than more operators, especially since aforementioned
GF's will help with many cases

dpn

On 3/26/07, Colin J. Williams <[EMAIL PROTECTED]> wrote:
> Charles R Harris wrote:
> >
> >
> > On 3/24/07, *Travis Oliphant* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Every so often the idea of new operators comes up because of the need to
> > do both "matrix-multiplication" and element-by-element multiplication.
> >
> > I think this is one area where the current Python approach is not as
> > nice because we have a limited set of operators to work with.
> >
> > One thing I wonder is if we are being vocal enough with the Python 3000
> > crowd to try and get additional operators into the language itself.
> >
> > What if we could get a few new operators into the language to help us.
> > If we don't ask for it, it certainly won't happen.
> > My experience is that the difficulty of using the '*' operator for both
> > matrix multiplication and element-by-element multiplication
> > depending on
> > the class of the object is not especially robust.  It makes it harder to
> > write generic code, and we still haven't gotten everything completely
> > right.
> >
> > It is somewhat workable as it stands, but I think it would be nicer if
> > we could have some "meta" operator that allowed an alternative
> > definition of major operators.   Something like @*  for example (just
> > picking a character that is already used for decorators).
> >
> >
> > Yes indeed, this is an old complaint. Just having an infix operator
> > would be an improvement:
> >
> > A dot B dot C
> >
> > Not that I am suggesting dot in this regard ;) In particular, it
> > wouldn't parse without spaces. What about division? Matlab has both /
> > and \ for left and right matrix division and something like that could
> > call solve instead of inverse, leading to some efficiencies.
>
> Yes, thanks to a suggestion from Alan Isaac, this was implemented in
> PyMatrix (based on numarray and not yet converted to numpy). / served
> for one and // for the other.
>
> Regarding an additional multiply operator, I don't see the need for it.
>A matrix and and array are similar dut different animals.
>
> Colin W.
>
> We also
> > have both dot and tensordot, which raises the problem of interpretation
> > when ndim > 2.
> >
> > Chuck
> >
> >
> >
> > 
> >
> > ___
> > Numpy-discussion mailing list
> > Numpy-discussion@scipy.org
> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New Operators in Python

[Colin J. Williams]

Charles R Harris wrote:
> 
> 
> On 3/24/07, *Travis Oliphant* <[EMAIL PROTECTED] 
> > wrote:
> 
> Every so often the idea of new operators comes up because of the need to
> do both "matrix-multiplication" and element-by-element multiplication.
> 
> I think this is one area where the current Python approach is not as
> nice because we have a limited set of operators to work with.
> 
> One thing I wonder is if we are being vocal enough with the Python 3000
> crowd to try and get additional operators into the language itself.
> 
> What if we could get a few new operators into the language to help us.
> If we don't ask for it, it certainly won't happen.
> My experience is that the difficulty of using the '*' operator for both
> matrix multiplication and element-by-element multiplication
> depending on
> the class of the object is not especially robust.  It makes it harder to
> write generic code, and we still haven't gotten everything completely
> right.
> 
> It is somewhat workable as it stands, but I think it would be nicer if
> we could have some "meta" operator that allowed an alternative
> definition of major operators.   Something like @*  for example (just
> picking a character that is already used for decorators).
> 
> 
> Yes indeed, this is an old complaint. Just having an infix operator 
> would be an improvement:
> 
> A dot B dot C
> 
> Not that I am suggesting dot in this regard ;) In particular, it 
> wouldn't parse without spaces. What about division? Matlab has both / 
> and \ for left and right matrix division and something like that could 
> call solve instead of inverse, leading to some efficiencies. 

Yes, thanks to a suggestion from Alan Isaac, this was implemented in 
PyMatrix (based on numarray and not yet converted to numpy). / served 
for one and // for the other.

Regarding an additional multiply operator, I don't see the need for it. 
   A matrix and and array are similar dut different animals.

Colin W.

We also
> have both dot and tensordot, which raises the problem of interpretation 
> when ndim > 2.
> 
> Chuck
> 
> 
> 
> 
> 
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Simple multi-arg wrapper for dot()

[Colin J. Williams]

Bill Baxter wrote:
> On 3/25/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Bill Baxter wrote:
> 
>> I don't know. Given our previous history with convenience functions with
>> different calling semantics (anyone remember rand()?), I think it probably 
>> will
>> confuse some people.
>>
>> I'd really like to see it on a cookbook page, though. I'd use it.
> 
> Done.
> http://www.scipy.org/Cookbook/MultiDot
> 
> --bb
I wasn't able to connect to this link but I gather that the proposal was 
to used dot(A, B, C) to represent the product of the 3 arrays.

if A, B and C were matrices then this could more clearly be written as
A * B * C

Colin W.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Detect subclass of ndarray

[Colin J. Williams]

Colin J. Williams wrote:
> Alan G Isaac wrote:
>> On Sat, 24 Mar 2007, Charles R Harris apparently wrote: 
>>> Yes, that is what I am thinking. Given that there are only the two 
>>> possibilities, row or column, choose the only one that is compatible with 
>>> the multiplying matrix. The result will not always be a column vector, for 
>>> instance, mat([[1]])*ones(3) will be a 1x3 row vector. 
>>
>>
>> Ack!  The simple rule `post multiply means its a column vector`
>> would be horrible enough: A*ones(n)*B becomes utterly obscure.
>> Now even that simple rule is to be violated??
> 
> It depends whether ones delivers an instance of the Matrix/vector class 
> or a simple array.
> 
> I assume that, in the above A and B represent matrices.
> 
> Colin W.

Postscript:  I hadn't read the later postings when I posted the above.

PyMatrix used the convention mentioned in an earlier posting.  Simply a 
vector is considered as a single row matrix or a single column matrix.

This same approach can largely be used with numpy's mat:

*** Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit 
(Intel)] on win32. ***
 >>> import numpy as _n
 >>> _n.ones(3)
array([ 1.,  1.,  1.])
 >>> a= _n.ones(3)
 >>> a.T
array([ 1.,  1.,  1.])
 >>> _n.mat(a)
matrix([[ 1.,  1.,  1.]])
 >>> _n.mat(a).T
matrix([[ 1.],
 [ 1.],
 [ 1.]])
 >>> b= _n.mat(a).T
 >>> a * b
matrix([[ 3.]])   #  Something has gone wrong here - it 
looks as though there is normalization under the counter.
 >>>

In any event, the problem posed by Alan Isaac can be handled with this 
approach:

A * mat(ones(3)).t * B can produce the desired result.  I haven't tested it.

Colin W.
>> Down this path lies madness.
>> Please, just raise an exception.
>>
>> Cheers,
>> Alan Isaac

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Detect subclass of ndarray

[Colin J. Williams]

Alan G Isaac wrote:
> On Sat, 24 Mar 2007, Charles R Harris apparently wrote: 
>> Yes, that is what I am thinking. Given that there are only the two 
>> possibilities, row or column, choose the only one that is compatible with 
>> the multiplying matrix. The result will not always be a column vector, for 
>> instance, mat([[1]])*ones(3) will be a 1x3 row vector. 
> 
> 
> 
> Ack!  The simple rule `post multiply means its a column vector`
> would be horrible enough: A*ones(n)*B becomes utterly obscure.
> Now even that simple rule is to be violated??

It depends whether ones delivers an instance of the Matrix/vector class 
or a simple array.

I assume that, in the above A and B represent matrices.

Colin W.
> 
> Down this path lies madness.
> Please, just raise an exception.
> 
> Cheers,
> Alan Isaac

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] dtype confusion

[Stefan van der Walt]

On Sun, Mar 25, 2007 at 04:09:11AM -0700, Jan Strube wrote:
> There seems to be a fundamental lack of understanding on my behalf when it
> comes to dtypes and record arrays.
> Please consider the following snippet:
> 
> import numpy as N
> newtype = N.dtype([('x', N.float64 ), ('y', N.float64), ('z', N.float64)])
> a = N.random.random((100,3))
> a.dtype=newtype
> b = N.column_stack([a['x'].ravel(), a['y'].ravel(), a['z'].ravel()])
> b.dtype = newtype
> --> ValueError: new type not compatible with array.
> 
> I don't understand two things about this:
> i) the shape of a changes from (100,3) to (100,1) after assigning
> the dtype.

Every group of three floats now become one element in the new array,
i.e.

float64 -> (float64,float64,float64)

> ii) the shape of b is obviously (100,3), so why can't I assign the
> new dtype?

The array is no longer a contiguous block of memory, so the new dtype
can't be applied:

In [23]: b.flags
Out[23]: 
  C_CONTIGUOUS : False
  F_CONTIGUOUS : True
  OWNDATA : False
  WRITEABLE : True
  ALIGNED : True
  UPDATEIFCOPY : False

The following does a copy of the array to contiguous memory:

In [24]: N.ascontiguousarray(b).dtype = newtype

If you want to move back to the original view you can do

b.view(N.float64)

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] dtype confusion

[Jan Strube]

There seems to be a fundamental lack of understanding on my behalf when it
comes to dtypes and record arrays.
Please consider the following snippet:

import numpy as N
newtype = N.dtype([('x', N.float64), ('y', N.float64), ('z', N.float64)])
a = N.random.random((100,3))
a.dtype=newtype
b = N.column_stack([a['x'].ravel(), a['y'].ravel(), a['z'].ravel()])
b.dtype = newtype
--> ValueError: new type not compatible with array.

I don't understand two things about this:
i) the shape of a changes from (100,3) to (100,1) after assigning the dtype.
ii) the shape of b is obviously (100,3), so why can't I assign the new
dtype?

Could someone please point out the flaws in this approach?
Thanks much,
   Jan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] array multiplication with different dtypes

[Jan Strube]

I'm having a difficult time understanding the following behavior:

import numpy as N
# create a new array 4 rows, 3 columns
x = N.random.random((4, 3))
# elementwise multiplication
x*x

newtype = N.dtype([('x', N.float64), ('y', N.float64), ('z', N.float64)])

# interpret the array as an array of cartesian coordinates
x.dtype = newtype

x*x

--> TypeError: unsupported operand type(s) for *: 'numpy.ndarray' and '
numpy.ndarray'

N.__version__
'1.0.2.dev3498'

So just by assigning names to the columns, I can't multiply the arrays any
more?
Numpy itself still claims that x is an ndarray.
I hope this is a bug, because it would be really convenient if this still
worked after assigning names to columns.
What I really wanted to do was N.dot(x, x.T) to get the length of the
cartesian vectors, but (I think) this fails for the same reason.

Please tell me this is a bug ;-)

Cheers,
   Jan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion