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

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

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 ?