Fix serialization of complex256 objects to JSON

[axelboc]

1. https://h5web.panosc.eu/h5grove?file=sample.h5
2. Select /complex256_scalar or /complex256_2D
3. 500 error

h5grove fails in encoders.py, when serializing complex256 values to JSON with orjson. There's an infinite recursion call in orjson_default, on line 27.

With complex64 or complex128 scalars, I trace two calls to orjson_default:

1. During the first call, the condition that matches first is isinstance(o, (np.generic, np.ndarray)) => o.tolist() is called and returned.
2. This triggers a second call, during which the condition that matches first is now isinstance(o, complex) => [o.real, o.imag] is returned.

With complex256, the first call is the same, but on the second call, the condition that matches is again isinstance(o, (np.generic, np.ndarray)) so we recurse infinitely.

If I move the complex condition first, then o.tolist() is never called for complex64 and complex128 numbers (i.e. there's only one call to orjson_default). I can then change the condition to isinstance(o, numbers.Complex) to also match complex256 and the infinite recursion issue is gone.

[axelboc]

Opening as draft as this casting to float64 doesn't seem to work with complex256 values. When I open /complex256_scalar, I still get [0.0,null] instead of [0.0,inf] (like with /float128_2D). I could not reproduce the issue in a Python REPL, so something weird is going on.

[axelboc]

/float128_2D is fetched as binary, so inf is kept, whereas /complex256_scalar is fetched as JSON, so inf is converted to null. So all is well. This relates more to silx-kit/h5web#641 (comment)

Though now I'm wondering whether casting to float64 with float() is needed at all... With np.complex256(np.finfo(np.complex256).smallest_normal + np.finfo(np.complex256).max * 1j), I get [0.0, null] both with and without the casting. For complex64, it actually adds "fake" precision, I think, which doesn't seem great.

[axelboc]

I've removed the casts to float64.

[t20100]

orjson_default is called recursively so when it is called for a complex and converts it to a list, it is then called again to convert the real and imaginary part with:

h5grove/h5grove/encoders.py

Lines 23 to 25 in a248a20

	if isinstance(o, np.number) and o.dtype.kind == "f" and o.itemsize > 8:
	# Force conversion of float >64bits to native float even if it means losing precision
	return float(o)