[msluszniak]

Description

Adds Float16Array to the TensorBuffer union so users running fp16-exported models can pass half-precision inputs ergonomically alongside the already-defined ScalarType.HALF. The native input path at JsiConversions.h already reads the underlying ArrayBuffer raw and forwards the integer scalarType, so no native changes are needed — TS 5.9 ships Float16Array in lib.esnext.float16.d.ts and the package targets ESNext.

bfloat16 is intentionally left out: JS has no BFloat16Array, so callers who need it can still pack the raw bytes into an ArrayBuffer (or a Uint16Array view) — this is now noted in the docs.

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

• tsc --noEmit on packages/react-native-executorch passes.
• Construct a TensorPtr with dataPtr: new Float16Array(...) and scalarType: ScalarType.HALF; type-checks and forwards to ExecuTorch as half-precision.

Screenshots

Related issues

Partially addresses #373 (fp16 only; bf16 has no JS TypedArray and is out of scope here).

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

[chmjkb]

Have you verified this works? IIRC hermes doesn't support Float16Array, so this could crash:
https://github.com/facebook/hermes/blob/main/include/hermes/VM/TypedArrays.def
microsoft/onnxruntime#27548

[msluszniak]

Have you verified this works? IIRC hermes doesn't support Float16Array, so this could crash: https://github.com/facebook/hermes/blob/main/include/hermes/VM/TypedArrays.def microsoft/onnxruntime#27548

Ok, I tested and indeed it failed. So I will close this issue with the accurate message.