Sebastian Berg

I tend to think that for this to be used often enough to make a dent it needs to be dead simple. Which is a bit related to @melissawm's PR...

My super-secret plan/idea would be that someone (maybe not in NumPy itself) creates a `FloatConstantsDType`. With some "common dtype", etc. magic it should be possible provide constants at different precisions...

Stumbled on this issue, do you care about it? CuPy has little understanding of dtype parameters in general right now. I moved some code around in a current PR, which...

CC @lysnikolaou for awareness. Now that I glance at this, I wonder a bit if it may be easier to just reinterpret the `utf8` buffer as an ascii/latin1 buffer (do...

Thanks for the issue! I agree, we should probably also just deprecate `np.fix`, I don't like the name anyway and `trunc` looks better _and_ more reliable.

Yeah, `fix` is terrible to the point that I wonder if would make sense to re-write it as just calling `trunc()` even if we deprecate it. That is, I don't...

The main point is that the current approach of if/else does not generalize to any Array API implementing object. Rather we have a few hand-picked things that we add mapping...

> So this is meant to allow registering new implementations of (parts of) SciPy API instead of hardcoding cupyx.scipy and jax.scipy, as it currently is, correct? Right, the idea is...

> which `xp=` is inconvenient Indeed a side-question. You expose an `xp=` kwarg for array creating functions and that just doesn't quite match with the type centric design in spatch...

I pushed a commit that loads the CuPy backend as-is via the entry-point, not much of a PoC maybe, but that entry-point could come from anywhere. The following code didn't...