Re: [Numpy-discussion] Move scipy.org docs to Github?

On Wed, Mar 15, 2017 at 6:16 AM, Bryan Van de ven wrote: > NumPy is a NumFocus fiscally sponsored project, perhaps they can help with > the costs of different/better hosting. Enthought already provides hosting and operations support (thanks!) – the problem is that it doesn't make sense to have a

Re: [Numpy-discussion] Move scipy.org docs to Github?

On Mar 15, 2017 12:28 PM, "Pauli Virtanen" wrote: Wed, 15 Mar 2017 12:11:09 -0400, Marten van Kerkwijk kirjoitti: > Astropy uses readthedocs quite happily (auto-updates on merges to master > too). AFAIK, scipy cannot be built on readthedocs. Another issue is that switching to rtd would (I thin

Re: [Numpy-discussion] Move scipy.org docs to Github?

On Mar 15, 2017 02:47, "Ralf Gommers" wrote: On Wed, Mar 15, 2017 at 3:21 PM, Matthew Brett wrote: > Hi, > > The scipy.org site is down at the moment, and has been for more than 36 > hours: > > https://github.com/numpy/numpy/issues/8779#issue-213781439 > > This has happened before: > > https:

Re: [Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))

On Sun, Mar 5, 2017 at 7:46 AM, Nico Schlömer wrote: >> I am honestly not sure where you are going at. This order seems the more >> natural order for most operations. > > Not sure what you mean by "natural". The most basic operations like `a[0] + > a[1]` are several times faster than `a[...,0] + a

Re: [Numpy-discussion] Numpy Overhead

On Feb 28, 2017 2:57 PM, "Sebastian K" wrote: Yes it is true the execution time is much faster with the numpy function. The Code for numpy version: def createMatrix(n): Matrix = np.empty(shape=(n,n), dtype='float64') for x in range(n): for y in range(n): Matrix[x, y] = 0.1 + ((x*y)%1000)/1000.

Re: [Numpy-discussion] Fortran order in recarray.

On Feb 21, 2017 3:24 PM, "Alex Rogozhnikov" wrote: Ah, got it. Thanks, Chris! I thought recarray can be only one-dimensional (like tables with named columns). Maybe it's better to ask directly what I was looking for: something that works like a table with named columns (but no labelling for rows

Re: [Numpy-discussion] ImportError: Importing the multiarray numpy extension module failed

On Tue, Feb 14, 2017 at 8:24 PM, Amit Bhosle wrote: > Hi, > > I'm struggling with a numpy issue and web search hasn't helped. I'm on > windows 10, and using Python27. > > I've tried reinstalling numpy, and also a few different versions, but > without any luck. > > numpy was pulled in as dependency

Re: [Numpy-discussion] NumPy 1.12.0 release

On Wed, Jan 18, 2017 at 3:43 AM, Julian Taylor wrote: > The version of gcc used will make a large difference in some places. > E.g. the AVX2 integer ufuncs require something around 4.5 to work and in > general the optimization level of gcc has improved greatly since the > clang competition showed

Re: [Numpy-discussion] [SciPy-Dev] NumPy 1.12.0 release

On Tue, Jan 17, 2017 at 3:47 PM, Neal Becker wrote: > Matthew Brett wrote: > >> Hi, >> >> On Tue, Jan 17, 2017 at 5:56 AM, Neal Becker wrote: >>> Charles R Harris wrote: >>> Hi All, I'm pleased to announce the NumPy 1.12.0 release. This release supports Python 2.7 and 3.4-3.6.

Re: [Numpy-discussion] Deprecating matrices.

On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers wrote: > > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris > wrote: >> >> >> >> On Fri, Jan 6, 2017 at 6:37 PM, wrote: >>> >>> >>> >>> >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers >>> wrote: On Sat, Jan 7, 2017 at 2:21 PM,

Re: [Numpy-discussion] numpy vs algebra Was: Integers to negative integer powers...

It's possible we should back off to just issuing a deprecation warning in 1.12? On Jan 3, 2017 1:47 PM, "Yaroslav Halchenko" wrote: > > On Tue, 03 Jan 2017, Stephan Hoyer wrote: > > >On Tue, Jan 3, 2017 at 9:00 AM, Yaroslav Halchenko < > li...@onerussian.com> > >wrote: > > > Sorry f

Re: [Numpy-discussion] Deprecating matrices.

On Mon, Jan 2, 2017 at 7:54 PM, Charles R Harris wrote: > > > On Mon, Jan 2, 2017 at 8:29 PM, Nathaniel Smith wrote: >> >> On Mon, Jan 2, 2017 at 7:12 PM, Charles R Harris >> wrote: >> > >> > >> > On Mon, Jan 2, 2017 at 7:26 PM, wrote: >

Re: [Numpy-discussion] Deprecating matrices.

On Mon, Jan 2, 2017 at 7:12 PM, Charles R Harris wrote: > > > On Mon, Jan 2, 2017 at 7:26 PM, wrote: [...] >> How about dropping python 2 support at the same time, then we can all be >> in a @ world. >> > > The "@" operator works with matrices already, what causes problems is the > combination o

Re: [Numpy-discussion] Deprecating matrices.

On Mon, Jan 2, 2017 at 6:26 PM, wrote: > > > On Mon, Jan 2, 2017 at 9:00 PM, Ralf Gommers wrote: >> >> >> >> On Tue, Jan 3, 2017 at 2:36 PM, Charles R Harris >> wrote: >>> >>> Hi All, >>> >>> Just throwing this click bait out for discussion. Now that the `@` >>> operator is available and things

Re: [Numpy-discussion] Default type for functions that accumulate integers

On Mon, Jan 2, 2017 at 6:27 PM, Charles R Harris wrote: > Hi All, > > Currently functions like trace use the C long type as the default > accumulator for integer types of lesser precision: > >> dtype : dtype, optional >> Determines the data-type of the returned array and of the accumulator >>

Re: [Numpy-discussion] PyPI source files.

On Sun, Dec 18, 2016 at 5:21 PM, Charles R Harris wrote: > Hi All, > > It seems that PyPI will only accept one source file at this time, e.g., > numpy-1.11.3.zip and numpy-1.11.3.tar.gz are considered duplicates. Does > anyone know if this is intentional or a bug on the PyPI end? It makes sense >

Re: [Numpy-discussion] PyPy wheels (was: NumPy 1.12.0b1 released)

On Nov 18, 2016 3:30 PM, "Ralf Gommers" wrote: > > > > On Sat, Nov 19, 2016 at 5:24 AM, Nathaniel Smith wrote: >> >> Another thing to think about is that 1.12 on pypy won't pass its test suite (though it's close), and we're not yet testing ne

Re: [Numpy-discussion] NumPy 1.12.0b1 released

On Nov 18, 2016 01:14, "Ralf Gommers" wrote: > > > > On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett wrote: >> >> Hi, >> >> On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus wrote: >> > Congrats to all on the release.Two questions: >> > >> > Is there a guide to building standard wheels for NumPy? >> >

Re: [Numpy-discussion] array comprehension

On Nov 4, 2016 10:32 AM, "Stephan Hoyer" wrote: > > On Fri, Nov 4, 2016 at 10:24 AM, Nathaniel Smith wrote: >> >> Are you sure fromiter doesn't make an intermediate list or equivalent? It has to collect all the values before it can know the shape or

Re: [Numpy-discussion] array comprehension

Are you sure fromiter doesn't make an intermediate list or equivalent? It has to collect all the values before it can know the shape or dtype of the array to put them in. On Nov 4, 2016 5:26 AM, "Francesc Alted" wrote: 2016-11-04 13:06 GMT+01:00 Neal Becker : > I find I often write: > np.arra

Re: [Numpy-discussion] Intel random number package

On Oct 27, 2016 8:42 AM, "Robert McLeod" wrote: > > Releasing NumPy under GPL would make it incompatible with SciPy, which may be _slightly_ inconvenient to the scientific Python community: > > https://scipy.github.io/old-wiki/pages/License_Compatibility.html > > https://mail.scipy.org/pipermail/s

Re: [Numpy-discussion] Intel random number package

On Wed, Oct 26, 2016 at 12:41 PM, Warren Weckesser wrote: > > > On Wed, Oct 26, 2016 at 3:24 PM, Nathaniel Smith wrote: >> >> On Wed, Oct 26, 2016 at 9:10 AM, Julian Taylor >> wrote: >> > On 10/26/2016 06:00 PM, Julian Taylor wrote: >> >>

Re: [Numpy-discussion] Numpy integers to integer powers again again

On Wed, Oct 26, 2016 at 12:23 PM, Charles R Harris wrote: [...] > What I have been concerned about are the follow combinations that currently > return floats > > num: , exp: , res: 'numpy.float32'> > num: , exp: , res: 'numpy.float32'> > num: , exp: , res: 'numpy.float32'> > num: , exp: , res:

Re: [Numpy-discussion] Intel random number package

On Wed, Oct 26, 2016 at 9:10 AM, Julian Taylor wrote: > On 10/26/2016 06:00 PM, Julian Taylor wrote: >> >> On 10/26/2016 10:59 AM, Ralf Gommers wrote: >>> >>> >>> >>> On Wed, Oct 26, 2016 at 8:33 PM, Julian Taylor >>> mailto:jtaylor.deb...@googlemail.com>> >>> wrote: >>> >>> On 26.10.2016 06:3

Re: [Numpy-discussion] Combining covariance and correlation coefficient into one numpy.cov call

On Wed, Oct 26, 2016 at 11:13 AM, Stephan Hoyer wrote: > On Wed, Oct 26, 2016 at 11:03 AM, Mathew S. Madhavacheril > wrote: >> >> On Wed, Oct 26, 2016 at 1:46 PM, Stephan Hoyer wrote: >>> >>> I wonder if the goals of this addition could be achieved by simply adding >>> an optional `cov` argument

Re: [Numpy-discussion] Preserving NumPy views when pickling

On Tue, Oct 25, 2016 at 5:09 PM, Matthew Harrigan wrote: > It seems pickle keeps track of references for basic python types. > > x = [1] > y = [x] > x,y = pickle.loads(pickle.dumps((x,y))) > x.append(2) > print(y) [[1,2]] Yes, but the problem is: suppose I have a 10 gigabyte array, and then

Re: [Numpy-discussion] Preserving NumPy views when pickling

On Tue, Oct 25, 2016 at 12:38 PM, Stephan Hoyer wrote: > With a custom wrapper class, it's possible to preserve NumPy views when > pickling: > https://stackoverflow.com/questions/13746601/preserving-numpy-view-when-pickling > > This can result in significant time/space savings with pickling views

Re: [Numpy-discussion] Numpy integers to integer powers again again

On Mon, Oct 24, 2016 at 3:41 PM, Charles R Harris wrote: > Hi All, > > I've been thinking about this some (a lot) more and have an alternate > proposal for the behavior of the `**` operator > > if both base and power are numpy/python scalar integers, convert to python > integers and call the `**`

Re: [Numpy-discussion] fpower ufunc

On Thu, Oct 20, 2016 at 7:58 PM, Charles R Harris wrote: > Hi All, > > I've put up a preliminary PR for the proposed fpower ufunc. Apart from > adding more tests and documentation, I'd like to settle a few other things. > The first is the name, two names have been proposed and we should settle on

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Sat, Oct 8, 2016 at 3:18 PM, Krisztián Horváth wrote: > > > >> but then that violates the numpy >> principle that output dtypes should be determined entirely by input >> dtypes, without peeking at the actual values. (And this rule is very >> important for avoiding nasty surprises when you run y

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Sat, Oct 8, 2016 at 1:40 PM, V. Armando Sole wrote: > Well, testing under windows 64 bit, Python 3.5.2, positive powers of > integers give integers and negative powers of integers give floats. So, do > you want to raise an exception when taking a negative power of an element of > an array of in

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Sat, Oct 8, 2016 at 6:59 AM, Charles R Harris wrote: > > > On Sat, Oct 8, 2016 at 4:40 AM, Nathaniel Smith wrote: >> >> On Fri, Oct 7, 2016 at 6:12 PM, Charles R Harris >> wrote: >> > Hi All, >> > >> > The time for NumPy 1.12.0 approache

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Fri, Oct 7, 2016 at 6:12 PM, Charles R Harris wrote: > Hi All, > > The time for NumPy 1.12.0 approaches and I like to have a final decision on > the treatment of integers to negative integer powers with the `**` operator. > The two alternatives looked to be > > Raise an error for arrays and num

Re: [Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

On Sep 7, 2016 9:03 AM, "Sebastian Berg" wrote: > > Hi all, > > Pauli just opened a nice pull request [1] to add overlap detection to > the new iterator, this means adding a new iterator flag: > > `NPY_ITER_COPY_IF_OVERLAP` > > If passed to the iterator (also exposed in python), the iterator will

Re: [Numpy-discussion] State-of-the-art to use a C/C++ library from Python

On Fri, Sep 2, 2016 at 1:16 AM, Peter Creasey wrote: >> Date: Wed, 31 Aug 2016 13:28:21 +0200 >> From: Michael Bieri >> >> I'm not quite sure which approach is state-of-the-art as of 2016. How would >> you do it if you had to make a C/C++ library available in Python right now? >> >> In my case, I

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

On Aug 21, 2016 10:46 AM, "Dipankar “Dipu” Ganguly" wrote: > > Is there a way to use Wolframs’ Mathematica 11 within IPython on Jupyter running on Anaconda’s Navigator on a Mac with OS 10.11.6? Failing that, what Python package would give me those capabilities? This has nothing to do with numpy,

Re: [Numpy-discussion] 1.11.1 install fails on RHEL 7.2 (IBM Power8) with Python 2.7.12

Can you post the complete output from pip? On Jul 14, 2016 2:06 PM, "Brian M Belgodere" wrote: > > > While attempting to install numpy on a Power8 (ppc) machine Running RHEL > 7.2 I'm encountering the following error below. Numpy 1.11.0 installs and > works fine. > pip install numpy==1.11.1 > ER

Re: [Numpy-discussion] Custom Dtype/Units discussion

bby after the lightning > talks? > > On Thu, Jul 14, 2016 at 10:49 AM, Ryan May wrote: > >> Fine with me. >> >> Ryan >> >> On Thu, Jul 14, 2016 at 12:48 AM, Nathaniel Smith wrote: >> >>> I have something at lunch, so dinner woul

Re: [Numpy-discussion] Custom Dtype/Units discussion

I have something at lunch, so dinner would be good for me too. On Jul 13, 2016 7:46 PM, "Charles R Harris" wrote: > Evening would work for me. Dinner? > On Jul 13, 2016 2:43 PM, "Ryan May" wrote: > >> On Mon, Jul 11, 2016 at 12:39 PM, Chris Barker >> wrote: >> >>> >>> >>> On Sun, Jul 10, 2016 a

Re: [Numpy-discussion] Custom Dtype/Units discussion

Hi Ryan, I'll be and SciPy and I'd love to talk about this :-). Things are a bit hectic for me on Mon/Tue/Wed between the Python Compilers Workshop and my talk, but do you want to meet up Thursday maybe? -n On Sat, Jul 9, 2016 at 6:44 PM, Ryan May wrote: > Greetings! > > I've been beating my he

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Wed, Jul 6, 2016 at 1:56 PM, Ralf Gommers wrote: > > > On Wed, Jul 6, 2016 at 6:26 PM, Nathaniel Smith wrote: > >> On Jul 5, 2016 11:21 PM, "Ralf Gommers" wrote: >> > >> > >> > >> > On Wed, Jul 6, 2016 at 7:06 AM, Nathan

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Jul 6, 2016 6:12 AM, "Joseph Fox-Rabinovitz" wrote: > > I can add a keyword-only argument that lets you put the new dims > before or after the existing ones. I am not sure how to specify > arbitrary patterns for the new dimensions, but that should take care > of most use cases. > > The use case

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Jul 5, 2016 11:21 PM, "Ralf Gommers" wrote: > > > > On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith wrote: > >> On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" wrote: >> > >> > Hi, >> > >> > I have generalized np.a

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" wrote: > > Hi, > > I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a > function np.atleast_nd in PR#7804 > (https://github.com/numpy/numpy/pull/7804). > > As a result of this PR, I have a couple of questions about > `np.atleast_3d

