Matthew Barber

Ah I see thanks. The `di.electron` path does indeed launch, with a familiar warning. ``` [98337:1111/133530.962570:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData:

Would we want a data type function for complex dtypes i.e. `cinfo()`? Currently NumPy and PyTorch don't have a dedicate method, but complex dtypes can fallback on `finfo()`. Interestingly there...

Related [discussion](https://github.com/data-apis/consortium-feedback/discussions/8) (somehow totally missed this interesting issue agh)

Should this PR be blocked until an initial spec release?

> Sorry if this is a bit off topic, but I wonder if instead of having different functions like this, we could have just one function that was type agnostic...

> Nearly all of the information is shared other than `resolution`. In fact `resolution` could even be specified for integers for simplicity (as it would just be `1`). Ah `resolution=1`...

How about we have bound-y attributes per component, i.e. `{real/imag}_{min/max}`, `{real/imag}_eps` and `{real/imag}_smallest_normal`? Or just attributes for both the real and imag components (which should be the same), i.e. `component_{min/max}`,...

Think we forgot to delegate someone to do this, so just now wrote an issue at https://github.com/numpy/numpy/issues/22260

How do folks feel about changing `xp.finfo()` so it supports complex dtypes? https://github.com/numpy/numpy/issues/22260#issuecomment-1247387732 I think makes a sound argument > `cinfo()` does not sound very useful to me. Complex types...

> @honno is there anything left to do here after [gh-484](https://github.com/data-apis/array-api/pull/484)? Nope—forgot to link this issue to that merged PR, so I'll close this.