Re: [Numpy-discussion] Integers to integer powers

On Fri, May 20, 2016 at 6:54 PM, Nathaniel Smith wrote: > 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,

Re: [Numpy-discussion] Integers to integer powers

On Fri, May 20, 2016 at 4:27 PM, Warren Weckesser < warren.weckes...@gmail.com> wrote: > > > On Fri, May 20, 2016 at 4:22 PM, Alan Isaac wrote: > >> On 5/19/2016 11:30 PM, Nathaniel Smith wrote: >> >>> the last bad >>> option IMHO would be that we make int ** (negative int) an error in >>> all ca

Re: [Numpy-discussion] Integers to integer powers

On Fri, May 20, 2016 at 3:23 PM, Charles R Harris wrote: > > > On Fri, May 20, 2016 at 1:15 PM, Nathaniel Smith wrote: > >> 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

Re: [Numpy-discussion] Integers to integer powers

On Thu, May 19, 2016 at 10:16 PM, wrote: > > > On Thu, May 19, 2016 at 5:37 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> Hi All, >> >> There are currently several pull requests apropos integer arrays/scalars >> to integer powers and, because the area is messy and involves trade

Re: [Numpy-discussion] Integers to integer powers

On Thu, May 19, 2016 at 5:37 PM, Charles R Harris wrote: > Hi All, > > There are currently several pull requests apropos integer arrays/scalars > to integer powers and, because the area is messy and involves tradeoffs, > I'd like to see some discussion here on the list before proceeding. > > *Sca

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

On Wed, May 18, 2016 at 12:01 PM, Robert Kern wrote: > On Wed, May 18, 2016 at 4:50 PM, Chris Barker > wrote: > >> > >> > ...anyway, the real reason I'm a bit grumpy is because there are solid > >> > engineering reasons why users *want* this API, > > > > Honestly, I am lost in the math -- but li

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

On Tue, May 17, 2016 at 4:49 AM, Robert Kern wrote: > On Tue, May 17, 2016 at 9:09 AM, Stephan Hoyer wrote: > > > > On Tue, May 17, 2016 at 12:18 AM, Robert Kern > wrote: > >> > >> On Tue, May 17, 2016 at 4:54 AM, Stephan Hoyer > wrote: > >> > 1. When writing a library of stochastic functions

Re: [Numpy-discussion] Remove a random sample from array

On Mon, May 16, 2016 at 12:24 PM, Elliot Hallmark wrote: > Use `random.shuffle(range(len(arr))` to make a list of indices. Use a > slices to get your 20/80. Convert to integer arrays and index your > original array with them. Use sorted on the 80% list if you need to > preserve the order. > s

Re: [Numpy-discussion] three-way comparisons

On Sat, May 14, 2016 at 3:23 AM, Phillip Feldman < phillip.m.feld...@gmail.com> wrote: > I often find a need to do the type of comparison done by function shown > below. I suspect that this would be more efficient for large arrays if > implemented direction in C. Is there any possibility of addi

Re: [Numpy-discussion] Changing the behavior of (builtins.)round (via the __round__ dunder) to return an integer

On Wed, Apr 13, 2016 at 4:31 AM, Stephan Hoyer wrote: > On Wed, Apr 13, 2016 at 12:42 AM, Antony Lee > wrote: > >> (Note that I am suggesting to switch to the new behavior regardless of >> the version of Python.) >> > > I would lean towards making this change only for Python 3. This is > arguabl

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

On Fri, Apr 8, 2016 at 5:11 PM, Charles R Harris wrote: > > > On Fri, Apr 8, 2016 at 2:52 PM, wrote: > >> >> >> On Fri, Apr 8, 2016 at 3:55 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker >>> wrote: >>> On Fri, Apr 8,

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

On Fri, Apr 8, 2016 at 3:55 PM, Charles R Harris wrote: > > > On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker > wrote: > >> On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> Apropos column/row vectors, I've toyed a bit with the idea of adding a >>> flag

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

