[Numpy-discussion] Re: mixed mode arithmetic
Hi Matti, The documentation for numpy.dot currently states """ out ndarray, optional Output argument. This must have the exact kind that would be returned if it was not used. In particular, it must have the right type, must be C-contiguous, and its dtype must be the dtype that would be returned for dot(a,b). This is a performance feature. Therefore, if these conditions are not met, an exception is raised, instead of attempting to be flexible. """ I think this means that if dot(a,b) returned FP32 for FP16 inputs, it would be consistent with this API to supply a full precision output array. All that would be needed in an actual implementation is a mixed_precision flag (or output_dtype option) for this op to override the usual type promotion rules. Do you agree? 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] Is there a desire to implement more functions as ufuncs? e.g. round, astype, real
Hello there! First time posting here and I apologize if this discussion is not new. I couldn't find it in a search. I've been contributing a bit to the sparse project (https://github.com/pydata/sparse) and I was working on specializing the behavior for single-argument ufuncs, because there is a faster path for some sparse arrays if the indexes don't change at all. As I was working on this I noticed that `sparse` uses `__array_ufunc__` on some non-ufunc methods, like `round`, `clip`, and `astype`, which caused some bugs in my initial attempt. This is easy enough to fix in the package, but it made me wonder if those functions _could_ or _should_ be ufuncs in numpy itself. The full list for the sparse library is `clip`, `round`, `astype`, `real`, and `imag`. There might be other candidates in numpy, those are just the ones in this project. The benefit I see is that an implementor of `__array_ufunc__` wouldn't need to implement these methods. But perhaps their interfaces are too complex for ufunc-iness? ___ 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
On 10/7/23 16:13, Jens Glaser via NumPy-Discussion wrote: Hi Matti, The documentation for numpy.dot currently states """ out ndarray, optional Output argument. This must have the exact kind that would be returned if it was not used. In particular, it must have the right type, must be C-contiguous, and its dtype must be the dtype that would be returned for dot(a,b). This is a performance feature. Therefore, if these conditions are not met, an exception is raised, instead of attempting to be flexible. """ I think this means that if dot(a,b) returned FP32 for FP16 inputs, it would be consistent with this API to supply a full precision output array. All that would be needed in an actual implementation is a mixed_precision flag (or output_dtype option) for this op to override the usual type promotion rules. Do you agree? Jens ___ `np.dot` is strange. Could you use `np.matmul` instead, which is a real ufunc and (I think) already does this? 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] Re: mixed mode arithmetic
On Tue, Jul 11, 2023 at 10:11 AM Matti Picus wrote: > > On 10/7/23 16:13, Jens Glaser via NumPy-Discussion wrote: > > Hi Matti, > > > > The documentation for numpy.dot currently states > > > > """ > > out > > ndarray, optional > > Output argument. This must have the exact kind that would be returned if > it was not used. In particular, it must have the right type, must be > C-contiguous, and its dtype must be the dtype that would be returned for > dot(a,b). This is a performance feature. Therefore, if these conditions are > not met, an exception is raised, instead of attempting to be flexible. > > """ > > > > I think this means that if dot(a,b) returned FP32 for FP16 inputs, it > would be consistent with this API to supply a full precision output array. > All that would be needed in an actual implementation is a mixed_precision > flag (or output_dtype option) for this op to override the usual type > promotion rules. Do you agree? > > > > Jens > > `np.dot` is strange. Could you use `np.matmul` instead, which is a real > ufunc and (I think) already does this? > Sort of. As currently implemented, no, it won't do what Jens wants because there is no `ee->f` loop implemented (`e` is the typecode for float16, `f` for float32). Passing float16 operands and requesting a float32 output (either with `dtype=np.float32` or providing such an `out=`) will fall down to the `ff->f` loop and cause upcasting of the operands, which is not what they want. But notionally one could add an `ee->f` loop between those two that would catch this case when `dtype=np.float32` is requested. -- Robert Kern ___ 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
