[Numpy-discussion] Requesting a PR review for #5822

https://github.com/numpy/numpy/pull/5822 is a year-old PR which allows many random distributions to have a scale of exactly 0 (in which case a stream of zeros is returned of whatever constant value is appropriate). It passes all tests and has been sitting there for a while. Would a core dev be

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

https://github.com/numpy/numpy/issues/3511 proposed (nearly three years ago) to return an integer when `builtins.round` (which calls the `__round__ dunder method, and thereafter called `round` (... not to be confused with `np.round`)) is called with a single argument. Currently, `round` returns a

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

(2**62-1)) would actually fit in an int64 (or an uint64), so arguably the conversion to float makes things worse. Antony 2016-04-12 19:56 GMT-07:00 Nathaniel Smith <n...@pobox.com>: > So what type should uint64 + int64 return? > On Apr 12, 2016 7:17 PM, "Antony Lee" <anton

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

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 argument "dividing an uint by an int may give a result that does not fit in an uint nor in an int"

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

016 at 10:15 AM, Antony Lee <antony@berkeley.edu> > 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 r

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

gov>: > On Sun, Feb 14, 2016 at 11:41 PM, Antony Lee <antony@berkeley.edu> > wrote: > >> So how can np.array(range(...)) even work? >> > > range() (in py3) is not a generator, nor is is a iterator. it is a range > object, which is lazily evaluated

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

Actually, while working on https://github.com/numpy/numpy/issues/7264 I realized that the memory efficiency (one-pass) argument is simply incorrect: import numpy as np class A: def __getitem__(self, i): print("A get item", i) return [np.int8(1), np.int8(2)][i] def

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

See earlier discussion here: https://github.com/numpy/numpy/issues/6326 Basically, naïvely sorting may be faster than a not-so-optimized version of quickselect. Antony 2016-02-15 21:49 GMT-08:00 Joseph Fox-Rabinovitz : > I would like to add a `weights` keyword to

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