On Thu, Apr 7, 2016 at 4:07 PM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > On Thu, Apr 7, 2016 at 1:53 PM wrote: > >> On Thu, Apr 7, 2016 at 3:26 PM, Ian Henriksen < >> insertinterestingnameh...@gmail.com> wrote: >> >>> On Thu, Apr 7, 2016 at 12:31 PM wrote: >>> write uni

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

On Thu, Apr 7, 2016 at 3:26 PM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > On Thu, Apr 7, 2016 at 12:31 PM wrote: > >> write unit tests with non square 2d arrays and the exception / test error >> shows up fast. >> >> Josef >> >> > Absolutely, but good programming practices don'

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

On Thu, Apr 7, 2016 at 2:17 PM, Chris Barker wrote: > On Thu, Apr 7, 2016 at 10:00 AM, Ian Henriksen < > insertinterestingnameh...@gmail.com> 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 >> >

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

On Thu, Apr 7, 2016 at 1:35 PM, Sebastian Berg wrote: > On Do, 2016-04-07 at 13:29 -0400, josef.p...@gmail.com wrote: > > > > > > On Thu, Apr 7, 2016 at 1:20 PM, Sebastian Berg < > > sebast...@sipsolutions.net> wrote: > > > On Do, 2016-04-07 at 11:56 -0400, josef.p...@gmail.com wrote: > > > > > >

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

On Thu, Apr 7, 2016 at 1:20 PM, Sebastian Berg wrote: > On Do, 2016-04-07 at 11:56 -0400, josef.p...@gmail.com wrote: > > > > > > > > > > > I don't think numpy treats 1d arrays as row vectors. numpy has C > > -order for axis preference which coincides in many cases with row > > vector behavior.

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

On Thu, Apr 7, 2016 at 11:42 AM, Todd wrote: > On Thu, Apr 7, 2016 at 11:35 AM, wrote: >> >> On Thu, Apr 7, 2016 at 11:13 AM, Todd wrote: >> > On Wed, Apr 6, 2016 at 5:20 PM, Nathaniel Smith wrote: >> >> >> >> On Wed, Apr 6, 2016 at 10:43 AM, Todd wrote: >> >> > >> >> > My intention was to mak

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

On Thu, Apr 7, 2016 at 11:13 AM, Todd wrote: > On Wed, Apr 6, 2016 at 5:20 PM, Nathaniel Smith wrote: >> >> On Wed, Apr 6, 2016 at 10:43 AM, Todd wrote: >> > >> > My intention was to make linear algebra operations easier in numpy. >> > With >> > the @ operator available, it is now very easy to d

Re: [Numpy-discussion] Make np.bincount output same dtype as weights

On Sat, Mar 26, 2016 at 9:54 PM, Joseph Fox-Rabinovitz wrote: > Would it make sense to just make the output type large enough to hold the > cumulative sum of the weights? > > > - Joseph Fox-Rabinovitz > > -- Original message-- > > From: Jaime Fernández del Río > > Date: Sat, Mar 26, 2016 1

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

On Thu, Mar 17, 2016 at 1:08 AM, Steve Waterbury wrote: > On 03/16/2016 10:32 PM, Fernando Perez wrote: > >> On Wed, Mar 16, 2016 at 3:45 PM, Steve Waterbury >> mailto:water...@pangalactic.us>> wrote: >> >> On 03/16/2016 06:28 PM, Nathaniel Smith wrote: >> >> ... Sounds like a real de

Re: [Numpy-discussion] Windows wheels, built, but should we deploy?

On Fri, Mar 4, 2016 at 1:38 PM, Matthew Brett wrote: > On Fri, Mar 4, 2016 at 12:29 AM, David Cournapeau > wrote: > > > > > > On Fri, Mar 4, 2016 at 4:42 AM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> Summary: > >> > >> I propose that we upload Windows wheels to pypi. The wheels are > >>

Re: [Numpy-discussion] [Suggestion] Labelled Array

On Fri, Feb 19, 2016 at 12:08 PM, Allan Haldane wrote: > I also want to add a historical note here, that 'groupby' has been > discussed a couple times before. > > Travis Oliphant even made an NEP for it, and Wes McKinney lightly hinted > at adding it to numpy. > > http://thread.gmane.org/gmane.co

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

