Support conversion from int to float

[amnore]

I have the following type:

NDArray[Shape['2'], float]

and this json:

[150, 100]

When trying to deserialize from json, I would get the following error:

Value error, Invalid dtype! expected (<class 'numpy.float16'>, <class 'numpy.float32'>, <class 'numpy.float64'>, <class 'numpy.float32'>, <class 'numpy.float64'>), got int64 [type=value_error, input_value=[150, 100], input_type=list]
    For further information visit https://errors.pydantic.dev/2.10/v/value_error

This requirement seems too strict. Is it possible to automatically convert from integer to floats in this case?

[sneakers-the-rat]

Aha yes, I agree that to be consistent with pydantic behavior generally we should try and coerce there (and refuse to if we are in strict mode).

making some notes to self on implementation:

There is a tiny bit of constraint here, as one way of doing this would be to attempt to coerce and raise a validation error on failure, but for non-numpy arrays that could be e.g. stored on disk that could be a very costly operation indeed. For other formats like videos the coercion would be impossible or at least ill-advised since the dtype is intrinsic to the format.
For the numpy case though, where coercions should be comparatively cheap/possible, we can special-case coercion and then in the other interfaces raise a more informative error about why coercion can/can't be done.

An additional complication is between dtypes of different bit depth, e.g. if one sets an float32 should one coerce an float16 and float64 as well? I think the pydantic answer would be 'yes,' since the type annotation is the expected type after validation, rather than the expected input type, but we would probably want to put a warning on this type of coercion because doing naïve dtype conversions between e.g. uints and ints can be pretty bad.

One last complication is the case of type unions: we should check if any of the types in the union match, and not coerce if any of them do. then we should try to coerce each in order and pass the first. types can also be specified as a tuple (since the typing.Union API is a little shit), so same behavior there - attempt to coerce to each in order. in this case since numpy treats float as float64, we should reverse the order on the tuples so that the first coercion that's tried is float64.

ok i'll get on this. in the middle of a time-sensitive project elsewhere, but if you or anyone else sees this first and wants to PR, should be relatively straightforward:

• write a coerce_dtype function in validation.dtype
• add a coerce_dtype method in the base interface with a default impl that is just a passthrough, something like

def coerce_dtype(array:  NDArrayType, dtype_valid: bool) -> tuple[NDArrayType, bool]:
     return array, dtype_valid

• call in Interface.validate like

        # ...
        dtype_valid = self.validate_dtype(dtype)
        array, dtype_valid = self.coerce_dtype(array, dtype_valid)
        self.raise_for_dtype(dtype_valid, dtype)
        # ...

• override NumpyInterface.coerce_dtype to call validation.dtype.coerce_dtype, returning dtype_valid = True if coercion was successful.