rray(C()) Fatal Python error: Segmentation fault 2016-02-15 0:10 GMT-08:00 Nathaniel Smith <n...@pobox.com>: > On Sun, Feb 14, 2016 at 11:41 PM, Antony Lee <antony@berkeley.edu> > wrote: > > I wonder whether numpy is using the "old" iteration protocol (repe

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

gmail.com> >> wrote: >> >>> >>> >>> On Sun, Feb 14, 2016 at 9:21 AM, Antony Lee <antony@berkeley.edu> >>> wrote: >>> >>>> re: no reason why... >>>> This has nothing to do with Python2/Python3 (I personall

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

I was thinking (1) (special-case range()); however (2) may be more generally applicable and useful. Antony 2016-02-14 6:36 GMT-08:00 Ralf Gommers <ralf.gomm...@gmail.com>: > > > On Sun, Feb 14, 2016 at 9:21 AM, Antony Lee <antony@berkeley.edu> > wrote: > >>

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

t; wrote: > >> >> >> On Sat, Feb 13, 2016 at 8:57 PM, Antony Lee <antony@berkeley.edu> >> wrote: >> >>> Compare (on Python3 -- for Python2, read "xrange" instead of "range"): >>> >>> In [2]: %timeit np.arr

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

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: 853 µs per loop Note that while iterating over a range is not

[Numpy-discussion] Fixing the dtype of np.full's return value

Hi all, The docstring of np.full indicates that the result of the dtype is `np.array(fill_value).dtype`, as long as the keyword argument `dtype` itself is not set. This is actually not the case: the current implementation always returns a float array when `dtype` is not set, see e.g. In [1]:

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

2015-05-29 14:06 GMT-07:00 Antony Lee antony@berkeley.edu: A proof-of-concept implementation, still missing tests, is tracked as #5911. It includes the patch proposed in #5158 as an example of how to include an improved version of random.choice. Tests are in now (whether we should

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

A proof-of-concept implementation, still missing tests, is tracked as #5911. It includes the patch proposed in #5158 as an example of how to include an improved version of random.choice. Tests are in now (whether we should bundle in pickles of old versions to make sure they are still

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

Thanks to Nathaniel who has indeed clarified my intent, i.e. the global RandomState should use the latest implementation, unless explicitly seeded. More generally, the `RandomState` constructor is just a thin wrapper around `seed` with the same signature, so one can swap the version of the global

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

2015-05-24 13:30 GMT-07:00 Sturla Molden sturla.mol...@gmail.com: 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 that is what makes random numbers so special

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

backwards compatibility is maintained) are welcome. Antony Lee ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Automatic number of bins for numpy histograms

Another improvement would be to make sure, for integer-valued datasets, that all bins cover the same number of integer, as it is easy to end up otherwise with bins effectively wider than others: hist(np.random.randint(11, size=1)) shows a peak in the last bin, as it covers both 9 and 10.

Re: [Numpy-discussion] edge-cases of ellipsis indexing

I see, thanks! 2015-01-05 2:14 GMT-07:00 Sebastian Berg sebast...@sipsolutions.net: On Mo, 2015-01-05 at 14:13 +0530, Maniteja Nandana wrote: Hi Anthony, I am not sure whether the following section in documentation is relevant to the behavior you were referring to. When an

[Numpy-discussion] edge-cases of ellipsis indexing

While trying to reproduce various fancy indexings for astropy's FITS sections (a loaded-on-demand array), I found the following interesting behavior: np.array([1])[..., 0] array(1) np.array([1])[0] 1 np.array([1])[(0,)] 1 The docs say Ellipsis expand to the number of : objects needed to make

Re: [Numpy-discussion] truthiness of object arrays

On Python3, __nonzero__ is never defined (always raises an AttributeError), even after calling __bool__. 2014-11-13 5:24 GMT-08:00 Alan G Isaac alan.is...@gmail.com: On 11/13/2014 1:19 AM, Antony Lee wrote: t.__bool__() also returns True But t.__nonzero__() is being called in the `if` test

Re: [Numpy-discussion] truthiness of object arrays

1, in module AttributeError: 'numpy.ndarray' object has no attribute '__nonzero__' 2014-11-13 10:05 GMT-08:00 Alan G Isaac alan.is...@gmail.com: On 11/13/2014 12:37 PM, Antony Lee wrote: On Python3, __nonzero__ is never defined (always raises an AttributeError), even after calling __bool__

[Numpy-discussion] truthiness of object arrays

I am puzzled by the following (numpy 1.9.0, python 3.4.2): In [1]: t = array(None); t[()] = array([None, None]) # Construct a 0d array of dtype object, containing a single numpy array with 2 elements In [2]: bool(t) Out[2]: True In [3]: if t: pass

Re: [Numpy-discussion] Broadcasting with np.logical_and.reduce

:48 GMT-07:00 Sebastian Berg sebast...@sipsolutions.net: On Do, 2014-09-11 at 22:54 -0700, Antony Lee wrote: Hi, I thought that ufunc.reduce performs broadcasting, but it seems a bit confused by boolean arrays: ipython with pylab mode on In [1]: add.reduce([array([1, 2]), array([1

Re: [Numpy-discussion] Broadcasting with np.logical_and.reduce

I see. I went back to the documentation of ufunc.reduce and this is not explicitly mentioned although a posteriori it makes sense; perhaps this can be made clearer there? Antony 2014-09-12 2:22 GMT-07:00 Robert Kern robert.k...@gmail.com: On Fri, Sep 12, 2014 at 10:04 AM, Antony Lee antony

Re: [Numpy-discussion] Broadcasting with np.logical_and.reduce

, Robert Kern robert.k...@gmail.com wrote: On Fri, Sep 12, 2014 at 5:44 PM, Antony Lee antony@berkeley.edu wrote: I see. I went back to the documentation of ufunc.reduce and this is not explicitly mentioned although a posteriori it makes sense; perhaps this can be made clearer

[Numpy-discussion] Broadcasting with np.logical_and.reduce

Hi, I thought that ufunc.reduce performs broadcasting, but it seems a bit confused by boolean arrays: ipython with pylab mode on In [1]: add.reduce([array([1, 2]), array([1])]) Out[1]: array([2, 3]) In [2]: logical_and.reduce([array([True, False], dtype=bool), array([True], dtype=bool)])

Re: [Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

Thanks a lot! Antony 2013/9/20 Henry Gomersall h...@cantab.net On 18/09/13 01:51, Antony Lee wrote: While I realize that this is certainly tweaking multiprocessing beyond its specifications, I would like to use it on Windows to start a 32-bit Python process from a 64-bit Python process

Re: [Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

2013/9/19 Robert Kern robert.k...@gmail.com On Thu, Sep 19, 2013 at 5:58 PM, Antony Lee antony@berkeley.edu wrote: Henry: thanks a lot, that would be very appreciated regardless of whether I end up using it in this specific project or not. Other replies below. Antony 2013/9

Re: [Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

Henry: thanks a lot, that would be very appreciated regardless of whether I end up using it in this specific project or not. Other replies below. Antony 2013/9/19 Robert Kern robert.k...@gmail.com On Thu, Sep 19, 2013 at 2:40 AM, Antony Lee antony@berkeley.edu wrote: Thanks, I didn't

Re: [Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

if the FFTs are going to be the limiting step but I thought I may as well give pyFFTW a try and ran into that issue... Antony 2013/9/18 Robert Kern robert.k...@gmail.com On Wed, Sep 18, 2013 at 1:51 AM, Antony Lee antony@berkeley.edu wrote: Hi all, While I realize that this is certainly

[Numpy-discussion] multiprocessing, numpy and 32-64 bit cohabitation

Hi all, While I realize that this is certainly tweaking multiprocessing beyond its specifications, I would like to use it on Windows to start a 32-bit Python process from a 64-bit Python process (use case: I need to interface with a 64-bit DLL and use an extension (pyFFTW) for which I can only

Re: [Numpy-discussion] Python3, genfromtxt and unicode

Sure, I will. Right now my solution is to use genfromtxt once with bytes and auto-dtype detection, then modify the resulting dtype, replacing bytes with unicodes, and use that new dtypes for a second round of genfromtxt. A bit awkward but that gets the job done. Antony Lee 2012/5/1 Charles R

[Numpy-discussion] Python3, genfromtxt and unicode

limited understanding the problem comes earlier, in the way StringBuilder is defined(?). Antony Lee import io, numpy as np s = io.BytesIO() s.write(babc 1\ndef 2) s.seek(0) t = np.genfromtxt(s, dtype=None) # (or converters={0: bytes}) print(t, t.dtype) # - [(b'a', 1) (b'b', 2)] [('f0', '|S1'), ('f1', 'i8

[Numpy-discussion] unicode string for specifying dtype

I just ran into the following: np.dtype(uf4) Traceback (most recent call last): File stdin, line 1, in module TypeError: data type not understood Is that the expected behaviour? Thanks in advance, Antony Lee ___ NumPy-Discussion mailing list NumPy