Travis Oliphant schrieb:
O.K. So, the problem is that when I defined matrix multiplication, I
mistakenly believed that dot always interpreted 1-d arrays as row
vectors which it is now clear it doesn't.
I think this led to the issues.
So, making dot always return arrays seems like the
On Tue, 27 Mar 2007, Bill Baxter apparently wrote:
xformedPt = someComplicatedNonLinearThing(pt)
I do stuff like the above quite frequently in my code,
although with arrays rather than matrices.
Exactly: that was one other thing I found artificial.
Surely the points will then be wanted as
The last time I had this problem i ended up running python
in gdb and setting breakpoints at the appropriate dgemm calls.
That way i could see exactly what numpy was using to do dgemm.
Simon.
On Tue, 27 Mar 2007 10:20:41 +1000
Justin Bedo [EMAIL PROTECTED] wrote:
Hi All,
I'm trying to
Exactly: that was one other thing I found artificial.
Surely the points will then be wanted as arrays.
So my view is that we still do not have a use case
for wanting matrices yielded when iterating across
rows of a matrix.
It's pretty clear from my perspective: 1-D slices of matrices *must*
On 3/27/07, Robert Cimrman [EMAIL PROTECTED] wrote:
ok. now which version of scipy (scipy.__version__) do you use (you may
have posted it, but I missed it)? Not so long ago, there was an effort
by Nathan Bell and others reimplementing sparsetools + scipy.sparse to
get better usability and
Zachary Pincus wrote:
rest of linear algebra -- e.g. that m[0] yields a matrix if m is a
matrix-- it almost certainly would violate the principle of least
surprise for iteration over m (intuitively understood to be choosing m
[0] then m[1] and so forth) to yield anything other than a
Hi Zachary,
I think your response highlights very well
the apparent design flaw.
Here is your response to my request for a use case where
iteration over a matrix should yield matrices:
do not iterate!
Does some part of you not find that just a little bizarre?!
As for offering as a use
Charles R Harris wrote:
On 3/26/07, *Travis Oliphant* [EMAIL PROTECTED]
mailto:[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))
David Koch wrote:
On 3/27/07, Robert Cimrman [EMAIL PROTECTED] wrote:
ok. now which version of scipy (scipy.__version__) do you use (you may
have posted it, but I missed it)? Not so long ago, there was an effort
by Nathan Bell and others reimplementing sparsetools + scipy.sparse to
get
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.
This is again simple assertion.
**Why** would one expect this?
Some people clearly do not.
One person commented
A bit new to numpy, trying to move over some IDL code.
I have a complex array selection expression, where I need an array of indexes as
a result, so I can use this as a selection expression to apply changes to a
different array.
I have two images, image1 and image2, plus an array sigma, the
Ludwig wrote:
In pseudo code:
indexes = where(image1 0 and image2 0 and sigma quality)
result[indexes] = i # scalar
When I run this numpy tells me that the that the truth value of the array
comparison is ambiguous -- but I do not want to compare the whole arrays here,
but the value
Alan Isaac wrote:
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.
Hi all,
I'm having a good discussion with Carl Banks and Greg Ewing over on
python-dev about the buffer interface. We are converging on a pretty
good design, IMHO. If anybody wants to participate in the discussion,
please read the PEP (there are a few things that still need to change)
and
Hello all,
I suspect my previous email did not contain the full chain of my
reasoning, because I thought that some parts were basically obvious.
My point was merely that given some pretty basic fundamental tenants
of numpy, Alan's suggestions quickly lead to *serious issues* far
worse
Hi Zach,
The use case I requested was for iteration over a
matrix where it is desirable that matrices are yielded.
That is not what you offered.
The context for this request is my own experience:
whenever I have needed to iterate over matrices,
I have always wanted the arrays. So I am simply
Alan G Isaac wrote:
Hi Zach,
The use case I requested was for iteration over a
matrix where it is desirable that matrices are yielded.
That is not what you offered.
The context for this request is my own experience:
whenever I have needed to iterate over matrices,
I have always wanted
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
I take it from context that you consider it desirable
to end up with a list of matrices?
I guess I would find it more natural to work with the
arrays, but perhaps that starts just being taste.
Thank you,
Alan
Hi,
I have a specific question and then a general question, and some
minor issues for clarification.
Specifically, regarding the arguments to getbufferproc:
166 format
167address of a format-string (following extended struct
168syntax) indicating what is in each element of
169
All,
I could swear that I ran once into a numpy (or scipy) function that output the
unique values of a 1d ndarray along with the number of occurences of each
element. If I'm not completely mistaken, it 's a private function initially
in Fortran.
Does this ring a bell to anyone ? Where could I
Hello,
There's unique and unique1d, but these don't output the number of
occurences.
There's also bincount, which outputs the number of each element, but
includes zeros for non-present elements and so could be problematic
for certain data.
Zach
On Mar 27, 2007, at 2:28 PM, Pierre GM
Alan G Isaac wrote:
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
I take it from context that you consider it desirable
to end up with a list of matrices?
Honestly, I don't care. You asked about iteration, and I gave you an example
where it was
I've been using numpy.memmap to access large arrays very nicely, but now
I desire to instantiate a masked array that uses memmap objects.
Using a memmap instance for the data works just fine and as expected.
However, using a memmap for the mask value seems to load the entire
object into memory,
Zach,
There's unique and unique1d, but these don't output the number of
occurences.
There's also bincount, which outputs the number of each element, but
includes zeros for non-present elements and so could be problematic
for certain data.
Well, I found it anyway. As I was pretty sure it was
Zachary Pincus wrote:
Hi,
Is this saying that either NULL or a pointer to B can be supplied
by getbufferproc to indicate to the caller that the array is unsigned
bytes? If so, is there a specific reason to put the (minor)
complexity of handling this case in the caller's hands,
We have a class which is a subclass of ndarray which defines
__array_finalize__ to add an attribute. The class looks something like
this:
class UnitArray(ndarray):
# ...
def __new__(cls, data, dtype=None, copy=True, units=None):
# ...
arr = array(data, dtype=dtype, copy=copy)
res =
On Tuesday 27 March 2007 20:08:04 Bryce Hendrix wrote:
We have a class which is a subclass of ndarray which defines
__array_finalize__ to add an attribute. The class looks something like
this:
Ahah, we ran into this problem a few months ago:
You should not initialize your units attribute in
On Tue, 27 Mar 2007, Robert Kern apparently wrote:
Gram-Schmidt orthogonalization
Alan G Isaac wrote:
I take it from context that you consider it desirable
to end up with a list of matrices?
Robert wrote:
Honestly, I don't care. You asked about iteration, and
I gave you an
Is this saying that either NULL or a pointer to B can be supplied
by getbufferproc to indicate to the caller that the array is unsigned
bytes? If so, is there a specific reason to put the (minor)
complexity of handling this case in the caller's hands, instead of
dealing with it internally to
29 matches
Mail list logo
