[Numpy-discussion] Document server error.

>From issue #1951 : The following URL shows an 500 internal server error: > http://docs.scipy.org/doc/numpy/reference/generated/numpy.var.html > Can someone with access to the server take a look? TIA, Chuck

[Numpy-discussion] except expression discussion on python-ideas

I would like to invite numpy community to weigh in on the idea that is getting momentum at https://mail.python.org/pipermail/python-ideas/2014-February/025437.html The main motivation is to provide syntactic alternative to proliferation of default value options, so that x = getattr(u, 'answer',

Re: [Numpy-discussion] Default dtype of genfromtxt

I can certainly see the advantage of switching over to None. It makes a lot of sense. One thing that concerns me, though is a file full of whole number values. Would that get interpreted as integers? If so, then that affect needs to be aligned with some other proposed changes with respect to operat

[Numpy-discussion] Default dtype of genfromtxt

This is apropos issue #1860 , where it is proposed that the default dtype of genfromtxt should be None rather than float. A decision is needed. Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussio

Re: [Numpy-discussion] Rethinking multiple dimensional indexing with sequences?

So to be clear - what's being suggested is that code like this will be deprecated in 1.9, and then in some future release break: slices = [] for i in ...: slices.append(make_slice(...)) subarray = arr[slices] Instead, you will have to do: subarray = arr[tuple(slices)] And the reason is that

Re: [Numpy-discussion] New (old) function proposal.

On Tue, Feb 18, 2014 at 11:11 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > > > > On Tue, Feb 18, 2014 at 9:03 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> >> On Tue, Feb 18, 2014 at 9:40 AM, Nathaniel Smith wrote: >> >>> On 18 Feb 2014 11:05, "Charles R Ha

Re: [Numpy-discussion] allocated memory cache for numpy

On 18.02.2014 16:21, Julian Taylor wrote: > On Mon, Feb 17, 2014 at 9:42 PM, Nathaniel Smith wrote: >> On 17 Feb 2014 15:17, "Sturla Molden" wrote: >>> >>> Julian Taylor wrote: >>> When an array is created it tries to get its memory from the cache and when its deallocated it returns it

Re: [Numpy-discussion] New (old) function proposal.

On 18 Feb 2014 12:04, "Charles R Harris" wrote: > Where does 'shingle' come from. I can see the analogy but haven't seen that as a technical term. It just seems like a good name :-). -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http:

Re: [Numpy-discussion] New (old) function proposal.

On Tue, Feb 18, 2014 at 9:03 AM, Charles R Harris wrote: > > > > On Tue, Feb 18, 2014 at 9:40 AM, Nathaniel Smith wrote: > >> On 18 Feb 2014 11:05, "Charles R Harris" >> wrote: >> > >> > Hi All, >> > >> > There is an old ticket, #1499, that suggest adding a segment_axis >> function. >> > >> > d

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

Andreas Hilboll wrote: > On 18.02.2014 17:47, Sturla Molden wrote: >> Undortunately the DCMT code was LGPL, not BSD, I don't know if this has >> changed. > > I just checked. The file dcmt0.6.1b.tgz, available from > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dc.html, contains > this li

Re: [Numpy-discussion] New (old) function proposal.

On Tue, Feb 18, 2014 at 9:40 AM, Nathaniel Smith wrote: > On 18 Feb 2014 11:05, "Charles R Harris" > wrote: > > > > Hi All, > > > > There is an old ticket, #1499, that suggest adding a segment_axis > function. > > > > def segment_axis(a, length, overlap=0, axis=None, end='cut', endvalue=0): > >

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

On 18.02.2014 17:47, Sturla Molden wrote: > Matthieu Brucher wrote: >> Hi, >> >> The main issue with PRNG and MT is that you don't know how to >> initialize all MT generators properly. A hash-based PRNG is much more >> efficient in that regard (see Random123 for a more detailed >> explanation). >>

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

Matthieu Brucher wrote: > Hi, > > The main issue with PRNG and MT is that you don't know how to > initialize all MT generators properly. A hash-based PRNG is much more > efficient in that regard (see Random123 for a more detailed > explanation). >> From what I heard, if MT is indeed chosen for RN

Re: [Numpy-discussion] New (old) function proposal.

On 18 Feb 2014 11:05, "Charles R Harris" wrote: > > Hi All, > > There is an old ticket, #1499, that suggest adding a segment_axis function. > > def segment_axis(a, length, overlap=0, axis=None, end='cut', endvalue=0): > """Generate a new array that chops the given array along the given axis >

Re: [Numpy-discussion] Rethinking multiple dimensional indexing with sequences?

On Di, 2014-02-18 at 17:09 +0100, Sebastian Berg wrote: > Hey all, > > Now also NumPy commonly uses lists here to build up indexing tuples > (since they are mutable), however would it really be so bad if we had to > do `arr[tuple(slice_list)]` in the end to resolve this issue? So the > proposal w

Re: [Numpy-discussion] New (old) function proposal.

