ExecuTorch Scalar to() supports fewer types than c10::Scalar, breaking source compatibility

[swolchok]

🐛 Describe the bug

some_scalar.to<float>() is legal for c10::Scalar, but not ExecuTorch's Scalar. https://github.com/pytorch/executorch/blob/main/runtime/core/portable_type/scalar.h#L26 says it is a "source-compatible subset" of c10::Scalar.

Versions

main

cc @larryliu0820 @JacobSzwejbka

[ahbpp]

Hi @swolchok

I would be happy to work on this issue

Adding to<float>() looks like a quick fix.

I'm also happy to add support for other types, but I'm unsure which types should be supported.

It looks like c10::Scalar supports AT_FORALL_SCALAR_TYPES_WITH_COMPLEX + uint16/32/64_t (see: https://github.com/pytorch/pytorch/blob/29b3fdab0178d88a897ca48b85d1f7893d906ae0/c10/core/Scalar.h#L141), which includes various ints, floats and c10:complex types.

I was thinking about adding a similar implementation for exectutorch Scalar (but with executorch::runtime::etensor::complex instead of c10:complex). Does that sound like the right direction?

But I'm also happy to fix to<float>() issue first

[JacobSzwejbka]

@ahbpp yes that sounds like the right direction. I'm happy to review any PRs you put up or provide further guidance if needed

[ahbpp]

Hi @JacobSzwejbka

I created a PR implementing the to method for float, ::executorch::runtime::etensor::Half, and ::executorch::runtime::etensor::BFloat16, but I need advice on the best (expected) way to implement more complex logic:

1. I'm thinking about whether it’s better to create a separate TypeCast.h for typecasting (similar to PyTorch c10). Would this be better than having the casting code in the Scalar class?
2. For overflow logic, is it better to copy c10::overflows.h to related executorch/runtime/core/portable_type/c10 or create a separate overflow.h file somewhere in executorch/runtime/core/portable_type ?