On Thu, Feb 18, 2016 at 1:15 PM, Antony Lee wrote: > Mostly so that there is no performance lost when someone passes range(...) > instead of np.arange(...). At least I had never realized that one is much > faster than the other and always just passed range() as a convenience. > > Antony > > 2016

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 7:17 PM, Juan Nunez-Iglesias wrote: > Ah! Touché! =) My last and admittedly weak defense is that I've been > writing numpy since before 1.7. =) > > On Thu, Feb 18, 2016 at 11:08 AM, Alan Isaac wrote: > >> On 2/17/2016 7:01 PM, Juan Nunez-Iglesias wrote: >> >>> Notice the

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 3:58 PM, G Young wrote: > I sense that this issue is now becoming more of "randint has become too > complicated" I suppose we could always "add" more functions that present > simpler interfaces, though if you really do want simple, there's always > Python's random library

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 2:20 PM, wrote: > > > On Wed, Feb 17, 2016 at 2:09 PM, G Young wrote: > >> Yes, you are correct in explaining my intentions. However, as I also >> mentioned in the PR discussion, I did not quite understand how your wrapper >> idea would make things any more comprehensive

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 2:09 PM, G Young wrote: > Yes, you are correct in explaining my intentions. However, as I also > mentioned in the PR discussion, I did not quite understand how your wrapper > idea would make things any more comprehensive at the cost of additional > overhead and complexity

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Wed, Feb 17, 2016 at 10:01 AM, G Young wrote: > Hello all, > > I have a PR open here that > makes "low" an optional parameter in numpy.randint and introduces new > behavior into the API as follows: > > 1) `low == None` and `high == None` > > Numbers a

Re: [Numpy-discussion] Proposal to add `weights` to `np.percentile` and `np.median`

On Tue, Feb 16, 2016 at 2:48 PM, Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > Please correct me if I misunderstood, but the code in that commit is > doing a full sort, somewhat similar to what > `scipy.stats.scoreatpercentile`. If that is correct, I will run some > benchmarks first,

Re: [Numpy-discussion] Proposal to add `weights` to `np.percentile` and `np.median`

On Tue, Feb 16, 2016 at 1:41 PM, Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > Thanks for pointing me to that. I had something a bit different in > mind but that definitely looks like a good start. > > On Tue, Feb 16, 2016 at 1:32 PM, Antony Lee > wrote: > > See earlier discussion he

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Tue, Feb 16, 2016 at 12:09 AM, wrote: > > > On Mon, Feb 15, 2016 at 11:31 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Mon, Feb 15, 2016 at 9:15 PM, wrote: >> >>> >>> >>> On Mon, Feb 15, 2016 at 11:05 PM, Charles R Harris < >>> charlesr.har...@gmail.com> wrote: >>>

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Mon, Feb 15, 2016 at 11:31 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Mon, Feb 15, 2016 at 9:15 PM, wrote: > >> >> >> On Mon, Feb 15, 2016 at 11:05 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Mon, Feb 15, 2016 at 8:50 PM, wrote: >>> >>>

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Mon, Feb 15, 2016 at 11:05 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Mon, Feb 15, 2016 at 8:50 PM, wrote: > >> >> >> On Mon, Feb 15, 2016 at 10:46 PM, wrote: >> >> >>> >>> On Fri, Feb 12, 2016 at 4:19 PM, Nathan Goldbaum >>> wrote: >>> https://github.com/numpy/nu

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Mon, Feb 15, 2016 at 10:46 PM, wrote: > > > On Fri, Feb 12, 2016 at 4:19 PM, Nathan Goldbaum > wrote: > >> https://github.com/numpy/numpy/blob/master/doc/release/1.11.0-notes.rst >> >> On Fri, Feb 12, 2016 at 3:17 PM, Andreas Mueller >> wrote: >> >>> Hi. >>> Where can I find the changelog? >

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

On Sun, Feb 14, 2016 at 3:21 AM, Antony Lee wrote: > re: no reason why... > This has nothing to do with Python2/Python3 (I personally stopped using > Python2 at least 3 years ago.) Let me put it this way instead: if > Python3's "range" (or Python2's "xrange") was not a builtin type but a type >

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

