I'm afraid I'm not quite done with this, yet.
There's still more I am confused about, even after reading the manual
(again).
There is something fundamentally weird about record arrays, that doesn't
seem to click with me.
Please have a look at this piece of code:
import numpy as N
newtype =
Hello,
I am interest both in numarray type multiplication and matrix type
multiplication.
But I am not shure that I can buy an Unicode keyboard.
May be it would be possible to implement a class with
user definissable (?) signs.
My choice :
a * b - numarray type multi
a !* b - matrix
--
PS... (sorry for all the posts, for anyone who isn't interested...)
Agreed, it looks like aliasing. Nevertheless, any resampling
procedure is supposed to deal with this internally, right? Either by
lowpass filtering (traditional case), or by spline fitting (spline
case as described by Unser
Thanks for the information and the paper link, James. I certainly
appreciate the perspective, and now see why the anti-aliasing and
reconstruction filtering might best be left to clients of a
resampling procedure.
Hopefully at least some of the kinks in the spline interpolation (to
date:
The unicode keyboards sailing everywhere is just a matter of time
And python 2-symbol operators soon will look obsolete, this will
increase migrating from python to Sun fortress etc. I took a look at
their unicode syntax for math formulas
http://research.sun.com/projects/plrg/faq/NAS-CG.pdf
it
Hi folks,
Sorry to rain on this parade, but unicode variable names and/or other
syntactic elements have already been rejected for Python 3:
http://www.python.org/dev/peps/pep-3099/
Python 3000 source code won't use non-ASCII Unicode characters for
anything except string literals or
MDP version 2.1 and symeig 1.2 have been released!
What's new in version 2.1?
--
- Fully compatible with NumpPy 1.0, the first stable release
of the descendant of the Numeric python extension module
- symeig project resumed and updated
- For increased speed, scipy and
Dear Numpy devels,
First of all, thank you for the great job done so far! We've been
updating our MDP module, and had a chance to appreciate it.
We found an issue in the random module: the random state contains an
array of int32 or int64 depending on the architecture, making
it not portable.
Bill Baxter wrote:
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
Alan G Isaac 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__()
Tiziano Zito schrieb:
The optional symeig module contains a Python wrapper for the LAPACK
functions to solve the standard and generalized eigenvalue problems
for symmetric (hermitian) positive definite matrices. Those
specialized algorithms give an important speed-up with respect to the
Alan G Isaac wrote:
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
Zachary Pincus wrote:
Anyhow, feel free to disagree with me -- I'm no expert here. I'm only
mentioning this as a public service to make it clear that most of
what's being proposed in this thread is, for better or worse, 100%
dead-in-the-water for Python 3, and the rest will have a
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
Perhaps things would be clearer if we thought of the
constituent groups of data in a matrix as being themselves
matrices.
This thinking of is what you have suggested before.
You need to explain why it is not begging the question.
Hi again,
I want to select/access several columns from a sparse csc_matrix. The only
way I could think of is the following enormously inefficient algorithm which
basically initalizes a new lil_matrix (for assigments) and loops over all
the specified columns and does sparse - dense - sparse. All
Alan G Isaac schrieb:
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.
On Mon, 26 Mar 2007, Sven Schreiber apparently wrote:
I think
Alan G Isaac schrieb:
What feels wrong: iterating over a container does not give
access to the contained objects. This is not Pythonic.
If you iterate over the rows of the matrix, it feels natural to me to
get the row vectors -- and as you know a 1d-array does not contain the
information
Alan G Isaac schrieb:
What feels wrong: iterating over a container does not give
access to the contained objects. This is not Pythonic.
On Mon, 26 Mar 2007, Sven Schreiber apparently wrote:
If you iterate over the rows of the matrix, it feels
natural to me to get the row vectors
On Mar 25, 2007, at 9:44 PM, Robert Kern wrote:
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.
get_include() does the trick. Thanks for your help.
--
Daniel Wheeler
On 3/26/07, Robert Cimrman [EMAIL PROTECTED] wrote:
Could you be more specific on which type of the sparse matrix storage
did you use?
Hi Robert,
I used csc_matrix.
/David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Mon, 26 Mar 2007, Sebastian Haase apparently wrote:
A matrix is an object that you expect a certain
(mathematical !) behavior from. If some object behaves
intuitively right -- that's ultimately pythonic!
The problem is, as I am not the only one to point out,
this particular behavior is
David Koch wrote:
On 3/26/07, Robert Cimrman [EMAIL PROTECTED] wrote:
Could you be more specific on which type of the sparse matrix storage
did you use?
Hi Robert,
I used csc_matrix.
OK, good. Would you mind measuring csc * csr, csc * csc, csr * csc and
csr * csr? I am curious how
Alan G Isaac wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
Perhaps things would be clearer if we thought of the
constituent groups of data in a matrix as being themselves
matrices.
This thinking of is what you have suggested before.
You need to explain why it is not
Dear list
what is the fastet way to multiply with a diagonal matrix from left or
right and without to build a square matrix from the diagonal.
Here it what I am looking for:
import numpy as N
def diagmult(X, Y):
Matrix multiplication X*Y where either X or Y is a diagonal matrix.
Alexander Michael kirjoitti:
On 3/23/07, Nadav Horesh [EMAIL PROTECTED] wrote:
How about
a = empty((5,7,4))
c = a[...,-1]
Solely because I want to use the array with code that assumes it is
working with two-dimensional arrays but yet only performs operations
on the outer
This is a small function I use to speed up multiplication with diagonal
matrices. I don't know if it's the *fastest* way to do it, but it's
pretty fast.
def mult_diag(d, mtx, left=True):
Multiply a full matrix by a diagonal matrix.
This function should always be faster than dot.
[EMAIL PROTECTED] wrote:
Dear list
what is the fastet way to multiply with a diagonal matrix from left or
right and without to build a square matrix from the diagonal.
Use broadcasting to do your work for you.
from numpy import array, newaxis
diags = array([...])
mymatrix =
Ok,
I did and the results are:
csc * csc: 372.601957083
csc * csc: 3.90811300278
csr * csc: 15.3202679157
csr * csr: 3.84498214722
Mhm, quite insightful. Note, that in an operation X.transpose() * X, where X
is csc_matrix, then X.tranpose() is automatically cast to csr_matrix. A
re-cast to csc
On 3/26/07, René Bastian [EMAIL PROTECTED] wrote:
May be it would be possible to implement a class with
user definissable (?) signs.
Yes, it is possible and is done.
See this recipe to define an Infix operator class either:
x |op| y
or:
x op y
On 3/26/07, Nils Wagner [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/25/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
snip
Ok, things should be working now. In order to get rid of the scipy problems
I just needed to rm the scipy package in
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
This is again simple assertion.
**Why** would one expect this?
Some people clearly do not.
Charles R Harris wrote:
On 3/26/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/25/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
**Why** would one expect this?
Some people clearly
On 3/26/07, Travis Oliphant [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/26/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/25/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:
Since matrices are an iterable Python object,
we *expect* to iterate over the contained objects.
(Arrays.) I am not sure why this is not evident to all,
but it is surely the sticking point in this discussion.
A matrix is not a container of matrices.
That it acts like one is surprsing.
Alan G Isaac wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
**Why**
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2007, Colin J. Williams apparently wrote:
One would expect the iteration over A to return row
vectors, represented by (1, n) matrices.
On 3/26/07, Alan G Isaac [EMAIL PROTECTED] wrote:
This is again simple assertion.
Charles R Harris wrote:
On 3/26/07, *Travis Oliphant* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/26/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
I've finally made the changes to fix the scalar coercion model problems
in NumPy 1.0.1
Now, scalar coercion rules only apply when involved types are of the
same basic kind.
Thus,
array([1,2,3],int8)*10
returns an int8 array
but
array([1,2,3],int8)*10.0
returns a float64 array.
If you
Great!
On Mar 26, 2007, at 4:52 PM, Travis Oliphant wrote:
I've finally made the changes to fix the scalar coercion model
problems
in NumPy 1.0.1
Now, scalar coercion rules only apply when involved types are of the
same basic kind.
[...]
___
Perry Greenfield wrote:
Great!
On Mar 26, 2007, at 4:52 PM, Travis Oliphant wrote:
I've finally made the changes to fix the scalar coercion model
problems
in NumPy 1.0.1
Now, scalar coercion rules only apply when involved types are of the
same basic kind.
Actually, the rule is
On 3/26/07, Travis Oliphant [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/26/07, *Travis Oliphant* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
On 3/26/07, *Nils Wagner* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
I think that might be the simplest thing, dot overrides subtypes. BTW,
here is another ambiguity
In [6]: dot(array([[1]]),ones(2))
---
exceptions.ValueErrorTraceback (most
recent call
On Mon, Mar 26, 2007 at 01:52:28PM -0700, Travis Oliphant wrote:
I really do want to get 1.0.2 out the door soon. What still needs to be
fixed before then?
The code in ticket 469 still causes a memory error, so that might be
worth fixing.
Cheers
Stéfan
On 3/26/07, Travis Oliphant [EMAIL PROTECTED] wrote:
I think that might be the simplest thing, dot overrides subtypes. BTW,
here is another ambiguity
In [6]: dot(array([[1]]),ones(2))
---
exceptions.ValueError
Charles R Harris wrote:
The rule 1-d is always a *row* vector only applies when converting
to a
matrix.
In this case, the dot operator does not convert to a matrix but
uses
rules for operating with mixed 2-d and 1-d arrays inherited from
Numeric.
I'm
On 3/26/07, Travis Oliphant [EMAIL PROTECTED] wrote:
Charles R Harris wrote:
The rule 1-d is always a *row* vector only applies when converting
to a
matrix.
In this case, the dot operator does not convert to a matrix but
uses
rules for operating with mixed 2-d
Hi All,
I'm trying to compile NumPy using the ATLAS libraries but am having
some difficulty with it. I've managed to build numpy such that
lapack_lite.so is linked as follows:
linux-gate.so.1 = (0xe000)
libatlas.so = /usr/local/atlas/lib/libatlas.so (0xb79e9000)
On Mon, 26 Mar 2007, Travis Oliphant wrote:
It actually has been offered. You just don't accept it.
Matrices are containers of matrices.
If M is an (mxn) matrix then M[0] is a (1xn) matrix.
Viewing this 1xn matrix as a 1-d array loses it's row-vectorness.
This seems perfectly
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
May I see a use case where the desired
return when iterating through a matrix
is rows as matrices? That has never
been what I wanted.
On Tue, 27 Mar 2007, Bill Baxter wrote:
AllMyPoints = mat(rand(100,2)) # 100 two-d points
for pt in
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote:
May I see a use case where the desired
return when iterating through a matrix
is rows as matrices? That has never
been what I wanted.
On Tue, 27 Mar 2007, Bill Baxter wrote:
AllMyPoints
Hi,
I just went through my mail archive and found these two minor
outstanding issues. Thought I'd ask for comments before the new
release:
From: Charles R Harris [EMAIL PROTECTED]
Subject: Re: [Numpy-discussion] Assign NaN, get zero
On 11/11/06, Lisandro Dalcin [EMAIL PROTECTED] wrote:
On
52 matches
Mail list logo
