matrix problem: float to matrix power
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices? Same question for matrices conformable for broadcasting: why not produce the equivalent of the array result? Cheers, Alan Isaac
On 10/31/07, Alan G Isaac <aisaac@american.edu> wrote:
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices?
Looks like it just got overlooked. It works fine for 2D arrays. In [11]: 1.0**eye(3) Out[11]: array([[ 1., 1., 1.], [ 1., 1., 1.], [ 1., 1., 1.]]) Chuck
On Oct 30, 2007 11:40 PM, Alan G Isaac <aisaac@american.edu> wrote:
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices?
Same question for matrices conformable for broadcasting: why not produce the equivalent of the array result?
With the caveat that I don't use the matrix class: I believe it's because M**n results in the matrix power of n. It would be confusing if n**M did a broadcast element wise power. -- . __ . |-\ . . tim.hochberg@ieee.org
Charles R Harris wrote:
On 10/31/07, Alan G Isaac <aisaac@american.edu> wrote:
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices?
Looks like it just got overlooked. It works fine for 2D arrays.
In [11]: 1.0**eye(3) Out[11]: array([[ 1., 1., 1.], [ 1., 1., 1.], [ 1., 1., 1.]])
For ndarrays, it does elementwise exponentiation, so it is neither here nor there with respect to matrices. What is the definition of a scalar raised to a matrix power? I don't ever recall seeing one. -- 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
On 10/31/07, Robert Kern <robert.kern@gmail.com> wrote:
Charles R Harris wrote:
On 10/31/07, Alan G Isaac <aisaac@american.edu> wrote:
1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices?
Looks like it just got overlooked. It works fine for 2D arrays.
In [11]: 1.0**eye(3) Out[11]: array([[ 1., 1., 1.], [ 1., 1., 1.], [ 1., 1., 1.]])
For ndarrays, it does elementwise exponentiation, so it is neither here nor there with respect to matrices. What is the definition of a scalar raised to a matrix power? I don't ever recall seeing one.
I suppose the usual: a**m = exp(ln(a)*m) but that isn't the broadcast version. Chuck
Charles R Harris wrote:
On 10/31/07, Robert Kern <robert.kern@gmail.com> wrote:
On 10/31/07, Alan G Isaac <aisaac@american.edu> wrote:
> 1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) > 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix'
Why the restriction for matrices? Looks like it just got overlooked. It works fine for 2D arrays.
In [11]: 1.0**eye(3) Out[11]: array([[ 1., 1., 1.], [ 1., 1., 1.], [ 1., 1., 1.]]) For ndarrays, it does elementwise exponentiation, so it is neither here nor
Charles R Harris wrote: there with respect to matrices. What is the definition of a scalar raised to a matrix power? I don't ever recall seeing one.
I suppose the usual:
a**m = exp(ln(a)*m)
but that isn't the broadcast version.
Ah, yes. Of course. How silly of me. That raises the question of how to calculate the bloody thing, though. We have three implementations of expm() in scipy.linalg.matfuncs. -- 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
On Wed, 31 Oct 2007, Timothy Hochberg apparently wrote:
because M**n results in the matrix power of n. It would be confusing if n**M did a broadcast element wise power.
In an attempt to summarize: scalar to a matrix power 1. may have been overlooked, or may have been omitted as confusing 2. if overlooked there are two possible answers as to what it could reasonably be a. a**m = exp(ln(a)*m) natural definition b. a**m = a**m.A broadcasting In languages that provide an answer, I have the impression that the answer is usually (b). (E.g., GAUSS.) However perhaps in NumPy this is the least interesting way to go? But it is what I was expecting. Cheers, Alan Isaac
On Nov 1, 2007 12:20 PM, Alan G Isaac <aisaac@american.edu> wrote:
On Wed, 31 Oct 2007, Timothy Hochberg apparently wrote:
because M**n results in the matrix power of n. It would be confusing if n**M did a broadcast element wise power.
In an attempt to summarize: scalar to a matrix power
1. may have been overlooked, or may have been omitted as confusing 2. if overlooked there are two possible answers as to what it could reasonably be a. a**m = exp(ln(a)*m) natural definition
For some definition of natural: it makes sense once you see it, but is seem like most people expected something else (in our four person sample, only one person came up with this definition -- not that that's good statistics.).
b. a**m = a**m.A broadcasting
In languages that provide an answer, I have the impression that the answer is usually (b). (E.g., GAUSS.) However perhaps in NumPy this is the least interesting way to go? But it is what I was expecting.
I'd inclined to leave it unimplemented. It seems like it's likely to cause confusion and my impression is that it's not a common enough construction that having to use a function should be a big burden for most if not all people. -- . __ . |-\ . . tim.hochberg@ieee.org
participants (4)
-
Alan G Isaac
-
Charles R Harris
-
Robert Kern
-
Timothy Hochberg