On Wed, 2021-01-27 at 10:33 +0100, Ralf Gommers wrote: > On Tue, Jan 26, 2021 at 10:21 PM Sebastian Berg < > sebast...@sipsolutions.net> > wrote: > <snip>
Thanks for all the other comments, they are helpful. I am considering writing a (hopefully short) NEP, to define the direction of thinking here (and clarify what user DTypes can expect). I don't like doing that, but the issue turns out to have a lot of traps and confusing points. (Our current logic alone is confusing enough...) > > > The other tricky example I have was: > > > > The following becomes problematic (order does not matter): > > uint24 + int16 + uint32 -> int64 > > <== (uint24 + int16) + (uint24 + uint32) -> int64 > > <== int32 + uint32 -> int64 > > > > With the addition that `uint24 + int32 -> int48` is defined the > > first > > could be expected to return `int48`, but actually getting there is > > tricky (and my current code will not). > > > > If promotion result of a user DType with a builtin one, can be a > > builtin one, then "ammending" the promotion with things like > > `uint24 + > > int32 -> int48` can lead to slightly surprising promotion results. > > This happens if the result of a promotion with another "category" > > (builtin) can be both a larger category or a lower one. > > > > I'm not sure I follow this. If uint24 and int48 both come from the > same > third-party package, there is still a problem here? > Yes, at least unless you ask `uint24` to take over all of the work (i.e. pass in all DTypes at once). So with a binary operator design it is "problematic" (in the sense that you have to live with the above result). Of course a binary operator base does probably not preclude a more complex design. I like a binary operator (it seems much easier to reason about and is a common design pattern). But it would be plausible to have an n-ary design where you pass all dtypes to each and ask them to handle it (similar to `__array_ufunc__`). We could even have both (the binary version for most things, but the ability to hook into the n-ary "reduction"). Cheers, Sebastian > Cheers, > Ralf > _______________________________________________ > 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