Re: [Numpy-discussion] Accelerate or OpenBLAS for numpy / scipy wheels?

On Jun 29, 2016 2:49 AM, "Andrew Jaffe" wrote: > > On 28/06/2016 18:50, Ralf Gommers wrote: >> >> >> On Tue, Jun 28, 2016 at 5:50 PM, Chris Barker > > wrote: >> >> > This doesn't really matter too much imho, we have to support Accelerate >> > either wa

Re: [Numpy-discussion] Is numpy.test() supposed to be multithreaded?

As a general rule I wouldn't worry too much about test speed. Speed is extremely dependent on exact workloads. And this is doubly so for test suites -- production workloads tend to do a small number of normal things over and over, while a good test suite never does the same thing twice and spends m

Re: [Numpy-discussion] Support of '@='?

To repeat and (hopefully) clarify/summarize the other answers: It's been left out on purpose so far. Why was it left out? A few reasons: - Usually in-place operations like "a += b" are preferred over the out-of-place equivalents like "a[...] = a + b" because they avoid some copies and potentiall

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Mon, Jun 20, 2016 at 3:09 PM, wrote: > On Mon, Jun 20, 2016 at 4:31 PM, Alan Isaac wrote: >> On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote: >>> >>> 1. What in principle is the best return type for int ** int (which >>> Josef I think most properly rephrased as whether `**` should be >>> thou

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Mon, Jun 20, 2016 at 2:11 PM, Alan Isaac wrote: > On 6/10/2016 8:28 PM, Allan Haldane wrote: >> >> My understanding is that numpy never upcasts based on the values, it >> upcasts based on the datatype ranges. >> >> http://docs.scipy.org/doc/numpy-1.10.1/reference/ufuncs.html#casting-rules > > >

Re: [Numpy-discussion] numpy threads crash when allocating arrays

On Jun 14, 2016 12:38 PM, "Burlen Loring" wrote: > > On 06/14/2016 12:28 PM, Julian Taylor wrote: >> >> On 14.06.2016 19:34, Burlen Loring wrote: >> >>> >>> here's my question: given Py_BEGIN_ALLOW_THREADS is used by numpy how >>> can numpy be thread safe? and how can someone using the C-API know

Re: [Numpy-discussion] numpy threads crash when allocating arrays

Hi Burlen, On Jun 13, 2016 5:24 PM, "Burlen Loring" wrote: > > Hi All, > > I'm working on a threaded pipeline where we want the end user to be able to > code up Python functions to do numerical work. Threading is all done in C++11 > and in each thread we've acquired gill before we invoke the us

[Numpy-discussion] Deprecating silent truncation of floats when assigned to int array

It was recently pointed out: https://github.com/numpy/numpy/issues/7730 that this code silently truncates floats: In [1]: a = np.arange(10) In [2]: a.dtype Out[2]: dtype('int64') In [3]: a[3] = 1.5 In [4]: a[3] Out[4]: 1 The proposal is that we should deprecate this, and eventually turn it

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Jun 13, 2016 10:54 AM, "Marten van Kerkwijk" wrote: > > Hi All, > > ​I think we're getting a little off the rails, perhaps because two questions are being conflated: > > 1. What in principle is the best return type for int ** int (which Josef I think most properly rephrased as whether `**` shou

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Jun 10, 2016 10:50, "Alan Isaac" wrote: > > On 6/10/2016 1:34 PM, Nathaniel Smith wrote: >> >> You keep pounding on this example. It's a fine example, but, c'mon. **2 is probably at least 100x more common in real source code. Maybe 1000x more common. Why

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Jun 10, 2016 05:11, "Alan Isaac" wrote: > > On 6/10/2016 2:42 AM, Nathaniel Smith wrote: >> >> I dunno, with my user hat on I'd be incredibly surprised / confused / >> annoyed if an innocent-looking expression like >> >> np.arange(10) ** 2

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris wrote: > > > > On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk > wrote: >> >> Hi Chuck, >> >> I consider either proposal an improvement, but among the two I favour >> returning float for `**`, because, like for `/`, it ensures one gets closes

Re: [Numpy-discussion] ENH: compute many inner products quickly

On Sun, Jun 5, 2016 at 5:41 PM, Stephan Hoyer wrote: > If possible, I'd love to add new functions for "generalized ufunc" linear > algebra, and then deprecate (or at least discourage) using the older > versions with inferior broadcasting rules. Adding a new keyword arg means > we'll be stuck with

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Jun 4, 2016 7:23 PM, "Charles R Harris" wrote: > [...] > We could always try the float option and see what breaks, but I expect there is a fair amount of code using small exponents like 2 or 3 where it is expected that the result is still integer. I would like more input from users than we have

Re: [Numpy-discussion] PyArray_Scalar should not use memcpy

On Jun 4, 2016 13:58, "Matti Picus" wrote: > > Hi. This is a heads up and RFC about a pull request I am preparing for PyArray_Scalar, within the framework of getting NumPy working properly on PyPy. For those who don't know, the numpy HEAD builds and runs on PyPy2.7 HEAD (otherwise known as nightly

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Sat, Jun 4, 2016 at 2:07 PM, V. Armando Sole wrote: > Also in favor of 2. Always return a float for '**' Even if we did want to switch to this, it's such a major backwards-incompatible change that I'm not sure how we could actually make the transition without first making it an error for a whi

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

+1 On Sat, Jun 4, 2016 at 10:22 AM, Charles R Harris wrote: > Hi All, > > I've made a new post so that we can make an explicit decision. AFAICT, the > two proposals are > > Integers to negative integer powers raise an error. > Integers to integer powers always results in floats. > > My own sense

Re: [Numpy-discussion] Changing FFT cache to a bounded LRU cache

On Jun 1, 2016 4:47 PM, "David Cournapeau" wrote: > > > > On Tue, May 31, 2016 at 10:36 PM, Sturla Molden wrote: >> >> Joseph Martinot-Lagarde wrote: >> >> > The problem with FFTW is that its license is more restrictive (GPL), and >> > because of this may not be suitable everywhere numpy.fft is.

Re: [Numpy-discussion] Integers to integer powers

On Tue, May 24, 2016 at 10:36 AM, Eric Moore wrote: > I'd say the most compelling case for it is that is how it has always worked. > How much code will break if we make that change? (Or if not break, at least > have a change in dtype?) Is that worth it? The current behavior for arrays is: # Ret

Re: [Numpy-discussion] A numpy based Entity-Component-System

On May 20, 2016 4:24 PM, "Elliot Hallmark" wrote: > > I have a Data Oriented programing library I'm writing that uses the Entity-Component-System model. > > https://github.com/Permafacture/data-oriented-pyglet > > I have initially called it Numpy-ECS but I don't know if that name is okay. The num

Re: [Numpy-discussion] Integers to integer powers

On May 20, 2016 12:44 PM, wrote: [...] > > can numpy cast to float by default for power or **? Maybe? The question is whether there are any valid use cases for getting ints back: >>> np.array([1, 2, 3]) ** 2 array([1, 4, 9]) It's not 100% obvious to me but intuitively this seems like an operati

Re: [Numpy-discussion] Integers to integer powers

On Fri, May 20, 2016 at 11:35 AM, Charles R Harris wrote: > > > On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote: >> >> So I guess what makes this tricky is that: >> >> - We want the behavior to the same for multiple-element arrays, >> single-eleme

Re: [Numpy-discussion] Integers to integer powers

So I guess what makes this tricky is that: - We want the behavior to the same for multiple-element arrays, single-element arrays, zero-dimensional arrays, and scalars -- the shape of the data shouldn't affect the semantics of ** - We also want the numpy scalar behavior to match the Python scalar

Re: [Numpy-discussion] Scipy 2016 attending

Me too. On Wed, May 18, 2016 at 3:02 PM, Chris Barker wrote: > I'll be there. > > -CHB > > > On Wed, May 18, 2016 at 2:09 PM, Charles R Harris > wrote: >> >> Hi All, >> >> Out of curiosity, who all here intends to be at Scipy 2016? >> >> Chuck >> >> __

Re: [Numpy-discussion] Proposal: numpy.random.random_seed

On Wed, May 18, 2016 at 5:07 AM, Robert Kern wrote: > On Wed, May 18, 2016 at 1:14 AM, Nathaniel Smith wrote: >> >> On Tue, May 17, 2016 at 10:41 AM, Robert Kern >> wrote: >> > On Tue, May 17, 2016 at 6:24 PM, Nathaniel Smith wrote: >> >> >>

Re: [Numpy-discussion] Proposal: numpy.random.random_seed

On Tue, May 17, 2016 at 10:41 AM, Robert Kern wrote: > On Tue, May 17, 2016 at 6:24 PM, Nathaniel Smith wrote: >> >> On May 17, 2016 1:50 AM, "Robert Kern" wrote: >> > >> [...] >> > What you want is a function that returns many RandomState

Re: [Numpy-discussion] Proposal: numpy.random.random_seed

On May 17, 2016 1:50 AM, "Robert Kern" wrote: > [...] > What you want is a function that returns many RandomState objects that are hopefully spread around the MT19937 space enough that they are essentially independent (in the absence of true jumpahead). The better implementation of such a function

Re: [Numpy-discussion] linux wheels coming soon

On Apr 17, 2016 10:47 AM, "Olivier Grisel" wrote: > > Thanks for the clarification, I read your original report too quickly. > > I wonder why the travis maintainers built Python 2.7 with a > non-standard unicode option. Because for some reason cpython's configure script (in the now somewhat ancie

Re: [Numpy-discussion] linux wheels coming soon

On Thu, Apr 14, 2016 at 1:22 PM, Matthew Brett wrote: > On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote: >> I have tried testing the wheels in a project that runs tests on Travis's >> Trusty infrastructure which. The wheels work great for python 3.5 and saves >> us several minuts of runtime.

Re: [Numpy-discussion] linux wheels coming soon

On Apr 14, 2016 11:11 AM, "Benjamin Root" wrote: > > Are we going to have to have documentation somewhere making it clear that the numpy wheel shouldn't be used in a conda environment? Not that I would expect this issue to come up all that often, but I could imagine a scenario where a non-scientis

Re: [Numpy-discussion] linux wheels coming soon

https://github.com/numpy/numpy/issues/7545 On Wed, Apr 13, 2016 at 3:38 PM, Nathaniel Smith wrote: > I can reproduce in self-compiled 1.9, so it's not a new bug. > > I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF, > where our special sigint handler is

Re: [Numpy-discussion] linux wheels coming soon

I can reproduce in self-compiled 1.9, so it's not a new bug. I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF, where our special sigint handler is getting left in place even after our code finishes running. Skimming the code, my best guess is that this is due to a race conditio

Re: [Numpy-discussion] Floor divison on int returns float

On Apr 13, 2016 9:08 AM, "Robert Kern" wrote: > > On Wed, Apr 13, 2016 at 3:17 AM, Antony Lee wrote: > > > > This kind of issue (see also https://github.com/numpy/numpy/issues/3511) > > has become more annoying now that indexing requires integers (indexing with > > a float raises a VisibleDepre

Re: [Numpy-discussion] linux wheels coming soon

Woot! \o/ On Wed, Apr 13, 2016 at 12:15 PM, Matthew Brett wrote: > On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett > wrote: > > Hi, > > > > On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett > wrote: > >> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock > wrote: > >>> On Fri, Mar 25, 2016 at 3:02 AM, Ro

Re: [Numpy-discussion] Floor divison on int returns float

So what type should uint64 + int64 return? On Apr 12, 2016 7:17 PM, "Antony Lee" wrote: > This kind of issue (see also https://github.com/numpy/numpy/issues/3511) > has become more annoying now that indexing requires integers (indexing with > a float raises a VisibleDeprecationWarning). The argu

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Fri, Apr 8, 2016 at 2:09 PM, Alan Isaac wrote: > On 4/8/2016 4:28 PM, Ian Henriksen wrote: >> >> The biggest things to me are having a broadcasting 2D transpose and having >> some >> form of transpose that doesn't silently pass 1D arrays through unchanged. > > > > This comment, like much of thi

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Thu, Apr 7, 2016 at 10:00 AM, Ian Henriksen wrote: > > Here's another example that I've seen catch people now and again. > > A = np.random.rand(100, 100) > b = np.random.rand(10) > A * b.T > > In this case the user pretty clearly meant to be broadcasting along the rows > of A > rather than alo

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Wed, Apr 6, 2016 at 10:43 AM, Todd wrote: > On Tue, Apr 5, 2016 at 11:14 PM, Nathaniel Smith wrote: >> >> On Tue, Apr 5, 2016 at 7:11 PM, Todd wrote: >> > When you try to transpose a 1D array, it does nothing. This is the >> > correct >> > be

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

On Apr 6, 2016 06:31, "Robert Kern" wrote: > > On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: > > > > I have C++ code that tries to share the mtrand state. It unfortunately > > depends on the layout of RandomState which used to be: > > > > struct __pyx_obj_6mtrand_RandomState { > > PyObjec

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

On Wed, Apr 6, 2016 at 2:04 AM, Olivier Grisel wrote: > 2016-04-05 19:44 GMT+02:00 Nathaniel Smith : >> >>> I propose to hold off distributing the OpenBLAS wheels until the >>> OpenBLAS tests are clean on the OpenBLAS buildbots - any objections? >> >> Alte

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Tue, Apr 5, 2016 at 7:11 PM, Todd wrote: > When you try to transpose a 1D array, it does nothing. This is the correct > behavior, since it transposing a 1D array is meaningless. However, this can > often lead to unexpected errors since this is rarely what you want. You can > convert the arra

Re: [Numpy-discussion] Multidimension array access in C via Python API

On Apr 5, 2016 9:39 AM, "mpc" wrote: > > This is the reason I'm doing this in the first place, because I made a pure > python version but it runs really slow for larger data sets, so I'm > basically rewriting the same function but using the Python and Numpy C API, > but if you're saying it won't r

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

On Apr 5, 2016 10:23 AM, "Matthew Brett" wrote: > > On Mon, Mar 28, 2016 at 2:33 PM, Matthew Brett wrote: > > Hi, > > > > Olivier Grisel and I are working on building and testing manylinux > > wheels for numpy and scipy. > > > > We first thought that we should use ATLAS BLAS, but Olivier found th

Re: [Numpy-discussion] Multidimension array access in C via Python API

On Apr 4, 2016 1:58 PM, "mpc" wrote: > > Thanks for responding. > > It looks you made/found these yourself since I can't find anything like this > in the API. I can't believe it isn't, so convenient! > > By the way, from what I understand, the ':' is represented as > *PySlice_New(NULL, NULL, NULL)

Re: [Numpy-discussion] Starting work on ufunc rewrite

On Thu, Mar 31, 2016 at 3:09 PM, Irwin Zaid wrote: > Hey guys, > > I figured I'd just chime in here. > > Over in DyND-town, we've spent a lot of time figuring out how to structure > DyND callables, which are actually more general than NumPy gufuncs. We've > just recently got them to a place where

Re: [Numpy-discussion] Starting work on ufunc rewrite

On Thu, Mar 31, 2016 at 1:00 PM, Jaime Fernández del Río wrote: > I have started discussing with Nathaniel the implementation of the ufunc ABI > break that he proposed in a draft NEP a few months ago: > > http://thread.gmane.org/gmane.comp.python.numeric.general/61270 > > His original proposal was

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

If OpenBLAS is looking like the easiest to support solution, then no objections here. (If 0.2.17 is genuinely working well, then maybe we want to switch to it on Windows too. I know Xianyi disabled some of the problematic kernels for us -- maybe that's enough. Mostly I just don't want to end up in

Re: [Numpy-discussion] linux wheels coming soon

On Thu, Mar 24, 2016 at 11:44 AM, Peter Cock wrote: > On Thu, Mar 24, 2016 at 6:37 PM, Nathaniel Smith wrote: >> On Mar 24, 2016 8:04 AM, "Peter Cock" wrote: >>> >>> Hi Nathaniel, >>> >>> Will you be providing portable Linux wheels aka m

Re: [Numpy-discussion] linux wheels coming soon

On Mar 24, 2016 8:04 AM, "Peter Cock" wrote: > > Hi Nathaniel, > > Will you be providing portable Linux wheels aka manylinux1? > https://www.python.org/dev/peps/pep-0513/ Matthew Brett will (probably) do the actual work, but yeah, that's the idea exactly. Note the author list on that PEP ;-) -n

[Numpy-discussion] [ANN/FYI] workshop on python compilers @ SciPy this year, with relevance to numpy

Hi numpy-discussion, Wanted to pass on this workshop announcement here, since one of the motivations for this was the realization that with PyPy and Pyston both actively working on getting numpy working, we'll probably soon have *three* JIT platforms actively attempting to write their own version

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

On Wed, Mar 16, 2016 at 12:48 PM, Travis Oliphant wrote: > > > On Wed, Mar 16, 2016 at 12:55 PM, Nathaniel Smith wrote: > >> Hi Travis, >> >> On Mar 16, 2016 9:52 AM, "Travis Oliphant" wrote: >> > >> > Hi everyone, >> > >

[Numpy-discussion] new API: nancumsum and nancumprod

Hi all, We have a pull request to add np.nancumsum and np.nancumprod: https://github.com/numpy/numpy/pull/7421 Seems pretty straightforward and uncontroversial to me, but our policy is to run new API by the mailing list, so speak up if you have some objection, or take a look at the PR if you

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

On Thu, Mar 17, 2016 at 2:04 PM, Feng Yu wrote: > Hi, > > ang2pix is used in astronomy to pixelize coordinate in forms of > (theta, phi). healpy is a binding of healpix > (http://healpix.sourceforge.net/, introduction there too), plus a lot > of more extra features or bloat (and I am not particula

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

On Mar 17, 2016 1:22 AM, "Feng Yu" wrote: > > Hi, > > Here is another example. > > To write pix2ang (and similar functions) to a ufunc, one may want to have implicit scalar broadcast on `nested` and `nsides` arguments. > > The function is described here: > > http://healpy.readthedocs.org/en/latest

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

On Wed, Mar 16, 2016 at 7:32 PM, Fernando Perez wrote: > On Wed, Mar 16, 2016 at 3:45 PM, Steve Waterbury > wrote: >> >> On 03/16/2016 06:28 PM, Nathaniel Smith wrote: >>> >>> ... Sounds like a real deprecation cycle would have been better. >> >&g

Re: [Numpy-discussion] Changes to generalized ufunc core dimension checking

Hi Travis, On Mar 16, 2016 9:52 AM, "Travis Oliphant" wrote: > > Hi everyone, > > Can you help me understand why the stricter changes to generalized ufunc argument checking no now longer allows scalars to be interpreted as 1-d arrays in the core-dimensions? > > Is there a way to specify in the co

  1   2   3   4   5   6   7   8   9   10   >