On Sat, Feb 13, 2016 at 9:43 PM, wrote: > > > On Sat, Feb 13, 2016 at 8:57 PM, Antony Lee > wrote: > >> Compare (on Python3 -- for Python2, read "xrange" instead of "range"): >> >> In [2]: %timeit np.array(range(100), np.int64) >> 10 loops, best of 3: 156 ms per loop >> >> In [3]: %timeit np

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

On Sat, Feb 13, 2016 at 8:57 PM, Antony Lee wrote: > Compare (on Python3 -- for Python2, read "xrange" instead of "range"): > > In [2]: %timeit np.array(range(100), np.int64) > 10 loops, best of 3: 156 ms per loop > > In [3]: %timeit np.arange(100, dtype=np.int64) > 1000 loops, best of 3:

Re: [Numpy-discussion] ANN: numpydoc 0.6.0 released

On Sat, Feb 13, 2016 at 10:03 AM, Ralf Gommers wrote: > Hi all, > > I'm pleased to announce the release of numpydoc 0.6.0. The main new > feature is support for the Yields section in numpy-style docstrings. This > is described in > https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst

Re: [Numpy-discussion] [Suggestion] Labelled Array

On Sat, Feb 13, 2016 at 1:42 PM, Jeff Reback wrote: > These operations get slower as the number of groups increase, but with a > faster function (e.g. the standard ones which are cythonized), the > constant on > the increase is pretty low. > > In [23]: c = np.random.randint(0,1,size=10) >

Re: [Numpy-discussion] [Suggestion] Labelled Array

