Re: [Numpy-discussion] ANN: SciPy 1.7.1

2021-08-02 Thread Charles R Harris 
On Sun, Aug 1, 2021 at 8:31 PM Tyler Reddy  wrote:

> Hi all,
>
> On behalf of the SciPy development team I'm pleased to announce
> the release of SciPy 1.7.1, which is a bug fix release.
>
> Sources and binary wheels can be found at:
> https://pypi.org/project/scipy/
> and at: https://github.com/scipy/scipy/releases/tag/v1.7.1
> 
> 
>
> One of a few ways to install this release with pip:
>
> pip install scipy==1.7.1
>
> =
> SciPy 1.7.1 Release Notes
> =
>
> SciPy 1.7.1 is a bug-fix release with no new features
> compared to 1.7.0.
>
> Authors
> ===
>
> * Peter Bell
> * Evgeni Burovski
> * Justin Charlong +
> * Ralf Gommers
> * Matti Picus
> * Tyler Reddy
> * Pamphile Roy
> * Sebastian Wallkötter
> * Arthur Volant
>
> A total of 9 people contributed to this release.
> People with a "+" by their names contributed a patch for the first time.
> This list of names is automatically generated, and may not be fully
> complete.
>
> Issues closed for 1.7.1
> --
>
> * `#14074 `__: Segmentation
> fault when building cKDTree with Scipy 1.6.3.
> * `#14271 `__:
> scipy.io.loadmat failure in 1.7.0
> * `#14273 `__:
> \`scipy.signal.{medfilt,medfilt2d}\` hit "Windows fatal exception:...
> * `#14282 `__: DOC, CI:
> stats skewtest refguide failure
> * `#14363 `__: Huge stack
> allocation in _sobol.pyx may cause stack overvflow
> * `#14382 `__: Memory leak
> in \`scipy.spatial.distance\` for \`cdist\`
> * `#14396 `__: BUG: Sphinx
> 4.1 breaks the banner's logo
> * `#1 `__: DOC/FEAT
> Rotation.from_rotvec documents a degrees argument which...
>
> Pull requests for 1.7.1
> --
>
> * `#14178 `__: DEV: Update
> Boschloo Exact test
> * `#14264 `__: REL: prepare
> for SciPy 1.7.1
> * `#14283 `__: BUG: fix
> refguide-check namedtuple handling
> * `#14303 `__: FIX: Check for
> None before calling str methods
> * `#14327 `__: BUG: medfilt
> can access beyond the end of an array
> * `#14355 `__: BUG: KDTree
> balanced_tree is unbalanced for degenerate data
> * `#14368 `__: BUG: avoid
> large cython global variable in function
> * `#14384 `__: BUG: Reference
> count leak in distance_pybind
> * `#14397 `__: DOC/CI: do not
> allow sphinx 4.1.
> * `#14417 `__: DOC/CI: pin
> sphinx to !=4.1.0
> * `#14460 `__: DOC: add
> required scipy version to kwarg
> * `#14466 `__: MAINT: 1.7.1
> backports (round 1)
> * `#14508 `__: MAINT: bump
> scipy-mathjax
> * `#14509 `__: MAINT: 1.7.1
> backports (round 2)
>
>
> Checksums
> =
>
> MD5
> ~~~
>
> ef8b44a175818183de28f2c3dacf4b74
>  scipy-1.7.1-cp37-cp37m-macosx_10_9_x86_64.whl
> 4f717b62946a6306bba88696b4992c73
>  scipy-1.7.1-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
> decf6837d0a28bdeb911e6e2d18b777c
>  scipy-1.7.1-cp37-cp37m-manylinux_2_5_i686.manylinux1_i686.whl
> 6449932605e3284f731744eb207e5612
>  scipy-1.7.1-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.whl
> fb94deaf9b43bf18890b0bd12fc26fda  scipy-1.7.1-cp37-cp37m-win32.whl
> c5894e5811278243d7f4abeb1a5f230f  scipy-1.7.1-cp37-cp37m-win_amd64.whl
> 3aec592a699f835319cbb4649f30df71
>  scipy-1.7.1-cp38-cp38-macosx_10_9_x86_64.whl
> 774a74a6c81d40c9a305523707c024f4
>  scipy-1.7.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
> 30206a19a96549f665bd608fe6bf2761
>  scipy-1.7.1-cp38-cp38-manylinux_2_5_i686.manylinux1_i686.whl
> eb58d9f3797d47866bfe571d5df3b827
>  scipy-1.7.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.whl
> 808a907d994b98fd6dbe2050a48b8c69  scipy-1.7.1-cp38-cp38-win32.whl
> 688921def6681ee5abe8543aca8383c2  scipy-1.7.1-cp38-cp38-win_amd64.whl
> 2fe4e958cb14d0b071c494b9faee0c98
>  scipy-1.7.1-cp39-cp39-macosx_10_9_x86_64.whl
> dd5b4db9cf83a0594e0b651e198b16a4
>  scipy-1.7.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
> 67c5d75378d0ba2803c1b93fe670563b
>  scipy-1.7.1-cp39-cp39-manylinux_2_5_i686.manylinux1_i686.whl
> c1ea8eec1dd6d

[Numpy-discussion] Revert the return of a single NaN for `np.unique` with floating point numbers?

2021-08-02 Thread Sebastian Berg 
Hi all,

In NumPy 1.21, the output of `np.unique` changed in the presence of
multiple NaNs.  Previously, all NaNs were returned when we now only
return one (all NaNs were considered unique):

a = np.array([1, 1, np.nan, np.nan, np.nan])