On Di, 2014-02-18 at 09:05 -0700, Charles R Harris wrote: > Hi All, > > > There is an old ticket, #1499, that suggest adding a segment_axis > function. > > def segment_axis(a, length, overlap=0, axis=None, end='cut', endvalue=0): > """Generate a new array that chops the given array along the

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

I won't dive into the discussion as well, except to say that parallel RNGs have to have specific characteristics, mainly to initialize many RNGs at the same time. I don't know how MRG31k3p handles this, as the publications was not very clear on this aspect. I guess it falls down as the other from t

Re: [Numpy-discussion] New (old) function proposal.

yes, but I don't like the name too much. Unfortunately, I can't think of a better one. Ben Root On Tue, Feb 18, 2014 at 11:05 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Hi All, > > There is an old ticket, #1499 , > that suggest adding

[Numpy-discussion] Rethinking multiple dimensional indexing with sequences?

Hey all, currently in numpy this is possible: a = np.zeros((5, 5)) a[[0, slice(None, None)]] #this behaviour has its quirks, since the "correct" way is: a[(0, slice(None, None))] # or identically a[0, :] The problem with using an arbitrary sequence is, that an arbitrary sequence is also typicall

[Numpy-discussion] New (old) function proposal.

Hi All, There is an old ticket, #1499 , that suggest adding a segment_axis function. def segment_axis(a, length, overlap=0, axis=None, end='cut', endvalue=0): """Generate a new array that chops the given array along the given axis into overlappi

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

