Fix double rounding in conversions to the custom float types (float64, integers, Python and NumPy scalars); fix a constructor crash on non-numeric strings

[EylonKrause]

Problem

Converting to any of the ml_dtypes float types double-rounds whenever the source is wider than float. Every conversion path narrows the source value to float first and only then to the target:

path	today
np.array(x, np.float64).astype(T) (also longdouble, complex128)	static_cast<To>(static_cast<float>(from))
np.array(n, np.int64).astype(T) (also uint64, int32, uint32)	same, via static_cast<float>
T(python_float)	T(double): exact for the float8 types, but Eigen's bfloat16(double) narrows to float first
T(python_int)	T(static_cast<float>(long))
T(np.int64(n)), T(np.float64(x)), T(np.longdouble(x)), …	the NumPy scalar is read through the float32 setitem

The first rounding (to float) can land exactly on a midpoint of the target format; the second rounding then resolves that spurious tie to even instead of picking the true nearest value.

input	true nearest	today
float64 -431.99999999999994 → float8_e4m3fn (neighbours −416 / −448)	−416	−448
float64 1 + 2⁻⁸ + 2⁻⁴⁰ → bfloat16 (neighbours 1 / 1.0078125)	1.0078125	1.0
int64 16973823 → bfloat16 (neighbours 16908288 / 17039360, midpoint 16973824)	16908288	17039360
int64 3·2³⁰ − 1 → float8_e8m0fnu (neighbours 2³¹ / 2³²)	2³¹	2³²
bfloat16(16973823), bfloat16(np.int64(16973823))	16908288	17039360
bfloat16(1 + 2⁻⁸ + 2⁻⁴⁰), bfloat16(np.longdouble(…))	1.0078125	1.0

NumPy's own int64 → float16 and float64 → float16 casts are single-rounded on the same inputs, which is what users expect from a dtype.

Fix

Narrow the wide source to float with round-to-odd before the final rounding. This makes the subsequent round-to-nearest-even exact for any target with at least two fewer significand bits than float (Boldo & Melquiond, When double rounding is odd, 2005), which holds for every type here (bfloat16: 8 bits, float8: ≤ 4). It is the trick float8_base::ConvertFrom already applies for long double.

• NarrowToFloatRoundToOdd (float64 / long double) — as in the first commit.
• IntegerToFloatRoundToOdd (32/64-bit integers): keep the top 24 bits, fold any dropped bit into the lowest kept bit, scale back with an exact ldexp.
• One NarrowToFloat entry point (exact when the value fits in a float, round-to-odd otherwise) used by the NumPy cast kernel and by all three scalar-constructor paths. NumPy scalars are now read at full width (long long / unsigned long long / long double by scalar kind) instead of through the float32 setitem, so T(np.float64(x)) and T(np.array([x]).astype(T)[0]) agree.
• The setitem result is now checked: before, a failing conversion (e.g. bfloat16(np.datetime64(...))) returned garbage with an exception left set, which surfaced as SystemError: returned a result with an exception set; the conversion's own error propagates now.
• Second commit, found while reviewing that path: bfloat16("abc") (any custom float built from a string that is not a number) segfaults on main — the constructor passes the null result of PyFloat_FromString straight into CastToCustomFloat, which dereferences it (and on success the parsed float was never released). It now raises the parser's ValueError, and the constructor and array setitem return a conversion's own error instead of replacing it with a generic TypeError, mirroring ints.cc.

Validation

• Exhaustive oracle sweep (nearest representable value, ties to even by encoding) for every type: float64 → T over all float16 values plus every midpoint ± 1 float64 ulp — before: e4m3fn 252, e5m2 246, e4m3b11fnuz 254, e4m3fnuz 254, e5m2fnuz 254, e3m4 222, e2m1fn 14, e2m3fn 62, e3m2fn 62, bfloat16 65 278 mismatches; after: 0 for every type. int64/uint64 → bfloat16 over integers next to every midpoint in [2²⁴, 2⁶²): before 156/468 mismatches, after 0.
• The only remaining float8_e8m0fnu mismatches are exact ties / its lowest binade, i.e. e8m0's own float → e8m0 rounding, which Round exact ties to nearest-even when converting to float8_e8m0fnu #398 fixes separately; the tests restrict themselves to float32-normal midpoints so they do not depend on Round exact ties to nearest-even when converting to float8_e8m0fnu #398.
• Tests: testCastFromFloat64DoesNotDoubleRound, testCastFromInt64DoesNotDoubleRound, testConstructFromScalarDoesNotDoubleRound (Python int/float, NumPy int32/uint32/int64/uint64/float64/longdouble scalars), for every parameterized type. Each fails without the corresponding fix; the full custom_float_test.py passes with -W error (2195 passed, 3 runs) and so does the rest of the suite (2752 passed).
• testConstructFromInvalidValueRaises: str/bytes/np.str_ garbage raises ValueError (was a segfault / a SystemError), np.datetime64 raises, numeric strings still parse.
• Edge cases checked by hand: INT64_MIN, UINT64_MAX, -0.0 sign, NaN/±inf, overflow (float8_e4m3fn(1e300) still NaN), complex128 (real part, ComplexWarning kept), np.bool_, np.str_, scalars of the other ml_dtypes types.

Disclosure: this contribution was authored with an AI coding assistant (Claude) and reviewed and validated before submission.

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[EylonKrause]

@googlebot I signed it!

[hawkinsp]

Sorry for the slow review, this seems like a good fix.

Please squash your commits.

[hawkinsp]

Duplicate cmath include.

[hawkinsp]

I gather the long double parsing path is actually a bit quirky. I would have a check for long double specifically and then have the else case go via double.

[hawkinsp]

I think you could add a fast path of this form
if ((magnitude >> kFloatDigits) == 0) return static_cast(from);

[hawkinsp]

Test negative integers as well?

[hawkinsp]

Test negative integers?