[Numpy-discussion] Re: mixed mode arithmetic
On 9/7/23 23:34, glaserj--- via NumPy-Discussion wrote: Reviving this old thread - I note that numpy.dot supports in-place computation for performance reasons like this c = np.empty_like(a, order='C') np.dot(a, b, out=c) However, the data type of the pre-allocated c array must match the result datatype of a times b. Now, with some accelerator hardware (i.e. tensor cores or matrix multiplication engines in GPUs), mixed precision arithmetics with relaxed floating point precision (i.e.., which are not necessarily IEEE754 conformant) but with faster performance are possible, which could be supported in downstream libraries such as cupy. Case in point, a mixed precision calculation may take half precision inputs, but accumulate in and return full precision outputs. Due to the above mentioned type consistency, the outputs would be unnecessarily demoted (truncated) to half precision again. The current API of numpy does not expose mixed precision concepts. Therefore, it would be nice if it was possible to build in support for hardware accelerated linear algebra, even if that may not be available on the standard (CPU) platforms numpy is typically compiled for. I'd be happy to flesh out some API concepts, but would be curious to first get an opinion from others. It may be necessary to weigh the complexity of adding such support explicitly against providing minimal hooks for add-on libraries in the style of JMP (for jax.numpy), or AMP (for torch). Jens If your goal is "accumulate in and return full precision outputs", then you can allocate C as the full precision type, and NumPy should do the right thing. Note it may convert the entire input array to the final dtype, rather than doing it "on the fly" which could be expensive in terms of memory. Matti ___ 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] Feature: Imporved specificity in exceptions raised by random.seed()
When a number is passed to random.seed(), which is otherwise numerically valid,
but is of the wrong data type (e.g. a string passed into a Flask app that was
not cast to an int type or perhaps a float), a VauleError is raised with an
ambiguous caption: `The value [...] cannot be used to seed a
numpy.random.RandomState instance`. I realized quickly what the issue was, but
in my humble opinion, this looks like something that could trip up a novice
user [or a sleep deprived | distracted | in a rush] advanced user. If we
provide a more granular explanation of the issue `TypeError('1234' is of type
, supported types are , , and related types)`, this could be
helpful to novice users to more quickly diagnose and fix the problem.
___
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: mixed mode arithmetic
Neal Becker wrote: > I've been browsing the numpy source. I'm wondering about mixed-mode > arithmetic on arrays. I believe the way numpy handles this is that it > never does mixed arithmetic, but instead converts arrays to a common type. > Arguably, that might be efficient for a mix of say, double and float. > Maybe not. > But for a mix of complex and a scalar type (say, CDouble * Double), it's > clearly suboptimal in efficiency. > So, do I understand this correctly? If so, is that something we should > improve? Reviving this old thread - I note that numpy.dot supports in-place computation for performance reasons like this c = np.empty_like(a, order='C') np.dot(a, b, out=c) However, the data type of the pre-allocated c array must match the result datatype of a times b. Now, with some accelerator hardware (i.e. tensor cores or matrix multiplication engines in GPUs), mixed precision arithmetics with relaxed floating point precision (i.e.., which are not necessarily IEEE754 conformant) but with faster performance are possible, which could be supported in downstream libraries such as cupy. Case in point, a mixed precision calculation may take half precision inputs, but accumulate in and return full precision outputs. Due to the above mentioned type consistency, the outputs would be unnecessarily demoted (truncated) to half precision again. The current API of numpy does not expose mixed precision concepts. Therefore, it would be nice if it was possible to build in support for hardware accelerated linear algebra, even if that may not be available on the standard (CPU) platforms numpy is typically compiled for. I'd be happy to flesh out some API concepts, but would be curious to first get an opinion from others. It may be necessary to weigh the complexity of adding such support explicitly against providing minimal hooks for add-on libraries in the style of JMP (for jax.numpy), or AMP (for torch). Jens ___ 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 triage meeting
The next NumPy triage meeting will be held this Wednesday, July 13th at 5pm UTC. This is a meeting where we synchronously triage prioritized PRs and issues. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVXZz09 . Everyone is welcome to attend and contribute to a conversation. Please notify us of issues or PRs that you’d like to have reviewed by adding a GitHub link to them in the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg. -- 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
