On Wed, Jan 27, 2021 at 5:44 PM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> 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...) > Sounds good, thanks. > > > > > 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"). > I'd say just document it and recommend that if >1 custom dtypes are used, then the user should (if they really care about the issue you bring up) determine the output dtype you want via some use of result_type and then explicitly cast. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
