Fix incorrect CPU float16 implementation

[eliasachermann]

Problem

The dace::half fallback in dace/runtime/include/dace/types.h is broken in two independent ways:

1. No default constructor.
   Generated code that declares an uninitialized dace::float16 fails to compile:

   error: no matching function for call to 'dace::half::half()'
   

2. Incorrect conversions.
   The float↔half conversion is wrong for zero, subnormals, Inf/NaN, and does no rounding.

Fix

• Replace both conversions with IEEE-754 round-to-nearest-even routines, correctly handling zero, subnormals, overflow→Inf and Inf/NaN.
• Add a default constructor.

Tests

Adds tests/half_cpu_test.py, to test the conversion against NumPy as the reference.

[ThrudPrimrose]

We need subnormal, inf and NaN in roundtrip tests to ensure we handle them correctly.

[ThrudPrimrose]

Can you add a subnormal number to your tests?

[eliasachermann]

Added inf and nan tests

[acalotoiu]

LGTM

[ahmadbelb]

@eliasachermann @ThrudPrimrose Quick follow up. On ARMv8.2-A targets built with the FP16 arithmetic extension (+fp16 / FEAT_FP16, which Apple Silicon has), _Float16 lowers to native fp16 instructions. So we could use it directly there and keep the software half as the fallback for x86 and anything without native fp16.

#elif (defined(__aarch64__) || defined(__arm64__)) && defined(__FLT16_MANT_DIG__)
    typedef std::complex<float> complex64;
    typedef std::complex<double> complex128;
    typedef _Float16 float16;   // native ARM hardware fp16
#else

@ThrudPrimrose Not sure if ARM is something you want to support here, but if it is I'm happy to open a
separate PR for this, or add it here if that's easier. What do you think?

[ThrudPrimrose]

@eliasachermann @ThrudPrimrose Quick follow up. On ARMv8.2-A targets built with the FP16 arithmetic extension (+fp16 / FEAT_FP16, which Apple Silicon has), _Float16 lowers to native fp16 instructions. So we could use it directly there and keep the software half as the fallback for x86 and anything without native fp16.

#elif (defined(__aarch64__) || defined(__arm64__)) && defined(__FLT16_MANT_DIG__)
    typedef std::complex<float> complex64;
    typedef std::complex<double> complex128;
    typedef _Float16 float16;   // native ARM hardware fp16
#else

@ThrudPrimrose Not sure if ARM is something you want to support here, but if it is I'm happy to open a separate PR for this, or add it here if that's easier. What do you think?

This would be a nice extension in my opinion.

Once this PR is merged, I would propose that you open a new PR on top of what has merged such that we have native fp16 support for corresponding ARM target. I also know that latest avx512 instruction sets also have native fp16, could be nice to also support them.