Re: [Numpy-discussion] Adding weights to cov and corrcoef

; charset="UTF-8" > > On Mi, 2014-03-05 at 10:21 -0800, David Goldsmith wrote: > > +1 for it being "too baroque" for NumPy--should go in SciPy (if it > > isn't already there): IMHO, NumPy should be kept as "lean and mean" as > > possible, e

Re: [Numpy-discussion] Adding weights to cov and corrcoef (Sebastian Berg)

Date: Wed, 05 Mar 2014 17:45:47 +0100 > From: Sebastian Berg > Subject: [Numpy-discussion] Adding weights to cov and corrcoef > To: numpy-discussion@scipy.org > Message-ID: <1394037947.21356.20.camel@sebastian-t440> > Content-Type: text/plain; charset="UTF-8" > > Hi all, > > in Pull Request https

Re: [Numpy-discussion] [JOB ANNOUNCEMENT] Software Developer permanent position

On Thu, Feb 20, 2014 at 10:37 PM, wrote: > Date: Fri, 21 Feb 2014 07:43:17 +0100 > From: "V. Armando Sol?" > *Ref. 8173* *- Deadline for returning application forms: * *01/04/2014* > I assume that's the European date format, i.e., the due date is April 1, 2014, not Jan. 4 2014, oui? DG

Re: [Numpy-discussion] create numerical arrays from strings

Date: Thu, 6 Feb 2014 08:42:38 -0800 > From: Chris Barker > Subject: Re: [Numpy-discussion] create numerical arrays from strings > To: Discussion of Numerical Python > Message-ID: > < > calgmxekvnqok6wty-jbjzgaeu5ewhh1_flmsqxjsujfclex...@mail.gmail.com> > Content-Type: text/plain; charse

Re: [Numpy-discussion] A one-byte string dtype?

Date: Tue, 21 Jan 2014 19:20:12 + > From: Robert Kern > Subject: Re: [Numpy-discussion] A one-byte string dtype? > > The wiki is frozen. Please do not add anything to it. It plays no role in > our current development workflow. Drafting a NEP or two and iterating on > them would be the next

Re: [Numpy-discussion] A one-byte string dtype?

On Tue, Jan 21, 2014 at 10:00 AM, wrote: > Date: Tue, 21 Jan 2014 09:53:25 -0800 > From: David Goldsmith > Subject: Re: [Numpy-discussion] A one-byte string dtype? > To: numpy-discussion@scipy.org > Message-ID: > 7altpxmrz4miujy2xebyi_fy5...@mail.gmail.com> >

Re: [Numpy-discussion] A one-byte string dtype?

uot;utf-8" > > On 21 Jan 2014 17:28, "David Goldsmith" wrote: > > > > > > Am I the only one who feels that this (very important--I'm being sincere, > not sarcastic) thread has matured and specialized enough to warrant it's > own home on the

Re: [Numpy-discussion] A one-byte string dtype?

Am I the only one who feels that this (very important--I'm being sincere, not sarcastic) thread has matured and specialized enough to warrant it's own home on the Wiki? DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org

Re: [Numpy-discussion] A one-byte string dtype? (Charles R Harris)

On Mon, Jan 20, 2014 at 9:11 AM, wrote: > I think that is right. Not having an effective way to handle these common > scientific data sets will block acceptance of Python 3. But we do need to > figure out the best way to add this functionality. > > Chuck > Sounds like it might be time for some f

Re: [Numpy-discussion] using loadtxt to load a text file in to a numpy array (Charles R Harris)

On Wed, Jan 15, 2014 at 9:52 AM, wrote: > Date: Wed, 15 Jan 2014 10:57:51 -0700 > From: Charles R Harris > Subject: Re: [Numpy-discussion] using loadtxt to load a text file in > to a numpy array > To: Discussion of Numerical Python > Message-ID: > < > cab6mnxjpvjbsozzy0ctk1bk+kd

Re: [Numpy-discussion] Quaternion type @ rosettacode.org

Thanks Anthony and Paul! OlyDLG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Quaternion type @ rosettacode.org

o last question for Octonion and/or general n-basis Grassmann (exterior) and/or Clifford Algebras? (rosettacode appears to have none of these). Thanks! David Goldsmith ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/m

Re: [Numpy-discussion] proposal: min, max of complex should give warning (Ralf Gommers)

> > As for your proposal, it would be good to know if adding a warning would > actually catch any bugs. For the truncation warning it caught several in > scipy and other libs IIRC. > > Ralf > In light of this, perhaps the pertinent unit tests should be modified (even if the warning suggestion isn'

Re: [Numpy-discussion] getting the equivalent complex dtype from a real or int array

We really ought to have a special page for all of Robert's little gems! DG On Tue, Oct 29, 2013 at 10:00 AM, wrote: > > -Message: 5 > Date: Tue, 29 Oct 2013 17:02:33 + > From: Robert Kern > Subject: Re: [Numpy-discussion] getting the equivalent complex dtype >

[Numpy-discussion] On Topic: Faster way to implement Bernstein polys: explicit or recursion?

Many thanks to Daniele Nicolodi for pointing me to the Wikipedia article on Bézier curves. Said article gives two formulae for the Bézier curve of degree n: one explicit, one recursive. Using numpy.polynomial.Polynomial as the base class, and its evaluation method for the evaluation in each dimen

[Numpy-discussion] OT: How are SVG data converted into curves

Does anyone on this list know how Scalable Vector Graphics C, S, etc. command data are translated into curves (i.e., pixel maps) and might you be willing to answer some questions off-list? Thanks! DG PS: I receive numpy-discussion in digest mode, so if you "qualify," please reply directly to my

Re: [Numpy-discussion] Bug in numpy.correlate documentation

Date: Wed, 9 Oct 2013 21:54:07 +0100 > From: Nathaniel Smith > Subject: Re: [Numpy-discussion] Bug in numpy.correlate documentation > To: Discussion of Numerical Python > Message-ID: > z8v-ahuu+85lz88xywmawxgzhk5ghtfuw8h...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > O

Re: [Numpy-discussion] Bug in numpy.correlate documentation

Looks like Wolfram MathWorld would favor the docstring, but the possibility of a "use-domain" dependency seems plausible (after all, a similar dilemma is observed, e.g., w/ the Fourier Transform)--I guess one discipline's future is another discipline's past. :-) http://mathworld.wolfram.com/Autoco

Re: [Numpy-discussion] [ANN] MATLAB ODE solvers - now available in Python (Dmitrey)

On Sun, Oct 6, 2013 at 10:00 AM, wrote: > Message: 2 > Date: Sat, 05 Oct 2013 21:36:48 +0300 > From: Dmitrey > Subject: Re: [Numpy-discussion] [ANN] MATLAB ODE solvers - now > available inPython > To: Discussion of Numerical Python > Cc: numpy-discussion@scipy.org > Message-ID: <138

Re: [Numpy-discussion] [ANN] MATLAB ODE solvers - now available in Python

MCR stands for MATLAB Compiler Runtime and if that's all it requires, that's great, 'cause that's free. Look forward to giving this a try; does the distribution come w/ examples? DG Date: Sat, 05 Oct 2013 11:27:04 +0300 > From: Dmitrey > Subject: Re: [Numpy-discussion] [ANN] MATLAB ODE solvers

Re: [Numpy-discussion] Valid algorithm for generating a 3D Wiener Process?

Thanks, guys. Yeah, I realized the problem w/ the uniform-increment-variable-direction approach this morning: physically, it ignores the fact that the particles hitting the particle being tracked are going to have a distribution of momentum, not all the same, just varying in direction. But I don'

[Numpy-discussion] Valid algorithm for generating a 3D Wiener Process?

Is this a valid algorithm for generating a 3D Wiener process? (When I graph the results, they certainly look like potential Brownian motion tracks.) def Wiener3D(incr, N): r = incr*(R.randint(3, size=(N,))-1) r[0] = 0 r = r.cumsum() t = 2*np.pi*incr*(R.randint(3, size=(N,))-1)

[Numpy-discussion] Generating a (uniformly distributed) random bit list of length N

Thanks, St?fan, speed: N ~ 1e9. Thanks again. DG -- > > Message: 1 > Date: Sun, 22 Sep 2013 14:04:09 -0700 > From: David Goldsmith > Subject: [Numpy-discussion] Generating a (uniformly distributed) >

[Numpy-discussion] Generating a (uniformly distributed) random bit list of length N

Is np.random.randint(2, size=N) the fastest way to do this? Thanks! DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Problem w/ Win installer

Hi, folks! Having a problem w/ the Windows installer; first, the "back-story": I have both Python 2.7 and 3.2 installed. When I run the installer and click next on the first dialog, I get the message that I need Python 2.7, which was not found in my registry. I ran regedit and searched for Pytho

Re: [Numpy-discussion] [OT: MATLAB] Any way to globally make Matlab struct attributes Python-property-like

> Date: Tue, 14 Sep 2010 20:55:03 -0400 > From: Ken Watford > Subject: Re: [Numpy-discussion] [OT: MATLAB] Any way to globally make > Matlab struct attributes Python-property-like > To: Discussion of Numerical Python > On Mon, Sep 13, 2010 at 10:24 PM, David Goldsmit

[Numpy-discussion] [OT: MATLAB] Any way to globally make Matlab struct attributes Python-property-like

I.e., I'd, at minimum, like to globally replace get(Handel, 'Property') with object.Property and set(Handel, 'Property', value) with object.Property = value to an arbitrary level of composition. (It's really getting cumbersome having to compound gets and sets all over the place while debug

Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 47, Issue 61

pe: text/plain; charset=UTF-8 > > On Fri, Aug 20, 2010 at 14:25, David Goldsmith > wrote: > > Hi! ?Please forgive the re-post: I forgot to change the subject line > > and I haven't seen a response to this yet, so I'm assuming the former > > might be the cause

[Numpy-discussion] Making MATLAB and Python "play nice"

Hi! Please forgive the re-post: I forgot to change the subject line and I haven't seen a response to this yet, so I'm assuming the former might be the cause of the latter. My question follows the quoted posts. Thanks! > From: Sturla Molden > Subject: Re: [Numpy-discussion] [SciPy-Dev] Good-bye

Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 47, Issue 47

Date: Wed, 18 Aug 2010 09:20:41 +0200 > From: Sturla Molden > Subject: Re: [Numpy-discussion] [SciPy-Dev] Good-bye, sort of (John >Hunter) > To: Discussion of Numerical Python > Message-ID: <8c0b2317-2a22-4828-99e8-ac6c0f778...@molden.no> > Content-Type: text/plain; charset=us-asci

Re: [Numpy-discussion] [SciPy-Dev] Good-bye, sort of (John Hunter)

> > After several years now of writing Python and now having written my first > > on-the-job 15 operational MATLAB LOC, all of which are string, cell > array, > > and file processing, I'm ready to say: "MATLAB: what a PITA!" :-( > > Ahh, cell arrays, they bring back memories. Makes you pine for a

Re: [Numpy-discussion] [SciPy-Dev] Good-bye, sort of

cell array, and file processing, I'm ready to say: "MATLAB: what a PITA!" :-( DG > I appreciate your eye for detail in the docs project, and I hope we won't > lose that. > > Kind regards > Stéfan > > On 29 Jul 2010 07:10, "David Goldsmith" wro

Re: [Numpy-discussion] endian.h change

I assume this is addressed to David C., correct? DG On Fri, Jul 30, 2010 at 10:08 AM, Ralf Gommers wrote: > Hi David, > > Commit r8541 broke building with numscons for me, does this fix look okay: > > http://github.com/rgommers/numpy/commit/1c88007ab00cf378ebe19fbe54e9e868212c73d1 > > I am puzzl

Re: [Numpy-discussion] Don't understand this error

Thanks, that was it. DG On Tue, Jul 27, 2010 at 3:02 PM, Robert Kern wrote: > On Tue, Jul 27, 2010 at 16:59, David Goldsmith > wrote: > > res = np.fromfunction(make_res, (nx, ny)) > >File "C:\Python26\lib\site-packages\numpy\core\numeric.py", line 1538, &g

[Numpy-discussion] Don't understand this error

res = np.fromfunction(make_res, (nx, ny)) File "C:\Python26\lib\site-packages\numpy\core\numeric.py", line 1538, in fromfunction args = indices(shape, dtype=dtype) File "C:\Python26\lib\site-packages\numpy\core\numeric.py", line 1480, in indices tmp.shape = (1,)*i + (dim,)+(1,)*(N-i-1) ValueE

Re: [Numpy-discussion] Help w/ indexing, please

#x27;t think you should. > Thanks, John, that works; you may be right about the transposing, but I can work that out empirically. Thanks again! DG > > On Tue, Jul 27, 2010 at 9:10 AM, David Goldsmith > wrote: > >> Hi! I have a large M x K, M, K ~ 1e3 array L of indices - non-nega

[Numpy-discussion] Help w/ indexing, please

Hi! I have a large M x K, M, K ~ 1e3 array L of indices - non-negative integers in the range 0 to N-1 - and an N x 3 array C (a matplotlib colormap). I need to create an M x K x 3 array R such that R[m,k,j] = C[L[m,k], j], j = 0,1,2. I want to do so w/out having to loop through all the (m,k) ind

Re: [Numpy-discussion] Problem using polyutils.mapdomain with fromfunction

On Sun, Jul 25, 2010 at 7:08 AM, Charles R Harris wrote: > > On Sun, Jul 25, 2010 at 2:32 AM, David Goldsmith > wrote: > >> Why am I being told my coefficient array is not 1-d when both coefficient >> arrays--old and new--are reported to have shape (2L,): >> >&

[Numpy-discussion] Problem using polyutils.mapdomain with fromfunction

Why am I being told my coefficient array is not 1-d when both coefficient arrays--old and new--are reported to have shape (2L,): C:\Users\Fermat>python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more in

Re: [Numpy-discussion] doc string linalg.solve --> works for b is matrix

Take it as a reminder: when reporting an error or problem, even if it doesn't seem relevant, always provide version number. :-) DG On Wed, Jul 21, 2010 at 12:50 PM, Mark Bakker wrote: > I am using 1.3.0. > Glad to hear it is correct in 1.4.0 > Sorry for bothering you with an old version, but I

Re: [Numpy-discussion] doc string linalg.solve --> works for b is matrix

What version of numpy are you using? That docstring was updated in that fashion about 8 mo. ago (at least in the Wiki; I'm not sure exactly when it was merged, but it does appear that way in version 1.4.0). DG I am using linalg.solve to solve a system of linear equations. As I have to > solve m

[Numpy-discussion] docstring for numpy.fft

I believe (hope) I've satisfactorily "finished" the docstring for numpy.fft; concerned parties are encouraged to take a look at it in the Wiki and provide comments there in its Discussion section. DG ___ NumPy-Discussion mailing list NumPy-Discussion@sci

Re: [Numpy-discussion] numpy.fft, yet again

On Tue, Jul 20, 2010 at 5:47 PM, David Cournapeau wrote: > On Wed, Jul 21, 2010 at 2:02 AM, David Goldsmith > wrote: > > On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith < > d.l.goldsm...@gmail.com> > > wrote: > >> > >> On Thu, Jul 15,

Re: [Numpy-discussion] numpy.fft, yet again

On Thu, Jul 15, 2010 at 9:41 AM, David Goldsmith wrote: > On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> David Goldsmith skrev: >> > >> > >> > Interesting comment

Re: [Numpy-discussion] numpy.fft, yet again

On Thu, Jul 15, 2010 at 3:20 AM, Martin Raspaud wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > David Goldsmith skrev: > > > > > > Interesting comment: it made me run down the fftpack tutorial > > <http://docs.scipy.org/sci

Re: [Numpy-discussion] numpy.fft, yet again

On Mon, Jul 12, 2010 at 8:26 PM, David Goldsmith wrote: > 2010/7/12 Jochen Schröder > >> On 13/07/10 08:04, Eric Firing wrote: >> > On 07/12/2010 11:43 AM, David Goldsmith wrote: >> >> > From the docstring: >> >> >> >> &q

Re: [Numpy-discussion] Here's what I've done to numpy.fft

2010/7/12 Jochen Schröder > On 13/07/10 08:47, David Goldsmith wrote: > > In light of my various questions and the responses thereto, here's what > > I've done (but not yet committed) to numpy.fft. > > > > There are many ways to define the DFT, va

Re: [Numpy-discussion] numpy.fft, yet again

2010/7/12 Jochen Schröder > On 13/07/10 08:04, Eric Firing wrote: > > On 07/12/2010 11:43 AM, David Goldsmith wrote: > >> > From the docstring: > >> > >> "A[0] contains the zero-frequency term (the mean of the signal)" > >> > >>

Re: [Numpy-discussion] Here's what I've done to numpy.fft

On Mon, Jul 12, 2010 at 6:33 PM, Travis Oliphant wrote: > > On Jul 12, 2010, at 5:47 PM, David Goldsmith wrote: > > > In light of my various questions and the responses thereto, here's what > I've done (but not yet committed) to numpy.fft. > > > > There are

[Numpy-discussion] Here's what I've done to numpy.fft

In light of my various questions and the responses thereto, here's what I've done (but not yet committed) to numpy.fft. There are many ways to define the DFT, varying in the sign of the exponent, normalization, etc. In this implementation, the DFT is defined as .. math:: A_k = \sum_{m=0}^{n-

Re: [Numpy-discussion] numpy.fft, yet again

On Mon, Jul 12, 2010 at 3:04 PM, Eric Firing wrote: > On 07/12/2010 11:43 AM, David Goldsmith wrote: > > >From the docstring: > > > > "A[0] contains the zero-frequency term (the mean of the signal)" > > > > And yet, consistent w/ the definition

[Numpy-discussion] numpy.fft, yet again

>From the docstring: "A[0] contains the zero-frequency term (the mean of the signal)" And yet, consistent w/ the definition given in the docstring (and included w/ an earlier email), the code gives, e.g.: >>> import numpy as np >>> x = np.ones((16,)); x array([ 1., 1., 1., 1., 1., 1., 1.,

Re: [Numpy-discussion] Another reality check

Thanks, both. On Mon, Jul 12, 2010 at 5:39 AM, Fabrice Silva wrote: > Le lundi 12 juillet 2010 à 18:14 +1000, Jochen Schröder a écrit : > > On 07/12/2010 12:36 PM, David Goldsmith wrote: > > > On Sun, Jul 11, 2010 at 6:18 PM, David Goldsmith > > > mailto:d.l.

Re: [Numpy-discussion] Another reality check

On Sun, Jul 11, 2010 at 6:18 PM, David Goldsmith wrote: > In numpy.fft we find the following: > > "Then A[1:n/2] contains the positive-frequency terms, and A[n/2+1:]contains > the negative-frequency terms, in order of decreasingly negative > frequency." >

[Numpy-discussion] Another reality check

In numpy.fft we find the following: "Then A[1:n/2] contains the positive-frequency terms, and A[n/2+1:] contains the negative-frequency terms, in order of decreasingly negative frequency." Just want to confirm that "decreasingly negative frequency" means ..., A[n-2] = A_(-2), A[n-1] = A_(-1), as

[Numpy-discussion] "Nyquist frequency" in numpy.fft docstring

Hi! I'm a little confused: in the docstring for numpy.fft we find the following: "For an even number of input points, A[n/2] represents both positive and negative Nyquist frequency..." but according to http://en.wikipedia.org/wiki/Nyquist_frequency (I know, I know, I've bad mouthed Wikipedia in

[Numpy-discussion] Fwd: effect of shape=None (the default) in format.open_memmap

No reply? -- Forwarded message -- From: David Goldsmith Date: Tue, Jul 6, 2010 at 7:03 PM Subject: effect of shape=None (the default) in format.open_memmap To: numpy-discussion@scipy.org Hi, I'm trying to wrap my brain around the affect of leaving shape=None (the defaul

[Numpy-discussion] finfo.eps v. finfo.epsneg

>>> np.finfo('float64').eps # returns a scalar 2.2204460492503131e-16 >>> np.finfo('float64').epsneg # returns an array array(1.1102230246251565e-16) Bug or feature? DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/m

[Numpy-discussion] effect of shape=None (the default) in format.open_memmap

Hi, I'm trying to wrap my brain around the affect of leaving shape=None (the default) in format.open_memmap. First, I get that it's only even seen if the file is opened in write mode. Then, write_array_header_1_0 is called with dict d as second parameter, w/, as near as I can see, d['shape'] stil

[Numpy-discussion] where support full broadcasting, right?

Hi. The docstring (in the wiki) for where states: x, y : array_like, optionalValues from which to choose. *x* and *y* need to have the same shape as *condition*.But: >>> x = np.eye(2) >>> np.where(x,2,3) array([[2, 3], [3, 2]]) So apparently where supports broadcasting of scalars at least

Re: [Numpy-discussion] Ticket #1223...

On Thu, Jul 1, 2010 at 9:11 AM, Charles R Harris wrote: > > On Thu, Jul 1, 2010 at 8:40 AM, Bruce Southey wrote: > >> On 06/29/2010 11:38 PM, David Goldsmith wrote: >> >> On Tue, Jun 29, 2010 at 8:16 PM, Bruce Southey wrote: >> >>> On Tue, Jun 29, 2

Re: [Numpy-discussion] Ticket #1223...

On Tue, Jun 29, 2010 at 8:16 PM, Bruce Southey wrote: > On Tue, Jun 29, 2010 at 6:03 PM, David Goldsmith > wrote: > > On Tue, Jun 29, 2010 at 3:56 PM, wrote: > >> > >> On Tue, Jun 29, 2010 at 6:37 PM, David Goldsmith > >> wr

Re: [Numpy-discussion] numpy.all docstring reality check

OK, now I understand: dtype(out) is preserved, whatever that happens to be, not dtype(a) (which is what I thought it meant) - I better clarify. Thanks! DG On Tue, Jun 29, 2010 at 7:28 PM, Skipper Seabold wrote: > On Tue, Jun 29, 2010 at 8:50 PM, David Goldsmith > wrote: > > Hi, f

[Numpy-discussion] numpy.all docstring reality check

Hi, folks. Under Parameters, the docstring for numpy.core.fromnumeric.all says: "out : ndarray, optionalAlternative output array in which to place the result. It must have the same shape as the expected output and *the type is preserved*." [emphasis added].I assume this is a copy-and-paste-from-a

Re: [Numpy-discussion] Ticket #1223...

On Tue, Jun 29, 2010 at 3:56 PM, wrote: > On Tue, Jun 29, 2010 at 6:37 PM, David Goldsmith > wrote: > > ...concerns the behavior of numpy.random.multivariate_normal; if that's > of > > interest to you, I urge you to take a look at the comments (esp. mine :-) > );

[Numpy-discussion] Ticket #1223...

...concerns the behavior of numpy.random.multivariate_normal; if that's of interest to you, I urge you to take a look at the comments (esp. mine :-) ); otherwise, please ignore the noise. Thanks! DG ___ NumPy-Discussion mailing list NumPy-Discussion@sci

Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"

On Sun, Jun 27, 2010 at 3:44 AM, Pauli Virtanen wrote: > Sat, 26 Jun 2010 17:37:22 -0700, David Goldsmith wrote: > > On Sat, Jun 26, 2010 at 3:22 PM, wrote: > [clip] > >> Is there a chance that some changes got lost? > > > > (Almost) anything's possible...

Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?

On Sun, Jun 27, 2010 at 10:38 AM, Kurt Smith wrote: > On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser > wrote: > > Kurt Smith wrote: > >> I'd really like arr.copy(order='F') to work -- is it supposed to as > >> its docstring says, or is it supposed to raise a TypeError as it does > >> now? > >

Re: [Numpy-discussion] Strange behavior of np.sinc

On Sat, Jun 26, 2010 at 10:00 PM, David Goldsmith wrote: > On Sat, Jun 26, 2010 at 9:39 PM, Robert Kern wrote: > >> On Sat, Jun 26, 2010 at 23:33, David Goldsmith >> wrote: >> > Hi! The docstring for numpy.lib.function_base.sinc indicates that the >> > para

Re: [Numpy-discussion] Strange behavior of np.sinc

On Sat, Jun 26, 2010 at 9:39 PM, Robert Kern wrote: > On Sat, Jun 26, 2010 at 23:33, David Goldsmith > wrote: > > Hi! The docstring for numpy.lib.function_base.sinc indicates that the > > parameter has to be an ndarray, and that it will return the limiting > value 1 >

[Numpy-discussion] Strange behavior of np.sinc

Hi! The docstring for numpy.lib.function_base.sinc indicates that the parameter has to be an ndarray, and that it will return the limiting value 1 for sinc(0). Checking to see if it should actually say array_like, I found the following (Python 2.6): >>> np.sinc(np.array((0,0.5))) array([ 1.

Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"

On Sat, Jun 26, 2010 at 3:22 PM, wrote: > On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith > wrote: > > On Sat, Jun 26, 2010 at 3:03 PM, wrote: > >> > >> On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith > >> wrote: > >> > Something is syst

Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"

On Sat, Jun 26, 2010 at 3:28 PM, Vincent Davis wrote: > On Sat, Jun 26, 2010 at 4:22 PM, wrote: > > On Sat, Jun 26, 2010 at 6:11 PM, David Goldsmith > > wrote: > >> On Sat, Jun 26, 2010 at 3:03 PM, wrote: > >>> > >>> On Sat, Jun 2

Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"

On Sat, Jun 26, 2010 at 3:03 PM, wrote: > On Sat, Jun 26, 2010 at 5:56 PM, David Goldsmith > wrote: > > Something is systematically wrong if there are this many problems in the > > numpy.stats docstrings: numpy is supposed to be (was) almost completely > > ready for

Re: [Numpy-discussion] numpy.random.poisson docs missing "Returns"

Something is systematically wrong if there are this many problems in the numpy.stats docstrings: numpy is supposed to be (was) almost completely ready for review; please focus on scipy unless/until the reason why there are now so many problems in numpy.stats can be determined (I suspect the numpy.s

Re: [Numpy-discussion] Documentation error in numpy.random.logseries

On Sat, Jun 26, 2010 at 1:41 PM, Vincent Davis wrote: > numpy.random.logseries(p, size=None) > > but the parameters section, > Parameters: > loc : float > scale : float > 0. > size : {tuple, int} > Output shape. If the given shape is, e.g., (m, n, k), then m * n * k > samples are drawn. > > Notice

Re: [Numpy-discussion] Numpy.linalg.eig oddity

On Wed, Jun 23, 2010 at 2:17 PM, Robert Kern wrote: > On Wed, Jun 23, 2010 at 13:25, Salim, Fadhley (CA-CIB) > wrote: > > I've been investigating a truly bizarre bug related to the use of > > numpy.linalg.eig. > > > > I have two classes which both use numpy.linalg.eig. These classes are > > used

Re: [Numpy-discussion] Numpy.linalg.eig oddity

Is it not possible to update your versions to see if that solves the problem? DG On Wed, Jun 23, 2010 at 11:25 AM, Salim, Fadhley (CA-CIB) < fadhley.sa...@ca-cib.com> wrote: > I've been investigating a truly bizarre bug related to the use of > numpy.linalg.eig. > > I have two classes which both

[Numpy-discussion] SciPy docs marathon: a little more info

On Mon, Jun 14, 2010 at 2:05 AM, David Goldsmith wrote: > Hi, all! The scipy doc marathon has gotten off to a very slow start this > summer. We are producing less than 1000 words a week, perhaps because > many universities are still finishing up spring classes. So, this is > a seco

[Numpy-discussion] SciPy docs marathon: a little more info

On Mon, Jun 14, 2010 at 2:05 AM, David Goldsmith wrote: > Hi, all! The scipy doc marathon has gotten off to a very slow start this > summer. We are producing less than 1000 words a week, perhaps because > many universities are still finishing up spring classes. So, this is > a seco

[Numpy-discussion] SciPy docs marathon

wrong in the process. If you can help, please, now is the time to step forward. Thanks! On behalf of Joe and myself, David Goldsmith Olympia, WA ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Tensor contraction

Is this not what core.numeric.tensordotdoes? DG On Sun, Jun 13, 2010 at 12:37 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2010/6/13 Alan Bromborsky : > > I am writing symbolic tensor package for general relativity

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Wed, Jun 9, 2010 at 9:00 AM, David Cournapeau wrote: > On Thu, Jun 10, 2010 at 12:09 AM, Benjamin Root wrote: > >> I think that arrays are just syntax on pointer is indeed the key > >> reason for how C works here. Since a[b] really means a + b (which is > >> why 5[a] and a[5] are the same), I

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 3:49 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrot > 2010/6/8 Anne Archibald : > > Numpy arrays can have any configuration of memory strides, including > > some that are zero; C and Fortran contiguous arrays are simply those > > that have special arrangements of

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 1:56 PM, Benjamin Root wrote: > > On Tue, Jun 8, 2010 at 1:36 PM, Eric Firing wrote: > >> On 06/08/2010 08:16 AM, Eric Firing wrote: >> > On 06/08/2010 05:50 AM, Charles R Harris wrote: >> >> >> >> On Tue, Jun 8,

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 12:05 PM, Anne Archibald wrote: > On 8 June 2010 14:16, Eric Firing wrote: > > On 06/08/2010 05:50 AM, Charles R Harris wrote: > >> > >> > >> On Tue, Jun 8, 2010 at 9:39 AM, David Goldsmith < > d.l.goldsm...@gmail.com &g

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 8:43 AM, John Hunter wrote: > On Tue, Jun 8, 2010 at 10:33 AM, Sebastian Haase > wrote: > > On Tue, Jun 8, 2010 at 5:23 PM, David Goldsmith > wrote: > >> On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase > >> wrote: > >>>

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Tue, Jun 8, 2010 at 8:27 AM, Pavel Bazant wrote: > > > > Correct me if I am wrong, but the paragraph > > > > > > Note to those used to IDL or Fortran memory order as it relates to > > > indexing. Numpy uses C-order indexing. That means that the last index > > > usually (see xxx for exceptions)

Re: [Numpy-discussion] Is there really a moderator that reviews posts?

On Tue, Jun 8, 2010 at 12:10 AM, Sebastian Haase wrote: > I don't want to complain > But what is wrong with a limit of 40kB ? There are enough places where > one could upload larger files for everyone interested... > Not everyone knows about 'em, though - can you list some here, please. Than

Re: [Numpy-discussion] C vs. Fortran order -- misleading documentation?

On Mon, Jun 7, 2010 at 4:52 AM, Pavel Bazant wrote: > Correct me if I am wrong, but the paragraph > > Note to those used to IDL or Fortran memory order as it relates to > indexing. Numpy uses C-order indexing. That means that the last index > usually (see xxx for exceptions) represents the most r

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Mon, May 31, 2010 at 3:54 AM, Ralf Gommers wrote: > > > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sun, May 30, 2010 at 5:53 PM, Ralf Gommers < >> ralf.gomm...@googlemail.com> wrote: >> >>> >>> >>> On Mon, May 31, 2010 at 2:06 AM, Charl

Re: [Numpy-discussion] Finding Star Images on a Photo (Video chip) Plate?

On Fri, May 28, 2010 at 8:31 PM, Anne Archibald wrote: > On 28 May 2010 23:59, Wayne Watson wrote: > > That opened a few avenues. After reading this, I went on a merry search > with > > Google. I hit upon one interesting book, Handbook of CCD astronomy (Steve > B. > > Howell), that discusses PSFs

Re: [Numpy-discussion] Extending documentation to c code

On Thu, May 27, 2010 at 9:18 AM, Charles R Harris wrote: > > On Wed, May 26, 2010 at 8:14 AM, Pauli Virtanen wrote: > >> Wed, 26 May 2010 07:15:08 -0600, Charles R Harris wrote: >> > On Wed, May 26, 2010 at 2:59 AM, Pauli Virtanen wrote: >> > >> >> Wed, 26 May 2010 06:57:27 +0900, David Cournap

Re: [Numpy-discussion] numpy and the Google App Engine

On Wed, May 26, 2010 at 10:37 AM, Christopher Hanley wrote: > On Wed, May 26, 2010 at 12:49 PM, Dag Sverre Seljebotn > wrote: > > Christopher Hanley wrote: > >> Greetings, > >> > >> Google provides a product called App Engine. The description from > >> their site follows, > >> > >> "Google App E

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant wrote: > > On May 25, 2010, at 4:49 PM, David Goldsmith wrote: > > Travis: do you already have a place on the NumPy Development > Wiki<http://wiki.numpy.org/>where you're (b)logging your design decisions? > Seems li

Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

Travis: do you already have a place on the NumPy Development Wikiwhere you're (b)logging your design decisions? Seems like a good way for concerned parties to monitor your choices in more or less real time and thus provide comment in a timely fashion. DG On Tue, May 25, 2

Re: [Numpy-discussion] Extending documentation to c code

On Mon, May 24, 2010 at 8:06 PM, David Cournapeau wrote: > On Tue, May 25, 2010 at 3:01 AM, Charles R Harris > wrote: > > Hi All, > > > > I'm wondering if we could extend the current documentation format to the > c > > source code. The string blocks would be implemented something like > > > > /**

Re: [Numpy-discussion] Extending documentation to c code

On Mon, May 24, 2010 at 4:59 PM, Charles R Harris wrote: > > > On Mon, May 24, 2010 at 2:11 PM, David Goldsmith > wrote: > >> On Mon, May 24, 2010 at 11:01 AM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> Hi All, >

Re: [Numpy-discussion] Extending documentation to c code

On Mon, May 24, 2010 at 11:01 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Hi All, > > I'm wondering if we could extend the current documentation format to the c > source code. The string blocks would be implemented something like > > /**NpyDoc > """The Answer. > > Answer the Ultimat

Re: [Numpy-discussion] Runtime error in numpy.polyfit

gt; np.log results in float32 > > > >>>> np.log(np.array([5,2],int)).dtype > > dtype('float64') > > > > Josef > > > >> > >> Thanks, > >> Bill > >> > >> > >> > >> > >> > >&

  1   2   3   4   >