[Numpy-discussion] Re: Expanding support in testing for external collections.Sequence objects
On 30/11/22 05:47, Stefan van der Walt wrote: On Tue, Nov 29, 2022, at 07:21, i...@markopacak.com wrote: The debate is whether np.testing.asset_equal should support collections.Sequence objects. assert list(sequence1) == list(sequence2) should do the trick, and also handles int vs float and nan comparisons. What is the general view on adding support in testing for Sequence objects? If it's a straightforward change that doesn't impact the NumPy test suite, it's probably fine. Let's see what the others say. Stéfan Apparently nothing is really straightforward. On the issue there is discussion of problems this causes when comparing strings (and how the naive implementation breaks lots of tests), and this comment [0] from a Pandas maintainer > If you do go down this path, take a look at pandas._libs.lib.is_list_like. I've found it to be a minor PITA to accommodate every corner case that users ask to consider listlike Matti [0] https://github.com/numpy/numpy/issues/22569#issuecomment-1331586018 ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Expanding support in testing for external collections.Sequence objects
On Wed, Nov 30, 2022 at 10:24 AM Matti Picus wrote: > > On 30/11/22 05:47, Stefan van der Walt wrote: > > On Tue, Nov 29, 2022, at 07:21, i...@markopacak.com wrote: > >> The debate is whether np.testing.asset_equal should support > >> collections.Sequence objects. > > assert list(sequence1) == list(sequence2) > > > > should do the trick, and also handles int vs float and nan comparisons. > > > >> What is the general view on adding support in testing for Sequence > objects? > > If it's a straightforward change that doesn't impact the NumPy test > suite, it's probably fine. Let's see what the others say. > > > > Stéfan > > > Apparently nothing is really straightforward. On the issue there is > discussion of problems this causes when comparing strings (and how the > naive implementation breaks lots of tests), and this comment [0] from a > Pandas maintainer > > > If you do go down this path, take a look at > pandas._libs.lib.is_list_like. I've found it to be a minor PITA to > accommodate every corner case that users ask to consider listlike > I agree with Matti, this tends to lead to quite a bit of work and dealing with corner cases, for little gain. We should move away from supporting non-array inputs, not allow more. I'd prefer to tell users to use `np.asarray()` on their inputs instead. Cheers, Ralf > > > Matti > > [0] https://github.com/numpy/numpy/issues/22569#issuecomment-1331586018 > > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: ralf.gomm...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Formally accept NEP 51: Changing the Representation of NumPy Scalars
On Tue, 2022-11-29 at 14:51 -0700, Aaron Meurer wrote:
> On Fri, Nov 25, 2022 at 9:36 AM Sebastian Berg
> wrote:
> >
> > Hi all,
> >
> > I would like to formally propose accepting NEP 51. Without any
> > concern
> > voiced, we will consider it accepted within 7 days.
> >
> > * Clearly we can always adjust the printing conventions, e.g.
> > whether
> > to include the `np.` or whether NaN's should be `np.float64(nan)`
> > or
> > not. But bike-sheds happening now have a much better chance of
> > being heard :).
>
> I always prefer things that have copy-pastability, so I would suggest
> something like np.float64('nan'). It looks like the NEP already does
> this for longdouble.
It is a bit different for longdouble because for longdouble you should
always put quotes anyway.
Note that if we do that, we somewhat also have to do it also for:
array([1.0, nan, 2.0])
which currently doesn't print quotes. But then we need to include the
dtype in the output, or that doesn't round-trip anymore (even with
defining `nan`).
>
> I'm assuming for float-64 and lower one can guarantee round-tripping
> with the Python float literal.
>
> The "np." also helps for copy-pastability for standard usage so that
> sounds fine too. It would be useful to allow it to be disabled or
> customized. For example, some libraries reuse NumPy dtype objects so
> they may want to replace "np." with their own library name, or just
> omit it. It wasn't clear to me if something like this is already part
> of the NEP or not.
This changes printing of instances, classes always print as
`numpy.uint8` and I am not planning on changing that.
I added a way to format a scalars repr when the dtype is known (i.e.
the same way as it would be when calling `repr(array)`) in the NEP.
I didn't attach it to the scalar though, either way it feels a bit
unwieldy, but I don't have a good idea for providing it and `str()`
basically does this also.
>
> >
> > 1. The current NEP states that we use `np.str_` and `np.bytes_`.
> > There
> > is some chance that the top-level names could be changed, in that
> > case
> > the representation would change accordingly. (I consider this an
> > adjustment we can do without the NEP.)
> >
> > 2. To properly implement the NEP, we need to automate some of the
> > documentation changes necessary. This should also enable
> > downstream to
> > do the same or at least have a blueprint as a starting point.
> > (Help with this work is greatly appreciated, since it is its own
> > small
> > project to hook into the doctest utilities.)
>
> A reusable script would be nice, since many projects are going to
> have
> doctests broken by this. I think there also may already be some
> existing tooling that just "fixes" doctests by making them match
> their
> output.
Yeah, such a tool should be good enough in practice, do you know where
to find it?
Otherwise hacking a doctest helper seems very possible.
- Sebastian
>
> Aaron Meurer
>
> >
> > I plan on adding a brief note on about helping with doc updates to
> > NEP
> > when accepting it. Ross was planning to add a table of changed
> > examples, although I don't think that is necessary for accepting.
> >
> > Cheers,
> >
> > Sebastian
> >
> >
> >
> > On Fri, 2022-10-28 at 10:54 +0200, Sebastian Berg wrote:
> > > Hi all,
> > >
> > > As mentioned earlier, I would like to propose changing the
> > > representation of scalars in NumPy. Discussion and ideas on
> > > changes
> > > are much appreciated!
> > >
> > > The main change is to show scalars as:
> > >
> > > * `np.float64(3.0)` instead of just `3.0`
> > > * `np.True_` instead of `True`
> > > * `np.void((3, 5), dtype=[('a', ' > > `(3, 5)`
> > > * Use `np.` rather than `numpy.` for datetime/timedelta.
> > >
> > > This way it is clear for users that they are dealing with NumPy
> > > scalars
> > > which behave different from Python scalars.
> > > The `str()` that is given when using `print()` and the way arrays
> > > are
> > > shown will be unchanged.
> > >
> > > The NEP draft can be found here:
> > >
> > > https://numpy.org/neps/nep-0051-scalar-representation.html
> > >
> > > and it includes more details and related changes.
> > >
> > > The implementation is largely finished and can be found here:
> > >
> > > https://github.com/numpy/numpy/pull/22449
> > >
> > > W are fairly late in the release cycle and the change should not
> > > block
> > > other things. So, the aim is to merge it early in the next
> > > release
> > > cycle. That way downstream has time to fix documentation is
> > > wanted.
> > >
> > > Depending on how discussion goes, I hope to formally propose the
> > > NEP
> > > fairly soon, so that the merging the implementation doesn't need
> > > to
> > > wait on NEP approval.
> > >
> > > Cheers,
> > >
> > > Sebastian
> > >
> > >
> > >
> > >
> > > On Thu, 2022-09-08 at 11:38 +0200, Sebastian Berg wrote:
> > > >
> > > > TL;DR: NumPy scalars representation is e.g. `34.3
[Numpy-discussion] Behavior of round(array)
Hi all, there is a discussion about how `round(array)` should behave in: https://github.com/numpy/numpy/issues/6248 There is some discussion about object arrays which should probably be fixed for `around()` in that ago. Otherwise, the is the question what to do about the fact that: * round(np.float64(2.**64)) -> 18446744073709551616 (a Python int) * round(np.array([2., 3., 2.**64]) can only return float or integer The NumPy `np.round`/`np.around` (same function) functions always return the same dtype. We can either ignore that discrepancy, or opt to raise an error, so that: >>> round(np.array([2., 3.5])) TypeError: Rounding a NumPy float array cannot return integers, use `round(arr, ndigits=0)` or `round(arr, 0) to indicate that a float result is desired. In the call today, I think we leaned a bit towards ignoring it, but if I read Aaron correctly, he prefers the error and it may be the conservative choice. We could of course do other things (i.e. return an integer `intp` array) but that would probably require a hard error for overflows (which is different from `np.rint(arr).astype(np.intp)`. Are there any small or big opinions on this? It seems useful to enable `round()` and is a bit of a shame to get caught up on the detail, but I am not sure what the right choice is :). - Sebastian ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Behavior of round(array)
Hi Sebastian, all, I’d lean towards an error too, given that the invariants implied by the Python implementation clearly aren‘t met. No strong opinions though. Best regards, Hameer Abbasi Von meinem iPhone gesendet > Am 30.11.2022 um 18:36 schrieb Sebastian Berg : > > Hi all, > > there is a discussion about how `round(array)` should behave in: > >https://github.com/numpy/numpy/issues/6248 > > There is some discussion about object arrays which should probably be > fixed for `around()` in that ago. > > Otherwise, the is the question what to do about the fact that: > > * round(np.float64(2.**64)) -> 18446744073709551616 (a Python int) > * round(np.array([2., 3., 2.**64]) can only return float or integer > > The NumPy `np.round`/`np.around` (same function) functions always > return the same dtype. > > We can either ignore that discrepancy, or opt to raise an error, so > that: > round(np.array([2., 3.5])) >TypeError: Rounding a NumPy float array cannot return integers, >use `round(arr, ndigits=0)` or `round(arr, 0) to indicate that a >float result is desired. > > In the call today, I think we leaned a bit towards ignoring it, but if > I read Aaron correctly, he prefers the error and it may be the > conservative choice. > > We could of course do other things (i.e. return an integer `intp` > array) but that would probably require a hard error for overflows > (which is different from `np.rint(arr).astype(np.intp)`. > > Are there any small or big opinions on this? It seems useful to enable > `round()` and is a bit of a shame to get caught up on the detail, but I > am not sure what the right choice is :). > > - Sebastian > > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: einstein.edi...@gmail.com ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Expanding support in testing for external collections.Sequence objects
Hi Ralf, thx for replying to this. > I'd prefer to tell users to use `np.asarray()` on their inputs instead. How would you do that? Through a warning in the test suite? Or document it somewhere? ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Expanding support in testing for external collections.Sequence objects
On Wed, Nov 30, 2022 at 7:10 PM Marko Pacak wrote: > Hi Ralf, thx for replying to this. > > > I'd prefer to tell users to use `np.asarray()` on their inputs instead. > > How would you do that? Through a warning in the test suite? Or document it > somewhere? > The docstring for array_equal should mention, for `actual` and `desired`, what input types are accepted. And the code itself should yield an informative error if an unsupported type is passed. That error message can be tested in the test suite if desired (not always done consistently, but it can't hurt). Cheers, Ralf ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Adding bit_count ufunc
On Fri, Nov 25, 2022 at 9:55 PM Serge Guelton wrote: > On Fri, Nov 25, 2022 at 08:09:02PM +0100, Sebastian Berg wrote: > > Thanks for bringing this up again. The Python method exists and it > > seems like relatively basic functionality. > > > > Overall, I am slightly in favor of adding the ufunc. So if nobody > > voices an opinion that it doesn't seem a good fit for NumPy, I would be > > happy to move forward with it. > It seems like there is enough demand, so +0.5 from me. > > PS: One of my main concern would be if we were to add many bitwise > > functions, in which case a `bitwise` namespace might be nice. But I am > > not convinced that should stop us here. > > Technically speaking, bitwise_and, birwise_or, bitwise_xor and bitwise_not > already exist and popcount is widely spread, it already has its compiler > builtin > under the name of __builtin_popcount > Those four `bitwise_*` functions also came to mind for me. I'll also add that Python has six bit-wise operators ( https://wiki.python.org/moin/BitwiseOperators), and because of that the array API standard implements `bitwise_left_shift` and `bitwise_right_shift` in addition to the four functions that NumPy has. So it looks to me like this new ufunc should be called `bitwise_count` rather than `bit_count`. Cheers, Ralf ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] next NumPy Newcomers' Hour - 12 pm UTC
Our next Newcomers' Hour will be held tomorrow, December 1st, at 12 pm UTC. Stop by to ask questions or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09 -- Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy https://numpy.org/ GitHub: inessapawson ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