Before 1.21:

>>> np.unique(a)
array([ 1., nan, nan, nan])

After 1.21:

array([ 1., nan])


This change was requested in an old issue:

 https://github.com/numpy/numpy/issues/2111

And happened here:

 https://github.com/numpy/numpy/pull/18070

While, it has a release note.  I am not sure the change got the
attention it deserved.  This would be especially worrying if it is a
regression for anyone?


Cheers,

Sebastian


PS: One additional note, is that this does not work for object arrays
(it cannot reasonable):

>>> np.unique(a.astype(object))
array([1.0, nan, nan, nan], dtype=object)


signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Plan for a new Indexing how-to document

2021-08-02 Thread Mukulika Pahari 
Hi, all!
I'm planning to write a how-to doc for ndarray indexing as per discussion
in https://github.com/numpy/numpy/pull/19407. I have opened a discussion
issue (https://github.com/numpy/numpy/issues/19586) with a few ideas and
would love to know your opinions on them and other use-cases you'd like to
see in the doc.

Thank you!
Mukulika Pahari
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Revert the return of a single NaN for `np.unique` with floating point numbers?

2021-08-02 Thread Ralf Gommers 
On Mon, Aug 2, 2021 at 7:04 PM Sebastian Berg 
wrote:

> Hi all,
>
> In NumPy 1.21, the output of `np.unique` changed in the presence of
> multiple NaNs.  Previously, all NaNs were returned when we now only
> return one (all NaNs were considered unique):
>
> a = np.array([1, 1, np.nan, np.nan, np.nan])
>
> Before 1.21:
>
> >>> np.unique(a)
> array([ 1., nan, nan, nan])
>
> After 1.21:
>
> array([ 1., nan])
>
>
> This change was requested in an old issue:
>
>  https://github.com/numpy/numpy/issues/2111
>
> And happened here:
>
>  https://github.com/numpy/numpy/pull/18070
>
> While, it has a release note.  I am not sure the change got the
> attention it deserved.  This would be especially worrying if it is a
> regression for anyone?
>

I think it's now the expected answer, not a regression. `unique` is not an
elementwise function that needs to adhere to IEEE-754 where nan != nan. I
can't remember reviewing this change, but it makes perfect sense to me.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal for adding bit_count

2021-08-02 Thread Sebastian Berg 
On Thu, 2021-07-29 at 21:46 +0530, Ganesh Kathiresan wrote:
> Hi All,
> 
> 
> 
> I am working  on a new
> UFunc, `
> bit_count ` (popcount
> in
> other languages) that aims to count the number of 1-bits in
> the absolute value of an Integer.
> 

Thanks for the proposal!   Since `int.bit_count()` is now a Python
builtin (as a method on integers), I feel it is a good idea to add it
to NumPy.
It is requested fairly commonly as well.


Aside from comments about the inclusion in NumPy,  I had two questions
where I would love input:

* Should `np.ndarray.bit_count()` exist?  I tend against this;
  but we should have it on (integer) scalars to mirror the
  Python `int`.

* The return value is currently the same type as the input.  That
  means that: `np.bit_count(uint8)` returns the count as `uint8`
  while `np.bit_count(int32)` returns it as `int32`, etc.

  I think `bit_count` is different from typical math functions,
  so I am not quite sure this is what we want?  The main
  alternative I see right now would be returning the default
  integer (usually int64) – unless otherwise specified.

  As an aside, I am not sure what is returned for booleans right now
  int8, uint8, or boolean?  (Returning boolean for a count seems an
  oversight though).


Cheers,

Sebastian



> 
> Implementation
> --
> 
> The primary reference for the implementation is CountBitsSetParallel
> <
> http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel
> >.
> Here we take 12 operations to achieve the result which is the same as
> the
> lookup table method but does not suffer from memory issues or cache
> misses.
> 
> The implementation is aimed at unsigned integers, absolute value of
> signed
> integers and objects that support the operation.
> 
> 
> Usage
> --
> 
>     >>> np.bit_count(1023)
> 
>     10
> 
>     >>> a = np.array([2**i - 1 for i in range(16)])
> 
>     >>> np.bit_count(a)
> 
>     array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13,
> 14, 15])
> 
>     >>> np.int32(1023).bit_count()
> 
>     10
> 
> 
> Notes
> -
> 
> 1. Python has included this method here
> <
> https://github.com/python/cpython/commit/8bd216dfede9cb2d5bedb67f20a30c99844dbfb8
> >
>  (3.10+). Tracking issue 
> 
> 2.  NumPy tracking issue
> 
> 
> 3.  Interesting read
> <
> https://archive.org/details/dr_dobbs_journal_vol_08/page/n185/mode/2up
> > on
> how we get the magic number. Needed a bit of digging :)
> 
> 
> Please let us know what you think about the implementation and where
> we can
> improve in terms of performance or interface.
> 
> Regards,
> Ganesh
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal for adding bit_count

2021-08-02 Thread Stefan van der Walt 
On Mon, Aug 2, 2021, at 10:50, Sebastian Berg wrote:
> * Should `np.ndarray.bit_count()` exist?  I tend against this;
>   but we should have it on (integer) scalars to mirror the
>   Python `int`.

Should `np.bit_count` exist?  Having it on the int* types may be sufficient.

> * The return value is currently the same type as the input.  That
>   means that: `np.bit_count(uint8)` returns the count as `uint8`
>   while `np.bit_count(int32)` returns it as `int32`, etc.

What is the max value of the count?  64?  If so it can go in a uint8.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion