> 2009/7/7 keflavich :
>
> Hi, I want to be able to do something like:
>
> import numpy
> x=numpy.array([1,4,4,6,7,3,4,2])
> x.median()
>
> rather than
> numpy.median(x)
>
> so that in a function, I can call
> x.median()
> and allow x to be a masked array or a numpy array.
>
> Using the ma.median v
Also, there is a "non-method" way: the .T property:
>>> a = np. matrix([[1,2,3],[4,5,6],[7,8,9]])
>>> a
matrix([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]])
>>> b = a.T
>>> b
matrix([[1, 4, 7],
[2, 5, 8],
[3, 6, 9]])
DG
--- On Mon, 7/6/09, Chris Colbert wrote:
> From: Chr
and my grammar just sucks tonight...
On Tue, Jul 7, 2009 at 1:46 AM, Chris Colbert wrote:
> I should clarify, everything in python is an object. Even methods of
> classes. The syntax to invoke a method is the method name followed by the
> parenthese (). If you leave off the parentheses, python r
I should clarify, everything in python is an object. Even methods of
classes. The syntax to invoke a method is the method name followed by the
parenthese (). If you leave off the parentheses, python return the method
object. This can be useful if you want to pass the method to another
function or m
you actually have to call the method as transpose(). What you requested was
the actual method.
>>> import numpy as np
>>> a = np. matrix([[1,2,3],[4,5,6],[7,8,9]])
>>> a
matrix([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]])
>>> b = a.transpose()
>>> b
matrix([[1, 4, 7],
[2, 5, 8],
I'm using the Enthought Python Distribution. When I define a matrix and
transpose it, it appears that the result is no longer a matrix (see below).
This is both surprising and disappointing. Any suggestions will be
appreciated.
In [16]: A=matrix([[1,2,3],[4,5,6],[7,8,9]])
In [17]: B=A.transpos
That didn't fix it. I messed around some more, but I couldn't get the
spherical coordinates working. I decided to rework my first method. By
raising the radius to the one third power, like for the other method,
basically the same thing is accomplished. It's working now, thanks. :D
vecs = nump
>On Fri, Jul 3, 2009 at 10:21 PM, Alan Jackson wrote:
>>
>
>I don't see any problem here. If you can replicate your results, we
>would need more information about the versions.
>
>Josef
>
>'''
np.version.version
>'1.3.0'
scipy.version.version
>'0.8.0.dev5789'
>'''
>
In [4]: numpy.vers
ask the package maintainers
I typically build numpy with threaded atlas support, so the repo version
isn't good for me anyway.
And, the single threaded atlas repo libs are busted anyway...
On Mon, Jul 6, 2009 at 7:29 PM, John [H2O] wrote:
>
> Great! Solved/
>
> A question, however, any r
Great! Solved/
A question, however, any reason not to say replace the apt
dist-packages/numpy with the v1.3?
Chris Colbert wrote:
>
> I ran into this same problem a few days ago. The issue is that Python
> imports from /usr/python2.6/dist-packages before
> /usr/local/python2.6/dist-packages ca
I ran into this same problem a few days ago. The issue is that Python
imports from /usr/python2.6/dist-packages before
/usr/local/python2.6/dist-packages causing your numpy 1.3 (assuming its
installed there) to be hidden by the snaptic numpy.
To solve the problem, I added this line to my ~/.bashrc
Hi, I want to be able to do something like:
import numpy
x=numpy.array([1,4,4,6,7,3,4,2])
x.median()
rather than
numpy.median(x)
so that in a function, I can call
x.median()
and allow x to be a masked array or a numpy array.
Using the ma.median version by default is something of a workaround,
On Fri, Jul 3, 2009 at 10:21 PM, Alan Jackson wrote:
> I've tried the same scheme using R and it seems to give the right
> answers
>
>> quantile( rf(1000,10,10), .99)
> 99%
> 4.84548
>> quantile( rf(1000,11,10), .99)
> 99%
> 4.770002
>> quantile( rf(1000,11,11), .99)
> 99%
>
Hello,
I run Ubuntu 9.04 which has python-numpy 1.2 installed through apt-get. I
would like to upgrade to 1.3 in order to be able to use the
scikits.timeseries package. However, I cannot seem to do it using
apt-get/aptitude/synaptic or at least not that I've discovered.
Currently:
python -c "im
Le lundi 06 juillet 2009 à 17:57 +0200, Fabrice Silva a écrit :
> Le lundi 06 juillet 2009 à 17:13 +0200, Nils Wagner a écrit :
> > IIRC, the coefficients of your polynomial are complex.
> > So, you cannot guarantee that the roots are complex
> > conjugate pairs.
>
> Correct! If the construction
On Jul 6, 2009, at 1:12 PM, Elaine Angelino wrote:
> Hi -- We are subclassing from np.rec.recarray and are confused about
> how some methods of np.rec.recarray relate to (differ from)
> analogous methods of its parent, np.ndarray. Below are specific
> questions about the __eq__, __getitem__
Right.
DG
--- On Mon, 7/6/09, David Cournapeau wrote:
> From: David Cournapeau
> Subject: Re: [Numpy-discussion] The baffling behavior that just won't die
> To: "Discussion of Numerical Python"
> Date: Monday, July 6, 2009, 2:50 AM
> David Goldsmith wrote:
> > --- On Mon, 7/6/09, David Courn
Hi -- We are subclassing from np.rec.recarray and are confused about how
some methods of np.rec.recarray relate to (differ from) analogous methods of
its parent, np.ndarray. Below are specific questions about the __eq__,
__getitem__ and view methods, we'd appreciate answers to our specific
questio
Le lundi 06 juillet 2009 à 17:13 +0200, Nils Wagner a écrit :
> IIRC, the coefficients of your polynomial are complex.
> So, you cannot guarantee that the roots are complex
> conjugate pairs.
Correct! If the construction is done with X1 and X1* treated separately,
the coefficients appear to be co
On Mon, 06 Jul 2009 16:53:42 +0200
Fabrice Silva wrote:
> Le lundi 06 juillet 2009 à 08:16 -0600, Charles R Harris
>a écrit :
>
>> Double precision breaks down at about degree 25 if
>>things are well
>> scaled, so that is suspicious in itself. Also, the
>>companion matrix
>> isn't Hermitean
Le lundi 06 juillet 2009 à 08:16 -0600, Charles R Harris a écrit :
> Double precision breaks down at about degree 25 if things are well
> scaled, so that is suspicious in itself. Also, the companion matrix
> isn't Hermitean so that property of the roots isn't preserved by the
> algorithm. If it w
On Mon, Jul 6, 2009 at 7:30 AM, Dag Sverre Seljebotn <
da...@student.matnat.uio.no> wrote:
> I'm trying to fledge out Cython's numpy.pxd, and have a question:
>
> Is there documentation anywhere, or a simple-to-remember rule, on
> whether the return value of a NumPy C API is incref-ed or not?
>
>
On Mon, Jul 6, 2009 at 8:16 AM, Charles R Harris
wrote:
>
>
> On Mon, Jul 6, 2009 at 3:44 AM, Fabrice Silva wrote:
>
>> Le vendredi 03 juillet 2009 à 10:00 -0600, Charles R Harris a écrit :
>>
>> > What do you mean by erratic? Are the computed roots different from
>> > known roots? The connection
On Mon, Jul 6, 2009 at 3:44 AM, Fabrice Silva wrote:
> Le vendredi 03 juillet 2009 à 10:00 -0600, Charles R Harris a écrit :
>
> > What do you mean by erratic? Are the computed roots different from
> > known roots? The connection between polynomial coefficients and
> > polynomial values becomes s
I'm trying to fledge out Cython's numpy.pxd, and have a question:
Is there documentation anywhere, or a simple-to-remember rule, on
whether the return value of a NumPy C API is incref-ed or not?
E.g. PyArray_BASE, PyArray_DESCR obviously does not incref; while I'm
assuming that PyArray_New* mus
2009/7/6 Ian Mallett :
> randvecs = numpy.array([x,y,z]).reshape((size,size,3))
Try numpy.array([x, y, z]).T.reshape((size, size, 3))
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/nump
David Goldsmith wrote:
> --- On Mon, 7/6/09, David Cournapeau wrote:
>
>
>> avoid this. I can't understand why anyone would got into
>> site-packages ?
>>
>
> Why, to look at the source, of course - I did it all the time in Mac & Unix,
> too - must not have ever tried to run anything whil
Le vendredi 03 juillet 2009 à 10:00 -0600, Charles R Harris a écrit :
> What do you mean by erratic? Are the computed roots different from
> known roots? The connection between polynomial coefficients and
> polynomial values becomes somewhat vague when the polynomial degree
> becomes large, it is
--- On Mon, 7/6/09, David Cournapeau wrote:
> avoid this. I can't understand why anyone would got into
> site-packages ?
Why, to look at the source, of course - I did it all the time in Mac & Unix,
too - must not have ever tried to run anything while in there I guess; maybe I
knew this and fo
Pauli Virtanen wrote:
> Sun, 05 Jul 2009 20:27:02 -0700, d_l_goldsmith kirjoitti:
> [clip]
>
>> c:\Python25\Lib\site-packages\numpy>python
>>
>
> Just don't run Python inside Numpy's package directory. This is not Numpy-
> specific: doing a thing like that just breaks relative imports.
>
Thanks, Pauli; learn something new everyday! ;-)
DG
--- On Mon, 7/6/09, Pauli Virtanen wrote:
> From: Pauli Virtanen
> Subject: Re: [Numpy-discussion] The baffling behavior that just won't die
> To: numpy-discussion@scipy.org
> Date: Monday, July 6, 2009, 12:33 AM
> Sun, 05 Jul 2009 20:27:02
Sun, 05 Jul 2009 20:27:02 -0700, d_l_goldsmith kirjoitti:
[clip]
> c:\Python25\Lib\site-packages\numpy>python
Just don't run Python inside Numpy's package directory. This is not Numpy-
specific: doing a thing like that just breaks relative imports.
Also, Robert's answer in the old thread applies
32 matches
Mail list logo
