Hi Sebastian,
Tricky! It seems a balance between unexpected memory blow-up and unexpected
wrapping (the latter mostly for integers).
Some comments specifically on your message first, then some more general
related ones.
1. I'm very much against letting `a + b` do anything else than `np.add(a,
A few thoughts:
- We're not trying to achieve systematic guards against integer overflow /
wrapping in ufunc inner loops, right? The performance tradeoffs for a
"result-based" casting / exception handling addition would presumably be
controversial? I know there was some discussion about having an
Hi all,
Maybe to clarify this at least a little, here are some examples for
what currently happen and what I could imagine we can go to (all in
terms of output dtype).
float32_arr = np.ones(10, dtype=np.float32)
int8_arr = np.ones(10, dtype=np.int8)
uint8_arr = np.ones(10, dtype=np.uint8)
On Wed, 2019-06-05 at 14:14 -0700, Stephan Hoyer wrote:
> On Wed, Jun 5, 2019 at 1:43 PM Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> > Hi all,
> >
> >
> > Because `uint8(127)` can also be a `int8`, but uint8(128) it is not
> > as
> > simple as finding the "minimal" dtype once and
On Wed, Jun 5, 2019 at 1:43 PM Sebastian Berg
wrote:
> Hi all,
>
> TL;DR:
>
> Value based promotion seems complex both for users and ufunc-
> dispatching/promotion logic. Is there any way we can move forward here,
> and if we do, could we just risk some possible (maybe not-existing)
> corner
Hi all,
TL;DR:
Value based promotion seems complex both for users and ufunc-
dispatching/promotion logic. Is there any way we can move forward here,
and if we do, could we just risk some possible (maybe not-existing)
corner cases to break early to get on the way?
---
Currently when you
