Jake Vanderplas

I should add: this is one reason that prior to the array API standard, we never implemented a `device` argument for array creation functions at the `jax.numpy` level. In general...

Hi - for what it's worth, we made the *deliberate* choice to return `None` here in order to make JAX's existing device placement semantics work with the specifications of the...

(to anticipate one response: no, it's not possible to make JAX arrays support mutation: central to JAX are transformations like `jit`, `vmap`, `grad`, etc. that rely on immutability assumptions in...

> This is very surprising. It would be nice if we can have a list of such occurrences here, The main example is `__setitem__`, which as far as I can...

>The key point is that there's no semantic difference between updating values in-place or out-of-place as long as the update modifies only a single array. Thinking about this a bit,...

> and since I cannot see how the out-of-place semantics would be possible to support technically, I think there is no alternative output. Sorry, I think you misunderstood my point....

Rather than getting lost in implementation details, let's bring it back to the statement I was responding to: > The key point is that there's no semantic difference between updating...

Hey all – we chatted about this in today's meeting, and here is a summary: - while it's true that mutability is an array-level property, it's also a framework-level property....

Since the scipy change is still settling upstream, I'd recommend waiting on this PR until things stabilize.

> scipy PR is merged, and did not affect how we are calling `signal.lombscargle` here anyway. This is true so long as long as we're certain that scipy is not...