I won't go in the discussion of which RNG is better for some problems. I'll just tell why we pick this one. We needed a parallel RNG and we wanted to use the same RNG on CPU and on GPU. We discussed with a professor in our department that is well know in that field(Pierre L'Ecuyer) and he recomman

Re: [Numpy-discussion] allocated memory cache for numpy

I am cross-posting this to Cython user group to make sure they see this. Sturla Nathaniel Smith wrote: > On 18 Feb 2014 10:21, "Julian Taylor" wrote: > > On Mon, Feb 17, 2014 at 9:42 PM, Nathaniel Smith wrote: > On 17 Feb 2014 15:17, "Sturla Molden" wrote: > > Julian Taylor wrote: > > Whe

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

Hi, The main issue with PRNG and MT is that you don't know how to initialize all MT generators properly. A hash-based PRNG is much more efficient in that regard (see Random123 for a more detailed explanation). >From what I heard, if MT is indeed chosen for RNG in numerical world, in parallel world

Re: [Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

AFAIK, CMRG (MRG31k3p) is more equidistributed than Mersenne Twister, but the period is much shorter. However, MT is getting acceptance as the PRNG of choice for numerical work. And when we are doing stochastic simulations in Python, the speed of the PRNG is unlikely to be the bottleneck. Sturla

Re: [Numpy-discussion] allocated memory cache for numpy

On 18 Feb 2014 10:21, "Julian Taylor" wrote: > > On Mon, Feb 17, 2014 at 9:42 PM, Nathaniel Smith wrote: > > On 17 Feb 2014 15:17, "Sturla Molden" wrote: > >> > >> Julian Taylor wrote: > >> > >> > When an array is created it tries to get its memory from the cache and > >> > when its deallocated

Re: [Numpy-discussion] allocated memory cache for numpy

On Mon, Feb 17, 2014 at 9:42 PM, Nathaniel Smith wrote: > On 17 Feb 2014 15:17, "Sturla Molden" wrote: >> >> Julian Taylor wrote: >> >> > When an array is created it tries to get its memory from the cache and >> > when its deallocated it returns it to the cache. >> ... > > Another optimization w

[Numpy-discussion] Suggestion: Port Theano RNG implementation to NumPy

Hi, In a ticket I did a coment and Charles suggested that I post it here: In Theano we have an C implementation of a faster RNG: MRG31k3p. It is faster on CPU, and we have a GPU implementation. It would be relatively easy to parallize on the CPU with OpenMP. If someone is interested to port this

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 9:42 AM, Robert Kern wrote: > On Tue, Feb 18, 2014 at 2:37 PM, wrote: >> On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern wrote: >>> On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote: On 18 Feb 2014 07:07, "Robert Kern" wrote: > > On Tue, Feb 18, 2014 at

[Numpy-discussion] Numpy type inheritance

Hi All, I'm looking for some expert explication of the problems in issues #1398and #1397 . The segfault in the second looks nasty. Chuck ___ NumPy-Discussion mailing

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 2:37 PM, wrote: > On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern wrote: >> On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote: >>> On 18 Feb 2014 07:07, "Robert Kern" wrote: On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote: > Perhaps integer pow

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 8:53 AM, Robert Kern wrote: > On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote: >> On 18 Feb 2014 07:07, "Robert Kern" wrote: >>> >>> On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote: >>> > Perhaps integer power should raise an error on negative powers? That

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 1:46 PM, Nathaniel Smith wrote: > On 18 Feb 2014 07:07, "Robert Kern" wrote: >> >> On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote: >> > Perhaps integer power should raise an error on negative powers? That way >> > people will at least be directed to use arr ** -1

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On 18 Feb 2014 07:07, "Robert Kern" wrote: > > On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote: > > Perhaps integer power should raise an error on negative powers? That way > > people will at least be directed to use arr ** -1.0 instead of silently > > getting nonsense from arr ** -1. > >

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

Nathaniel Smith wrote: > Perhaps integer power should raise an error on negative powers? That way > people will at least be directed to use arr ** -1.0 instead of silently > getting nonsense from arr ** -1. That sounds far better than silently returning errorneous results. Sturla _

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Di, 2014-02-18 at 11:44 +, Sturla Molden wrote: > Robert Kern wrote: > > > We're talking about numpy.power(), not just ndarray.__pow__(). The > > equivalence of the two is indeed an implementation detail, but I do > > think that it is useful to maintain the equivalence. If we didn't, it >

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 12:00 PM, Nathaniel Smith wrote: > Perhaps integer power should raise an error on negative powers? That way > people will at least be directed to use arr ** -1.0 instead of silently > getting nonsense from arr ** -1. Controllable by np.seterr(invalid=...)? I could get behi

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

Perhaps integer power should raise an error on negative powers? That way people will at least be directed to use arr ** -1.0 instead of silently getting nonsense from arr ** -1. On 18 Feb 2014 06:57, "Robert Kern" wrote: > On Tue, Feb 18, 2014 at 11:44 AM, Sturla Molden > wrote: > > Robert Kern

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 11:44 AM, Sturla Molden wrote: > Robert Kern wrote: > >> We're talking about numpy.power(), not just ndarray.__pow__(). The >> equivalence of the two is indeed an implementation detail, but I do >> think that it is useful to maintain the equivalence. If we didn't, it >> wo

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

Robert Kern wrote: > We're talking about numpy.power(), not just ndarray.__pow__(). The > equivalence of the two is indeed an implementation detail, but I do > think that it is useful to maintain the equivalence. If we didn't, it > would be the only exception, to my knowledge. But in this case i

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 11:19 AM, Sturla Molden wrote: > Robert Kern wrote: > >> That's fine if you only have one value for each operand. When you have >> multiple values for each operand, say an exponent array containing >> both positive and negative integers, that becomes a problem. > > I don't

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

Robert Kern wrote: > That's fine if you only have one value for each operand. When you have > multiple values for each operand, say an exponent array containing > both positive and negative integers, that becomes a problem. I don't really see why. If you have a negative integer in there you get

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 10:59 AM, Todd wrote: > > On Feb 18, 2014 11:55 AM, "Robert Kern" wrote: >> I am -1 on the proposal to make power(x:int, y:int) always return a >> float. It is usually trivial to just make the exponent a float if one >> wants a float returned. Or we could introduce an fpo

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Feb 18, 2014 11:55 AM, "Robert Kern" wrote: > > On Tue, Feb 18, 2014 at 9:51 AM, Sturla Molden wrote: > > Charles R Harris wrote: > >> This is apropos issue #899 < >> href="https://github.com/numpy/numpy/issues/899";> https://github.com/numpy/numpy/issues/899>, > >> where it is suggested that

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

On Tue, Feb 18, 2014 at 9:51 AM, Sturla Molden wrote: > Charles R Harris wrote: >> This is apropos issue #899 <> href="https://github.com/numpy/numpy/issues/899";>https://github.com/numpy/numpy/issues/899>, >> where it is suggested that power promote integers to float. That sounds >> reasonable t

Re: [Numpy-discussion] Proposal to make power return float, and other such things.

Charles R Harris wrote: > This is apropos issue #899 < href="https://github.com/numpy/numpy/issues/899";>https://github.com/numpy/numpy/issues/899>, > where it is suggested that power promote integers to float. That sounds > reasonable to me, but such a change in behavior makes it a bit iffy. > >

Re: [Numpy-discussion] allocated memory cache for numpy

Julian Taylor wrote: > I was thinking of something much simpler, just a layer of pointer stacks > for different allocations sizes, the larger the size the smaller the > cache with pessimistic defaults. > e.g. the largest default cache layer is 128MB and with one or two > entries so we can cache te

Re: [Numpy-discussion] Proposal: Chaining np.dot with mdot helper function

Just to give an idea about the performance implications I timed the operations on my machine %timeit reduce(dotp, [x, v, x.T, y]).shape 1 loops, best of 3: 1.32 s per loop %timeit reduce(dotTp, [x, v, x.T, y][::-1]).shape 1000 loops, best of 3: 394 µs per loop I was just interested in a nicer fo

Re: [Numpy-discussion] allocated memory cache for numpy

On Tue, Feb 18, 2014 at 1:47 AM, David Cournapeau wrote: > > On Mon, Feb 17, 2014 at 7:31 PM, Julian Taylor > wrote: >> >> hi, >> I noticed that during some simplistic benchmarks (e.g. >> https://github.com/numpy/numpy/issues/4310) a lot of time is spent in >> the kernel zeroing pages. >> This is

[Numpy-discussion] ANN: numexpr 2.3.1 released

== Announcing Numexpr 2.3.1 == Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. It wears multi-