[Numpy-discussion] Re: New feature: binary (arbitrary base) rounding
On Thu, 2022-11-03 at 11:37 +0100, Oscar Gustafsson wrote: > Hi all, > > I hope this is the correct way to propose a new feature. > https://github.com/numpy/numpy/issues/22522 > Thanks for the proposal. I don't have much of an opinion on this and right now I am mainly wondering whether there is prior art which can inform us that this is relatively widely useful? > Currently, the around-function supports rounding to a given number of > decimal digits. It is often quite convenient to be able to round to a > given > number of binary digits to mimic fixed-point representations. > Currently > this can be readily achieved using e.g. > > fractional_bits = 5 > scale = 2**fractional_bits > x_round = np.around(x*scale)/scale > > However, it would be more convenient (and probably faster) to provide > dedicated support for it. This seems more like a a place for some bit-fiddling, but I am not sure. Also a question is whether rounding modes make sense and what you want (truncate, round to even?). I suspect that this would be more something for a project similar to Warrens ufunclab: https://github.com/WarrenWeckesser/ufunclab I.e. written as a NumPy ufunc, but not in NumPy iself. - Sebastian > > I see a few different ways to obtain this: > 1. Provide a separate function (binaryround?) > 2. Provide a base argument to around which defaults to 10. > 3. Provide a quant(ization) function where the argument is the step- > size. > (For completeness, one may think of having multiple quantization > modes, not > just rounding) > > Any opinions? > > BR Oscar Gustafsson > ___ > 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: sebast...@sipsolutions.net ___ 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] Introducing Arm Optimized Routines
Hello, Here at Arm, we've been investigating how we can improve performance on AArch64. One way in which we can improve performance is by integrating some existing optimized routines (https://github.com/ARM-software/optimized-routines), similar to the SVML methods for AVX512 that are currently included as a git submodule. Our intent is to include the optimized routines repository as an additional submodule which we can then use to provide routines on AArch64 for ASIMD, SVE and beyond. Currently, we're targeting 4-ULP as this aligns with libmvec (https://sourceware.org/glibc/wiki/libmvec) and the SVML integration (https://github.com/numpy/numpy/pull/19478). This is alongside adding sufficient error handling to pass the Numpy test suite, meeting the test requirements highlighted in the SVML integration (https://github.com/numpy/numpy/pull/19478#issuecomment-893001722). We've already started curating the necessary functions, let us know if you have any feedback. Cheers, Chris IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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: Introducing Arm Optimized Routines
Thanks, this seems like it would improve performance on aarch64. Would the routines also work with the Apple silicon arm64? If these are new routines, it would be better to implement them in terms of the numpy universal intrinsics rather than adding a new submodule. Matti On 8/11/22 13:30, Chris Sidebottom wrote: Hello, Here at Arm, we've been investigating how we can improve performance on AArch64. One way in which we can improve performance is by integrating some existing optimized routines (https://github.com/ARM-software/optimized-routines), similar to the SVML methods for AVX512 that are currently included as a git submodule. Our intent is to include the optimized routines repository as an additional submodule which we can then use to provide routines on AArch64 for ASIMD, SVE and beyond. Currently, we're targeting 4-ULP as this aligns with libmvec (https://sourceware.org/glibc/wiki/libmvec) and the SVML integration (https://github.com/numpy/numpy/pull/19478). This is alongside adding sufficient error handling to pass the Numpy test suite, meeting the test requirements highlighted in the SVML integration (https://github.com/numpy/numpy/pull/19478#issuecomment-893001722). We've already started curating the necessary functions, let us know if you have any feedback. Cheers, Chris IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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: matti.pi...@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: NEP 50 and integers (e.g. uint8 together -1)
Since I am still a bit on the fence with the deprecation (see also below), to mostly make the following Python integer conversions an error (for now deprecation): np.uint8(-1) np.array(5, dtype=np.int8) I have created a Poll about the change in case anyone wants to give feedback but formulate arguments in a mail: https://discuss.scientific-python.org/t/deprecation-of-assigning-converting-out-of-bounds-python-integers/580 Cheers, Sebastian PS: One tangential reason why I am bringing it up, is that I am struggling with the notion of "casting safety" for these Python integers. I will bring this up again also, but it is not directly related. On Tue, 2022-10-11 at 14:00 +0200, Sebastian Berg wrote: > Hi all, > > just to mention it, there is a PR ready on this: > > https://github.com/numpy/numpy/pull/22385 > > it necessecitates some changes to the NumPy test suite and will do > similar at least for SciPy downstream > I currently suspect we will give it a shot soon, but am not opposed > at > all with discussing especially allowing: > > np.uint8(-1) > > i.e. using the negative range of the corresponding signed integer > explicitly for the `np.uint8`, `np.uint16`. But still disallow it > for > other operations like `np.array([-1], dtype=np.uint8)`. > > As I said, my main interest is pushing NEP 50 related change: > > https://github.com/numpy/numpy/pull/21875 > > which this will simplify. If this PR seems tricky to move forward, > that is fine, but I would like to push that PR without the > simplification. (Decoupling this change from NEP 50 at some > complexity > cost.) > > Cheers, > > Sebastian > > > > On Tue, 2022-10-04 at 17:24 +0200, Ralf Gommers wrote: > > On Thu, Sep 29, 2022 at 10:10 AM Sebastian Berg > > > > wrote: > > > > > On Wed, 2022-09-28 at 16:44 -0700, Stefan van der Walt wrote: > > > > Hi Sebastian, > > > > > > > > On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote: > > > > > np.array([1, 2], dtype="uint8") + (-1) > > > > > > > > > > which currently returns an "int16" array must raise an > > > > > error. > > > > > This > > > > > is > > > > > because we want to return a uint8 array but the -1 cannot be > > > > > represented well by -1. > > > > > > > > Did you mean: the -1 is not representable in uint8? > > > > > > Sorry yes. With NEP 50, we do not look at the value (initially) > > > so > > > determine that the operation must be handled as: > > > > > > uint8 + uint8 -> uint8 > > > > > > We then try to convert the -1 to uint8. That conversion would > > > raise an > > > error, because previously the result was an int16. > > > (This is to prevent silent unexpected result changes and seemed > > > like > > > the more reasonable behavior.) > > > > > > On the other hand, assignments like: > > > > > > uint8_arr[0] = -1 > > > np.array([-1], dtype=np.uint8) > > > > > > do happily convert the -1 to `uint8`, currently. If we keep > > > allowing > > > these, we have two slightly different conversions: one that > > > fails > > > and > > > one that does not. > > > > > > This is fine, but maybe we actually want it to always fail in the > > > future? > > > > > > > It seems better to always raise an exception indeed. So if it > > simplifies > > your PR to do that now, I'd say go for it. > > > > 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: sebast...@sipsolutions.net > > > ___ > 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: sebast...@sipsolutions.net ___ 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
