Re: [Numpy-discussion] array vs matrix

2008-06-11 Thread Ondrej Certik
On Sun, Jun 8, 2008 at 3:54 AM, Anne Archibald
[EMAIL PROTECTED] wrote:
 2008/6/7 Robert Kern [EMAIL PROTECTED]:
 On Sat, Jun 7, 2008 at 14:37, Ondrej Certik [EMAIL PROTECTED] wrote:
 Hi,

 what is the current plan with array and matrix with regard of calculating

 sin(A)

 ? I.e. elementwise vs sin(A) = Q*sin(D)*Q^T? Is the current approach
 (elementwise for array and Q*sin(D)*Q^T for matrix) the way to go?

 I don't believe we intend to make numpy.matrix any more featureful. I
 don't think it's a good idea for you to base sympy.Matrix's
 capabilities in lock-step with numpy.matrix, though. There are very
 different constraints at work. Please, do what you think is best for
 sympy.Matrix.

 Let me elaborate somewhat:

 We recently ran across some painful quirks in numpy's handling of
 matrices, and they spawned massive discussion. As it stands now, there
 is significant interest in reimplementing the matrix object from
 scratch, with different behaviour. So emulating its current behaviour
 is not a win.

 For consistency, it makes a certain amount of sense to have sin(A)
 compute a matrix sine, since A**n computes a matrix power. But looking
 at the matrix exponential, I see that we have several implementations,
 none of which is satisfactory for all matrices. I would expect the
 matrix sine to be similar - particularly when faced with complex
 matrices - so perhaps needing an explicit matrix sine is a good thing?

 Also worth noting is that this problem can be evaded with namespaces;
 matrix sin could be scipy.matrixmath.sin, abbreviated perhaps to
 mm.sin, as opposed to np.sin.

I see. Thanks Robert and Anne for the replies. That's all I needed to know.

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


Re: [Numpy-discussion] array vs matrix

2008-06-07 Thread Robert Kern
On Sat, Jun 7, 2008 at 14:37, Ondrej Certik [EMAIL PROTECTED] wrote:
 Hi,

 what is the current plan with array and matrix with regard of calculating

 sin(A)

 ? I.e. elementwise vs sin(A) = Q*sin(D)*Q^T? Is the current approach
 (elementwise for array and Q*sin(D)*Q^T for matrix) the way to go?

I don't believe we intend to make numpy.matrix any more featureful. I
don't think it's a good idea for you to base sympy.Matrix's
capabilities in lock-step with numpy.matrix, though. There are very
different constraints at work. Please, do what you think is best for
sympy.Matrix.

-- 
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] array vs matrix

2008-06-07 Thread Anne Archibald
2008/6/7 Robert Kern [EMAIL PROTECTED]:
 On Sat, Jun 7, 2008 at 14:37, Ondrej Certik [EMAIL PROTECTED] wrote:
 Hi,

 what is the current plan with array and matrix with regard of calculating

 sin(A)

 ? I.e. elementwise vs sin(A) = Q*sin(D)*Q^T? Is the current approach
 (elementwise for array and Q*sin(D)*Q^T for matrix) the way to go?

 I don't believe we intend to make numpy.matrix any more featureful. I
 don't think it's a good idea for you to base sympy.Matrix's
 capabilities in lock-step with numpy.matrix, though. There are very
 different constraints at work. Please, do what you think is best for
 sympy.Matrix.

Let me elaborate somewhat:

We recently ran across some painful quirks in numpy's handling of
matrices, and they spawned massive discussion. As it stands now, there
is significant interest in reimplementing the matrix object from
scratch, with different behaviour. So emulating its current behaviour
is not a win.

For consistency, it makes a certain amount of sense to have sin(A)
compute a matrix sine, since A**n computes a matrix power. But looking
at the matrix exponential, I see that we have several implementations,
none of which is satisfactory for all matrices. I would expect the
matrix sine to be similar - particularly when faced with complex
matrices - so perhaps needing an explicit matrix sine is a good thing?

Also worth noting is that this problem can be evaded with namespaces;
matrix sin could be scipy.matrixmath.sin, abbreviated perhaps to
mm.sin, as opposed to np.sin.

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


Re: [Numpy-discussion] array vs matrix

2008-06-07 Thread Robert Kern
On Sat, Jun 7, 2008 at 20:54, Anne Archibald [EMAIL PROTECTED] wrote:

 For consistency, it makes a certain amount of sense to have sin(A)
 compute a matrix sine, since A**n computes a matrix power. But looking
 at the matrix exponential, I see that we have several implementations,
 none of which is satisfactory for all matrices. I would expect the
 matrix sine to be similar - particularly when faced with complex
 matrices - so perhaps needing an explicit matrix sine is a good thing?

I think so. We already have scipy.linalg.sinm(), cosm(), expm(), expm2(), etc.

-- 
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] array vs. matrix performance

2007-05-21 Thread Nils Wagner
Robert Cimrman wrote:
 I have come to a case where using a matrix would be easier than an
 array. The code uses lots of dot products, so I tested scipy.dot()
 performance with the code below and found that the array version is much
 faster (about 3 times for the given shape). What is the reason for this?
 Or is something wrong with my measurement?

 regards,
 r.

 ---
 import timeit
 setup = 
 import numpy as nm
 import scipy as sc
 X = nm.random.rand( 100, 3 )
 X = nm.asmatrix( X ) # (un)comment this line.
 print X.shape
 
 tt = timeit.Timer( 'sc.dot( X.T, X )', setup )
 print tt.timeit()
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion
   
Confirmed, but for what reason ?

0.5.3.dev3020
1.0.3.dev3792
Array version
6.84843301773
Matrix version
17.1273219585

Nils


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


Re: [Numpy-discussion] array vs. matrix performance

2007-05-21 Thread Charles R Harris

On 5/21/07, Charles R Harris [EMAIL PROTECTED] wrote:




On 5/21/07, David Cournapeau [EMAIL PROTECTED] wrote:

 Nils Wagner wrote:
  Robert Cimrman wrote:
  I have come to a case where using a matrix would be easier than an
  array. The code uses lots of dot products, so I tested scipy.dot()
  performance with the code below and found that the array version is
 much
  faster (about 3 times for the given shape). What is the reason for
 this?
  Or is something wrong with my measurement?
 
  regards,
  r.
 
  ---
  import timeit
  setup = 
  import numpy as nm
  import scipy as sc
  X = nm.random.rand( 100, 3 )
  X = nm.asmatrix( X ) # (un)comment this line.
  print X.shape
  
  tt = timeit.Timer( 'sc.dot( X.T, X )', setup )
  print tt.timeit()
  ___
  Numpy-discussion mailing list
  Numpy-discussion@scipy.org
  http://projects.scipy.org/mailman/listinfo/numpy-discussion
 
  Confirmed, but for what reason ?
 
  0.5.3.dev3020
  1.0.3.dev3792
  Array version
  6.84843301773
  Matrix version
  17.1273219585
 
 My guess would be that for such small matrices, the cost of matrix
 wrapping is not negligeable against the actual computation. This
 difference disappears for bigger matrices (for example, try 1000 and
 5000 instead of 100 for the first dimension).


Hmmm, I wonder how Tim's matrix version works. I've attached the code. I
am rather fond of the approach and have used it a few times myself. Tim uses
the dot product is written so: a(b). That is, the () operator is used
instead of the *.



Well, it doesn't go. There is a bug in the code and, on a second look, it
doesn't use dot.

BTW, on my machine numpy dot is faster than the scipy version.

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