Eric Emsellem schrieb:
> Hi again
>
> after some hours of debugging I finally (I think) found the problem:
>
> numpy.sum([[0,1,2],[2,3,4]])
> 24
>
> numpy.sum([[0,1,2],[2,3,4]],axis=0)
> array([2, 4, 6])
>
> numpy.sum([[0,1,2],[2,3,4]],axis=1)
> array([3, 9])
>
>
> Isn't the first line suppos
Christopher Barker schrieb:
> Sven Schreiber wrote:
>> on my 1.0b5 I also see this docstring which indeed seems obsolete.
>
> I get this docs string from :
>
> >>> import numpy as N
> >>> N.__version__
> '1.0b5'
> >>> a = N.a
Travis Oliphant schrieb:
>
>> If not, shouldn't
>>
>>
>> numpy.sqrt(-1) raise a ValueError instead of returning silently nan?
>>
>>
> This is user adjustable. You change the error mode to raise on
> 'invalid' instead of pass silently which is now the default.
>
> -Travis
>
Could you plea
Hi,
as suggested on the website I use the kindly provided pre-built
(unofficial) ubuntu debs. Recently there is a new one available with
version numbe 1.0+~dev3336-0ads1.
Apart from the slightly strange +~ thing in there, it very much seems to
be based on trac changeset 3336, which is somewhere be
David Cournapeau schrieb:
> Hi there,
>
> I've just managed to nail down a bug which took me nearly two whole
> days to find: this is coming from an unexpected (at least from me)
> behaviour of numpy.
You have all my sympathy, I tripped over something similar not too long
ago, so welcome to
David Cournapeau schrieb:
> Sven Schreiber wrote:
>> Yes it's intended; as far as I understand the python/numpy syntax, <+>
>> is an operator, and that triggers assignment by copy (even if you do
>> something trivial as bar = +foo, you get a copy, if I'
Andrew Straw schrieb:
> The matplotlib .deb on my website is working fine for me with the latest
> numpy .deb there. If there are any recent patches or anything you are
> missing, please let me know -- it's not really a big deal to update
> them, although it might take a couple of days for me to f
Wow! The list is so quiet despite the fact that the numpy 1.0 release is
officially announced on the website, and the download is on sourceforge.
Well ok, it was expected and the download counters are all at zero, but
still.
I want to thank everybody who made this possible very much! I'm not a
num
jeremito schrieb:
> argsort() will do the trick. Thanks once again.
> Jeremy
>
I was a bit confused by your question, maybe you can clarify what you
did in the end.
IIRC, if the eigenvalues returned by numpy are real numbers (due to the
type of the underlying matrix and algorithm), then they
Hi,
now that 1.0 is out I would like to ask again about the status of the
numpy ebook. Is there any mechanism in place where owners can get the
updates?
Note that this is not a request to Travis to send me the latest version
by private email. That would be inefficient and my need is not that
urgen
izak marais schrieb:
> Hi
>
> Sorry if this is an obvious question, but what is the easiest way to
> multiply matrices in numpy? Suppose I want to do A=B*C*D. The ' * '
> operator apparently does element wise multiplication, as does the
> 'multiply' ufunc. All I could find was the numeric function
Johannes Loehnert schrieb:
> Hi,
>
> in extension to the previous answers, I'd like to say that it is strongly
> preferable to use dot(A,dot(B,C)) or dot(dot(A,B),C) instead of A*B*C.
>
> The reason is that with dot(), you can control of which operation is
> performed
> first, which can *massi
Gael Varoquaux schrieb:
> Hi all,
>
> I didn't get any answers to this email. Is it because the proposed
> addition to numpy is not of any interest to anybody apart from me ?
> Maybe the way I introduced this is wrong. Please tell me what is wrong
> with this proposition.
>
Well you didn't m
Pierre GM schrieb:
> On Sunday 12 November 2006 17:08, A. M. Archibald wrote:
>> On 12/11/06, Keith Goodman <[EMAIL PROTECTED]> wrote:
>>> Is anybody interested in making x.max() and nanmax() behave the same
>>> for matrices, except for the NaN part? That is, make
>>> numpy.matlib.nanmax return a m
Charles R Harris schrieb:
> In [1]: from scipy import linalg
>
> In [2]: help(linalg.eig)
>
>
> >>> from scipy import linalg
> >>> help(linalg.eig)
>
> Help on function eig in module scipy.linalg.decomp:
>
>
> I expect scipy.linalg and numpy.linalg are different modules co
Hi all,
this may be a stupid question, but why doesn't rand accept a shape tuple
as argument? I find the difference between the argument types of rand
and (for example) zeros somewhat confusing. (See below for
illustration.) Can anybody offer an intuition/explanation?
(This is still on 0.9.6 becau
Robert Kern schrieb:
>
> My point is that there is no need to change rand() and randn() to the "new"
> interface. The "new" interface is already there: random.random() and
> random.standard_normal().
>
Ok thanks for the responses and sorry for not searching the archives
about this.
I tend to sh
Hi all,
I just discovered that the diff function returns a numpy-array even for
matrix inputs. Since I'm a card-carrying matrix fanatic, I hope that
behavior qualifies as a bug.
Then I went through some (most?) other functions/methods for which IMO
it's best to return matrices if the input is als
Nicholas schrieb:
> Hi,
>
> I installed numpy 0.9.8 and when I try to import pylab I get a crash in
> multiarray.pyd. I then tried numpy 0.9.6, this cured the pylab import
> but now I cannot import scipy without crashing (again multiarray.pyd). I
> have tried complete reinstalls on 2 machines now
ns still return
numpy-arrays (as opposed to the applicable rest of numpy's functions)
Cheers,
Sven
Sven Schreiber schrieb:
> Hi all,
>
> I just discovered that the diff function returns a numpy-array even for
> matrix inputs. Since I'm a card-carrying matrix fanatic, I ho
Alexander Belopolsky schrieb:
> In my view it is more important that code is easy to read rather than
> easy to write. Interactive users will disagree, but in programming you
> write once and read/edit forever :).
The insight about this disagreement imho suggests a compromise (or call
it a dual s
Alexandre Fayolle schrieb:
> On Fri, Jun 16, 2006 at 10:43:42AM +0200, Sven Schreiber wrote:
>>> Again, there is no defense for abbreviating linear_least_squares
>>> because it is unlikely to appear in an expression and waste valuable
>>> horisontal space.
>>
identity seems to be a "crippled" version of eye without any value
added, apart from backwards-compatibility;
So from a user point of view, which one does numpy recommend?
And from a developer point of view (which doesn't really apply to me, of
course), should identity maybe become an alias for e
Keith Goodman schrieb:
> How do I make a NxN diagonal matrix with a Nx1 column vector x along
> the diagonal?
>
>>> help(n.diag)
Help on function diag in module numpy.lib.twodim_base:
diag(v, k=0)
returns the k-th diagonal if v is a array or returns a array
with v as the k-th diagonal if
Keith Goodman schrieb:
>
> Isn't rand(3,1) a vector?
afaik not in numpy's terms, because two numbers are given for the
dimensions -- I also struggle with that, because I'm a matrix guy like
you ;-)
>
> Off list I was given the example:
> x=rand(3)
> diag(3)
>
> That works. But my x is a Nx1
Bill Baxter schrieb:
> Neat, didn't know about that. But, grr, always returns matrix
> regardless of argument types.
> --bb
>
Well Bill mayb you should have stayed with matrices ;-)
But I also see no reason why it shouldn't be expected work for 2d-arrays
in general. (Or maybe even for more dime
Travis Oliphant schrieb:
>
> You can use a masked array specifically, or use nan's for missing values
> and just tell Python you want a floating-point array (because it finds
> the None object it's guessing incorrectly you want an "object" array.
>
> asarray(x, dtype=float)
>
> array([[ 1.
I agree with everything in your post, so I'm really happy you're a
central figure of numpy!
As for rand(), ones() etc.: I don't mind (too much) the double pair of
parentheses in ones((5,5)), but I find Robert's proposal in an earlier
thread ("If you want a function that takes tuples, use
numpy.ran
Pierre GM schrieb:
>> I was also a bit surprised at the following behavior:
a = numpy.asarray([1,1])
a
> array([1, 1])
a[0]=numpy.nan
a
> array([0, 1])
>
> Seems to affect only the int_ arrays:
>
a = numpy.asarray([1,1], dtype=float_)
a
> array([1., 1.])
a[0]=nu
Sasha schrieb:
>
> Consistency is already lost because 1d case allows both ones(5) and
> ones([5]) (and even ones((5,)) if anyone can tolerate that
> abomination). I don't think those who argue for sequence only are
> willing to require ones([5]).
Imho consistency is not lost there precisely be
Travis Oliphant schrieb:
> Bill Baxter wrote:
>> So in short my proposal is to:
>> -- make a.T a property of array that returns a.swapaxes(-2,-1),
>> -- make a.H a property of array that returns
>> a.conjugate().swapaxes(-2,-1)
>> and maybe
>> -- make a.M a property of array that returns numpy.
Tim Hochberg schrieb:
>>> -) .I for inverse; actually, why not add that to arrays as well as
>>> "syntactic sugar"?
>>>
>>>
>> Because it encourages people to do the wrong thing numerically speaking?
>> My understanding is that one almost never wants to compute the inverse
>> directly, a
Travis Oliphant schrieb:
>
> 1) .T Have some kind of .T attribute
>
+0
(the discussion in the .T thread convinced me it's better to keep the
matrix playground as a separate subclass, and so it's not important for
me what happens with pure arrays)
>
> 2) .H returns .T.conj()
+0
>
>
> 3) .
Ed Schofield schrieb:
>
> Okay ... ... let's make this the thread ;)
> I'd like to know why you, Sven, and anyone else on the list have gone
> back to using arrays after trying matrices. What was inconvenient about
> them? I'd like a nice juicy list. The whole purpose of the matrix
> class i
Ed Schofield schrieb:
>
> I'd like to call for a vote on what people would prefer, and then ask
> Travis to make a final pronouncement before the feature freeze.
>
>
>
>
> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> arguments, like rand((3,3)), as an alternativ
JJ schrieb:
> -
> Hello Ed:
> Here are a couple of examples off the top of my head:
>
> a = mat(arange(10))
> a.shape = (5,2)
> b = a.copy()
> c = hstack((a,b)) # should return a matrix
> type(c)
>
This hstack bug has been fixed recently.
>
> a[where(
JJ schrieb:
> Travis Oliphant ee.byu.edu> writes:
>
>> Svd returns matrices now. Except for the list of singular values
>> which is still an array. Do you want a 1xn matrix instead of an
>> array?
Although I'm a matrix supporter, I'm not sure here. Afaics the pro
argument is to have *everyt
Travis Oliphant schrieb:
>
> Because of this. I've removed the global_namespace functions (fft,
> ifft, rand, and randn) from numpy. They are *no longer* in the
> top-level name-space. If you want them, setup a startup-file
> appropriately.
>
Ok I'm glad that's settled; however, do I und
Tamaryn Menneer schrieb:
> Hi
>
> I'm running Python 2.4 on Windows XP. I've installed NumPy, and run the
> simple test of "import numeric" but I get the error "ImportError: No module
> named numeric" in return. The module numeric is located in
> C:\Python24\Lib\site-packages\numpy\core, but even
Webb Sprague schrieb:
> Could someone recommend a way to average an array along the columns
> without propagating the nans and without turning them into some weird
> number which bias the result? I guess I can just keep using an
> indexing array for fooArray, but if there is somehting more gracefu
Jon Peirce schrieb:
> There used to be a function generalized_inverse in the numpy.linalg
> module (certainly in 0.9.2).
>
> In numpy0.9.8 it seems to have been moved to the numpy.linalg.old
> subpackage. Does that mean it's being dropped? Did it have to move? Now
> i have to add code to my pac
Curzio Basso schrieb:
>> Well try it out and see for yourself ;-)
>
> good point :-)
>
>> But for sums it doesn't make a difference, right... Note that it's
>> called nan*sum* and not nanwhatever.
>
> sure, I was still thinking about the first post which was referring to
> the average...
>
> qr
Victoria G. Laidler schrieb:
>
> I understand that for interactive use, short names are more convenient;
> but shouldn't they be available aliases to the more general names? Since
> numpy is primarily a software library, I wouldn't expect it to sacrifice
> a standard best-practice in order to
Travis Oliphant schrieb:
> I'd like to make release 1.0beta on Thursday. Please submit bug-reports
> and fixes before then.
>
Just two things I noticed:
>>> import numpy as n
import dft -> failed: module compiled against version 90709 of C-API but
this version of numpy is 9090d
>>> n.__versio
Bill Baxter schrieb:
> For 1-d inputs I think r_ should act like vstack, and c_ should act
> like column_stack.
> Currently r_ and c_ both act like hstack for 1-d inputs.
Well Bill, as I said before, you should have stayed with matrices ;-)
Seriously, I think all the quirks you mentioned recently
Bill Baxter schrieb:
> Finally, I noticed that the atleast_nd methods return arrays
> regardless of input type. At a minimum, atleast_1d and atleast_2d on
> matrices should return matrices. I'm not sure about atleast_3d, since
> matrices can't be 3d. (But my opinon is that the matrix type shoul
Hi,
Summary: Slicing seems to be broken with matrices now.
I eagerly installed the new beta, but soon stumbled over this
bug. I hope I'm missing something, but afaics that behavior used to be
different (and correct) before in 0.9.8. Don't know exactly when this
changed, though. I did a fresh inst
Thanks for helping out on matrix stuff, Bill!
Bill Baxter schrieb:
> On 7/22/06, Sven Schreiber <[EMAIL PROTECTED]> wrote:
>>
>> Note the array slicing works correct, but the equivalent thing with the
>> matrix does not.
>
> Looks like it happened in rev 2698 of
Travis Oliphant schrieb:
> Sven Schreiber wrote:
>>
> The change was trying to fix up some cases but did break this one. The
> problem is that figuring out whether or not to transpose the result is a
> bit tricky. I've obviously still got it wrong.
>
Ok, th
Hi,
there was a thread about this before, diag() is currently only
partly useful if you work with numpy-matrices, because the 1d->2d
direction doesn't work, as there are no 1d-numpy-matrices. This is
unfortunate because a numpy-matrix with shape (n,1) or (1,m) should be
naturally treated as a vect
Robert Kern schrieb:
> Sven Schreiber wrote:
>> Hi,
>>
>> there was a thread about this before, diag() is currently only
>> partly useful if you work with numpy-matrices, because the 1d->2d
>> direction doesn't work, as there are no 1d-numpy-matrices. This
Hi,
I upgraded from 1.0b1 because I saw that the matrix-indexing bug was
already fixed (thanks!). Now there's a new regression:
>>> import numpy as n
>>> n.__version__
'1.0.2891'
>>> a = n.mat(n.eye(3))
>>> n.linalg.cholesky(a)
array([[ 1., 0., 0.],
[ 0., 1., 0.],
[ 0., 0., 1.]
Robert Kern schrieb:
> Sven Schreiber wrote:
>> That would be fine with me. However, I'd like to point out that after
>> some bug-squashing currently all numpy functions deal with
>> numpy-matrices correctly, afaik. The current behavior of numpy.diag
>> could
Here's my attempt at summarizing the diag-discussion.
The symptom is that currently transforming something like the vector
a b c
into the diagonal matrix
a 0 0
0 b 0
0 0 c
is not directly possible if you're working with numpy-matrices (i.e. the
vector is of type matrix and has shape (n,1) or (1,n
Charles R Harris schrieb:
> Hi Sven,
>
> On 7/28/06, *Sven Schreiber* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Here's my attempt at summarizing the diag-discussion.
>
>
>
>
> 2) Deprecate the use of diag which is
Hi,
notice the (confusing, imho) different defaults for the axis of the
following related functions:
nansum(a, axis=-1)
Sum the array over the given axis, treating NaNs as 0.
sum(x, axis=None, dtype=None)
Sum the array over the given axis. The optional dtype argument
is the data type
Sven Schreiber schrieb:
> Hi,
> notice the (confusing, imho) different defaults for the axis of the
> following related functions:
>
> nansum(a, axis=-1)
> Sum the array over the given axis, treating NaNs as 0.
>
> sum(x, axis=None, dtype=None)
> Sum the arra
Hi,
Satya Upadhya schrieb:
from Numeric import *
Well this list is about the numpy package, but anyway...
> the power function is giving a resultant matrix in which each element of
> matrix B is raised to the power of 0 so as to make it 1. But, taken as a
> whole i.e. matrix B to the power
Jordan Dawe schrieb:
> I just tried to compile numpy-1.0b3 under windows using mingw. I got
> this error:
...
>
> Any ideas?
>
No, except that I ran into the same problem... Hooray, I'm not alone ;-)
-sven
-
Using Tomcat
[EMAIL PROTECTED] schrieb:
> Since no one has downloaded 1.0b3 yet, if someone wants to put up the
> windows version for python2.3 i would be more than happy to be the first
> person to download it :)
>
I'm sorry, this is *not* for python 2.3, but I posted a build of current
svn for python 2.4 un
Hi,
I experienced this strange bug which caused a totally unrelated variable
to be overwritten (no exception or error was raised, so it took me while
to rule out any errors of my own).
The context where this is in is a method of a class (Vecm.getSW()), and
the instance of Vecm is created within a
Hi,
is this normal behavior?:
>>> import numpy as n; print n.mat(0.075).round(2); print
n.mat(0.575).round(2)
[[ 0.08]]
[[ 0.57]]
Again, yesterday's svn on windows.
cheers,
Sven
-
Using Tomcat but need to do more? Need to
hose bugs was the most difficult thing about
> porting Matlab code to Numpy (that and the lack of some major toolkit or
> function you use in Matlab doesn't have an equivalent in Numpy... like
> eigs()).
>
> --bb
>
>
>
> On 8/26/06, *Sven Schreiber* <[EMA
Charles R Harris schrieb:
> +1. I too suspect that what you have here is a reference/copy problem.
> The only thing that is local to the class is the reference (pointer),
> the data is global.
>
> Chuck
Ok, so you guys were right, turns out that my problem was caused by the
fact that a local assi
Charles R Harris schrieb:
> You can get what you expect using matrices:
>
...
> But generally it is best to just use arrays and get used to the conventions.
>
Well, there are different views on this subject, and I'm happy that the
numpy crew is really trying (and good at it) to make array *and*
Mathew Yeates schrieb:
> My head is about to explode.
>
> I have an M by N array of floats. Associated with the columns are
> character labels
> ['a','b','b','c','d','e','e','e'] note: already sorted so duplicates
> are contiguous
>
> I want to replace the 2 'b' columns with the sum of the 2 c
Hi,
never mind that the following syntax is wrong, but is it supposed to
yield that SystemError instead of something more informative?
(This is with b5 on win32 and python 2.4.3)
>>> b.reshape(3,3,axis = 1)
Traceback (most recent call last):
File "", line 1, in ?
SystemError: NULL result withou
67 matches
Mail list logo