On Sat, Feb 13, 2016 at 1:01 PM, Allan Haldane wrote: > Sorry, to reply to myself here, but looking at it with fresh eyes maybe > the performance of the naive version isn't too bad. Here's a comparison of > the naive vs a better implementation: > > def split_classes_naive(c, v): > return [v[c

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Wed, Feb 10, 2016 at 5:36 PM, Charles R Harris wrote: > > > On Wed, Feb 10, 2016 at 2:58 PM, Pauli Virtanen wrote: > >> 10.02.2016, 04:09, Charles R Harris kirjoitti: >> > I'm pleased to announce the release of NumPy 1.11.0b3. This beta >> contains >> [clip] >> > Please test, hopefully this w

Re: [Numpy-discussion] Numpy 1.11.0b2 released

On Fri, Feb 5, 2016 at 3:24 PM, wrote: > > > On Fri, Feb 5, 2016 at 1:14 PM, Pauli Virtanen wrote: > >> 05.02.2016, 19:55, Nathaniel Smith kirjoitti: >> > On Feb 5, 2016 8:28 AM, "Chris Barker - NOAA Federal" < >> chris.bar...@noaa.gov> >> > wrote: >> >> >> >>> An extra ~2 hours of tests / 6-way

Re: [Numpy-discussion] Behavior of np.random.uniform

On Tue, Jan 19, 2016 at 12:43 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern > wrote: > >> On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> > >> > On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern

Re: [Numpy-discussion] Numpy 1.10.3 release.

On Sun, Jan 3, 2016 at 12:05 AM, wrote: > On Sat, Jan 2, 2016 at 4:47 PM, Charles R Harris > wrote: >> Hi All, >> >> A significant segfault problem has been reported against Numpy 1.10.2 and I >> want to make a quick 1.10.3 release to get it fixed. Two questions >> >> What exactly is the release

Re: [Numpy-discussion] Numpy 1.10.3 release.

On Sat, Jan 2, 2016 at 4:47 PM, Charles R Harris wrote: > Hi All, > > A significant segfault problem has been reported against Numpy 1.10.2 and I > want to make a quick 1.10.3 release to get it fixed. Two questions > > What exactly is the release process that has been decided on? AFAIK, I > should

Re: [Numpy-discussion] Fast vectorized arithmetic with ~32 significant digits under Numpy

On Fri, Dec 11, 2015 at 11:22 AM, Anne Archibald wrote: > Actually, GCC implements 128-bit floats in software and provides them as > __float128; there are also quad-precision versions of the usual functions. > The Intel compiler provides this as well, I think, but I don't think > Microsoft compile

Re: [Numpy-discussion] ENH: Add the function 'expand_view'

On Tue, Nov 24, 2015 at 7:13 PM, Nathaniel Smith wrote: > On Nov 24, 2015 11:57 AM, "John Kirkham" wrote: > > > > Takes an array and tacks on arbitrary dimensions on either side, which > is returned as a view always. Here are the relevant features: > > > > * Creates a view of the array that has

Re: [Numpy-discussion] asarray(sparse) -> object

On Fri, Nov 20, 2015 at 6:29 PM, CJ Carey wrote: > The short answer is: "kind of". > > These two Github issues explain what's going on more in-depth: > https://github.com/scipy/scipy/issues/3995 > https://github.com/scipy/scipy/issues/4239 > Thanks, I didn't pay attention to those issues, or on

[Numpy-discussion] asarray(sparse) -> object

Is this intentional? >>> exog <50x5 sparse matrix of type '' with 50 stored elements in Compressed Sparse Column format> >>> np.asarray(exog) array(<50x5 sparse matrix of type '' with 50 stored elements in Compressed Sparse Column format>, dtype=object) I'm just a newbie who thought to use the

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Tue, Oct 27, 2015 at 10:59 AM, Nathaniel Smith wrote: > On Oct 27, 2015 6:08 AM, wrote: > > > [...] > > > > > > What's the equivalent of > > python setup.py build_ext --inplace > > It's > python setup.py build_ext --inplace > > ;-) > Ok, Sorry, I read now the small print and the issue. S

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Tue, Oct 27, 2015 at 3:32 AM, Ralf Gommers wrote: > > > On Tue, Oct 27, 2015 at 8:28 AM, Nathaniel Smith wrote: > >> On Tue, Oct 27, 2015 at 12:19 AM, Ralf Gommers >> wrote: >> > >> > >> > On Tue, Oct 27, 2015 at 6:44 AM, Nathaniel Smith wrote: >> >> >> >> On Mon, Oct 26, 2015 at 9:31 PM, N

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:51 PM, wrote: > > > On Mon, Oct 19, 2015 at 9:15 PM, Nathaniel Smith wrote: > >> On Mon, Oct 19, 2015 at 5:55 AM, wrote: >> > >> > >> > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: >> >> >> >> On Sun, Oct 18, 2015 at 9:35 PM, wrote: >> >> np.column_

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 9:31 PM, Allan Haldane wrote: > On 10/16/2015 09:17 PM, josef.p...@gmail.com wrote: > >> >> >> On Fri, Oct 16, 2015 at 8:56 PM, Allan Haldane > > wrote: >> >> On 10/16/2015 05:31 PM, josef.p...@gmail.com >>

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:15 PM, Nathaniel Smith wrote: > On Mon, Oct 19, 2015 at 5:55 AM, wrote: > > > > > > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > >> > >> On Sun, Oct 18, 2015 at 9:35 PM, wrote: > >> np.column_stack((np.ones(10), np.ones(10))).flags > >> > C_CONTI

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:00 AM, wrote: > > > On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > >> On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: >> > >> >> >> >> >> > >> > It looks like in 1.9 it depends on the order of the 2-d arrays, which

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg wrote: > On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: > > > > > > > > > > It looks like in 1.9 it depends on the order of the 2-d arrays, which > > it didn't do in 1.6 > > > > Yes, it uses concatenate, and concatenate probably chan

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > On Sun, Oct 18, 2015 at 9:35 PM, wrote: > np.column_stack((np.ones(10), np.ones(10))).flags > > C_CONTIGUOUS : True > > F_CONTIGUOUS : False > > > np.__version__ > > '1.9.2rc1' > > > > > > on my notebook which has numpy 1.6

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 1:27 AM, wrote: > > > On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > >> Looking at the git logs, column_stack appears to have been that way >> (creating a new array with concatenate) since at least NumPy 0.9.2, way >> back in January 2006: >> https://github.com/n

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > Looking at the git logs, column_stack appears to have been that way > (creating a new array with concatenate) since at least NumPy 0.9.2, way > back in January 2006: > https://github.com/numpy/numpy/blob/v0.9.2/numpy/lib/shape_base.py#L271 >

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 12:35 AM, wrote: > >>> np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : True > F_CONTIGUOUS : False > > >>> np.__version__ > '1.9.2rc1' > > > on my notebook which has numpy 1.6.1 it is f_contiguous > > > I was just trying to optimize a loop over varia

[Numpy-discussion] when did column_stack become C-contiguous?

>>> np.column_stack((np.ones(10), np.ones(10))).flags C_CONTIGUOUS : True F_CONTIGUOUS : False >>> np.__version__ '1.9.2rc1' on my notebook which has numpy 1.6.1 it is f_contiguous I was just trying to optimize a loop over variable adjustment in regression, and found out that we lost fortr

Re: [Numpy-discussion] Interesting discussion on copyrighting files.

On Thu, Oct 15, 2015 at 11:28 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Worth a read at A&D . > Thanks, it is worth a read. Most of the time when I see code copied from scipy or statsmodels, it is properly attributed. But every once in a

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 8:56 PM, Allan Haldane wrote: > On 10/16/2015 05:31 PM, josef.p...@gmail.com wrote: > > > > > > On Fri, Oct 16, 2015 at 2:21 PM, Charles R Harris > > mailto:charlesr.har...@gmail.com>> wrote: > > > > > > > > On Fri, Oct 16, 2015 at 12:20 PM, Charles R Harris > > ma

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 2:21 PM, Charles R Harris wrote: > > > On Fri, Oct 16, 2015 at 12:20 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Oct 16, 2015 at 11:58 AM, wrote: >> >>> was there a change with reduce operations with recarrays in 1.10 or >>> 1.10.1? >>> >

[Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

was there a change with reduce operations with recarrays in 1.10 or 1.10.1? Travis shows a new test failure in the statsmodels testsuite with 1.10.1: ERROR: test suite for File "/home/travis/miniconda/envs/statsmodels-test/lib/python2.7/site-packages/statsmodels-0.8.0-py2.7-linux-x86_64.egg/s

Re: [Numpy-discussion] Bug

Sorry, wrong shortcut key, question will arrive later. Josef On Fri, Oct 16, 2015 at 1:40 PM, wrote: > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Bug

___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

On Thu, Oct 8, 2015 at 8:39 PM, Charles R Harris wrote: > > > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett > wrote: > >> Hi, >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. >> Using twine to do the upload generated a new release - 1.10.0.post2 - >> containing only the w

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 2:16 PM, Nathaniel Smith wrote: > On Sep 29, 2015 8:25 AM, "Anne Archibald" wrote: > > > > IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point arrays. > Why should it be different for object arrays? > > The argument for doing it this way would be that arbitra

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 11:25 AM, Anne Archibald wrote: > IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point arrays. > Why should it be different for object arrays? > > Anne > > P.S. If you want exceptions when NaNs appear, that's what np.seterr is > for. -A > I also think NaN sho

Re: [Numpy-discussion] Governance model request

On Tue, Sep 22, 2015 at 10:55 PM, Bryan Van de Ven wrote: > > > On Sep 22, 2015, at 1:48 PM, Matthew Brett > wrote: > > > > The point is, that a sensible organization and a sensible leader has > > to take the possibility of conflict of interest into account. They > > also have to consider the p

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Fri, Sep 4, 2015 at 7:19 PM, Matthew Brett wrote: > On Sat, Sep 5, 2015 at 12:04 AM, wrote: > > > > > > On Fri, Sep 4, 2015 at 5:55 PM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Fri, Sep 4, 2015 at 10:22 PM, Eric Firing > wrote: > >> > On 2015/09/04 10:53 AM, Matthew Brett wrote:

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Fri, Sep 4, 2015 at 5:55 PM, Matthew Brett wrote: > Hi, > > On Fri, Sep 4, 2015 at 10:22 PM, Eric Firing wrote: > > On 2015/09/04 10:53 AM, Matthew Brett wrote: > >> On Fri, Sep 4, 2015 at 2:33 AM, Matthew Brett > wrote: > >>> Hi, > >>> > >>> On Wed, Sep 2, 2015 at 5:41 PM, Chris Barker > w

[Numpy-discussion] meshgrid dtype casting

I'm trying to build a meshgrid with small nonnegative integers default is int32 >>> np.meshgrid([0,1,2], [0,1])[0].dtype dtype('int32') If I use uint, then the arrays are upcast to int64 - Why? >>> np.meshgrid(np.array([0,1,2], np.uint), np.array([0,1], np.uint))[0].dtype dtype('int64') broad

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 2:06 PM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 6:23 PM, wrote: > > > > > > On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett > > > wrote: > >> > >> Hi > >> > >> On Thu, Aug 27, 2015 at 5:11 PM, wrote: > >> > > >> > > >> > On Thu, Aug 27, 2015 at 11:04 A

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett wrote: > Hi > > On Thu, Aug 27, 2015 at 5:11 PM, wrote: > > > > > > On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett > > > wrote: > >> > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 3:34 PM, wrote: > >> [snip] > >> > I don't really see a problem wit

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 3:34 PM, wrote: > [snip] > > I don't really see a problem with "codifying" the status quo. > > That's an excellent point.If we believe that the current situation > is the best possible, both now and in

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

On Wed, Aug 26, 2015 at 10:06 AM, Travis Oliphant wrote: > > > On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith wrote: > >> Hi Travis, >> >> Thanks for taking the time to write up your thoughts! >> >> I have many thoughts in return, but I will try to restrict myself to two >> main ones :-). >> >

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 8:57 AM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 12:11 PM, Sebastian Berg > wrote: > > On Do, 2015-08-27 at 10:45 +0100, Matthew Brett wrote: > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 10:35 AM, Bryan Van de Ven > wrote: > >> > > >> >> On Aug 27, 2015, at

Re: [Numpy-discussion] np.in1d() & sets, bug?

On Mon, Aug 10, 2015 at 1:40 PM, Benjamin Root wrote: > > Not really, it is "simply" because ``np.asarray(set([1, 2, 3]))`` > > returns an object array > > Holy crap! To be pedantic, it looks like it turns it into a numpy scalar, > but still! I wouldn't have expected np.asarray() on a set (or dic

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > > > > well, IIUC, np.int is the python integer type, which > is > > > a C long in all the implemtations of cPython that I k

Re: [Numpy-discussion] difference between dtypes

On Fri, Jul 24, 2015 at 3:46 AM, Robert Kern wrote: > On Wed, Jul 22, 2015 at 7:45 PM, wrote: > > > > Is there an explanation somewhere of what different basic dtypes mean, > across platforms and python versions? > > > > >>> np.bool8 > > > > >>> np.bool_ > > > > >>> bool > > > > > > > > Are t

[Numpy-discussion] difference between dtypes

Is there an explanation somewhere of what different basic dtypes mean, across platforms and python versions? >>> np.bool8 >>> np.bool_ >>> bool Are there any rules and recommendations or is it all folks lore? I'm asking because my intuition picked up by osmosis might be off, and I thought h

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

On Thu, Jul 2, 2015 at 8:51 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Sent from my iPhone > > > > > The disadvantage I see is, that some weirder calculations would possible > > work most of the times, but not always, > > > > not sure if you can define a "tolerance" > > rea

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

On Wed, Jul 1, 2015 at 10:32 AM, Sebastian Berg wrote: > On Mi, 2015-07-01 at 10:05 -0400, josef.p...@gmail.com wrote: > > About the deprecation warning for using another type than integers, in > > ones, reshape, indexing and so on: > > > > > > Wouldn't it be nicer to accept floats that are equal

[Numpy-discussion] floats for indexing, reshape - too strict ?

About the deprecation warning for using another type than integers, in ones, reshape, indexing and so on: Wouldn't it be nicer to accept floats that are equal to an integer? for example >>> 5.0 == 5 True >>> np.ones(10 / 2) array([ 1., 1., 1., 1., 1.]) >>> 10 / 2 == 5 True or the python 2

[Numpy-discussion] annoying Deprecation warnings about non-integers

I'm trying to fix some code in statsmodels that creates Deprecation Warnings from numpy Most of it are quite easy to fix, mainly cases where we use floats to avoid integer division I have two problems first, I get Deprecation warnings in the test run that don't specify where they happen. I try t

Re: [Numpy-discussion] Python 3 and isinstance(np.int64(42), int)

On Fri, Jun 19, 2015 at 4:15 PM, Chris Barker wrote: > On Wed, Jun 17, 2015 at 11:13 PM, Nathaniel Smith wrote: > >> there's some >> argument that in Python, doing explicit type checks like this is >> usually a sign that one is doing something awkward, > > > I tend to agree with that. > > On th

Re: [Numpy-discussion] Clarification sought on Scipy Numpy version requirements.

On Fri, Jun 19, 2015 at 4:08 PM, Charles R Harris wrote: > Hi All, > > I'm looking to change some numpy deprecations into errors as well as > remove some deprecated functions. The problem I see is that > SciPy claims to support Numpy >= 1.5 and Numpy 1.5 is really, really, old. > So the question

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fri, Jun 5, 2015 at 11:50 AM, Anne Archibald wrote: > > > On Fri, Jun 5, 2015 at 5:45 PM Sebastian Berg > wrote: > >> On Fr, 2015-06-05 at 08:36 -0400, josef.p...@gmail.com wrote: >> > >> >> > >> > What is actually being deprecated? >> > It looks like there are different examples. >> > >> >

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fri, Jun 5, 2015 at 3:16 AM, Sebastian Berg wrote: > On Do, 2015-06-04 at 18:04 -0700, Nathaniel Smith wrote: > > On Thu, Jun 4, 2015 at 5:57 PM, Nathaniel Smith wrote: > > > So specifically the question is -- if you have an array with five > > items, and > > > a Boolean array with three item

[Numpy-discussion] checking S versus U dtype

What's the best way to check whether a numpy array is string or bytes on python3? using char? >>> A = np.asarray([[1, 0, 0],['E', 1, 0],['E', 'E', 1]], dtype='>> A array([['1', '0', '0'], ['E', '1', '0'], ['E', 'E', '1']], dtype='>> A.dtype dtype('>> A.dtype.char 'U' >>> A.dt

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 5:09 PM, Antony Lee wrote: > 2015-05-24 13:30 GMT-07:00 Sturla Molden : > >> On 24/05/15 10:22, Antony Lee wrote: >> >> > Comments, and help for writing tests (in particular to make sure >> > backwards compatibility is maintained) are welcome. >> >> I have one comment, and

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 1:49 PM, Nathaniel Smith wrote: > On May 24, 2015 8:43 AM, wrote: > > > > Reminder: we are bottom or inline posting > > Can we stop hassling people about this? Inline replies are a great tool to > have in your toolkit for complicated technical discussions, but I feel like

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 11:13 AM, Anne Archibald wrote: > Do we want a deprecation-like approach, so that eventually people who want > replicability will specify versions, and everyone else gets bug fixes and > improvements? This would presumably take several major versions, but it > might avoid

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac wrote: > On 5/24/2015 8:47 AM, Ralf Gommers wrote: > > Values only change if you leave out the call to seed() > > > OK, but this claim seems to conflict with the following language: > "the global RandomState object should use the latest implementation

Re: [Numpy-discussion] binary wheels for numpy?

On Fri, May 15, 2015 at 4:07 PM, Chris Barker wrote: > Hi folks., > > I did a little "intro to scipy" session as part of a larger Python class > the other day, and was dismayed to find that "pip install numpy" still > dosn't work on Windows. > > Thanks mostly to Matthew Brett's work, the whole sc

Re: [Numpy-discussion] code snippet: assert all close or large

Sorry, hit the wrong key just an example that I think is not covered by numpy.testing assert absolute tolerance for `inf`: "assert x and y are allclose or x is large if y is inf" On Thu, Apr 30, 2015 at 2:24 PM, wrote: > > > def assert_allclose_large(x, y, rtol=1e-6, atol=0, ltol=1e30): "

[Numpy-discussion] code snippet: assert all close or large

___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

  1   2   >