complex type promotion

[inversecrime]

What is the best way to avoid manual type promotion like this:

import jax.numpy as jnp

x = jnp.zeros(2)
y = jnp.asarray(1j)
print(x+y)  # this works fine
print(x.at[0].set(y))  # this doesn't work
print(x.astype(jnp.promote_types(x.dtype, y.dtype)).at[0].set(y))  # this works, but I would rather avoid it

[jakevdp]

This currently raises a warning I believe. We have a TODO to make this into an error.

If you want to cast x into a new dtype, I don't think we'll ever do that implicitly. Your best option is probably to do it explicitly as in your last line.

[inversecrime]

This is quite unsatisfying though...

[jakevdp]

What semantics would you suggest that would be more satisfying?

[inversecrime]

This was just an unnecessary comment.
From your answer, I conclude that my problem is a consequence of what jax is (i.e. "differentiable NumPy that runs on accelerators"),
and I'm perfectly fine with that, given how useful jax has already been in the short time of me using it.

I also noticed that even numpy doesn't allow implicit type promotion when using inplace operations - I'm just used to it because I come from matlab.

If I were to suggest something, maybe a keyword argument for "ndarray.at" which would allow implicit type promotion for all "set" operations.

[jakevdp]

Thanks – I've been thinking about adding an argument similar to numpy's casting concept, which lets the user specify how mismatched dtypes in the update might be handled. Perhaps we could include a mode that allows implicit casting of the destination array.