Add half-precision floats to `RtypesCores.h`

[enirolf]

Explain what you would like to see improved and how.

RtypesCores.h currently has Float16_t, which, according to the documentation, represents an (on-disk) 16-bit floating point number as a 32-bit with truncated mantissa in memory. This would correspond to a bfloat16. The IEEE standard however also prescribes a half-precision float which has a smaller exponent as well. There is an open PR (#13844) to add half-precision floats to RNTuple and for completeness it might be nice to properly make this a ROOT basic type.

Right now, there is no way to 'properly' represent this type, considering that half-precision floats will only become part of the standard library from C++23). There is the _Float16 type, but compatibility is compiler and architecture-specific. An option would be to represent the type as an unsigned short.

This issue is meant as way to discuss and decide how if and how this type can best be added.

ROOT version

master

Installation method

build from source

Operating system

all

Additional context

No response

[pcanal]

which, according to the documentation, represents a 16-bit floating point number written as a 32-bit number with truncated mantissa.

That seems reversed and/or ambiguous. Float16_t is 32 bits in memory and 16 bits on file (Same pattern as Double32_t which is 64 bits (per double) in memory and 32 bits on file).

To follow the pattern the new type should be HalfFloat_t: 16 bits in memory and 16 bits on file. And if (unlikely) we want to store less on file HalfFloat8_t: 16 bits in memory and 8 bits on file.

[enirolf]

That seems reversed and/or ambiguous. Float16_t is 32 bits in memory and 16 bits on file (Same pattern as Double32_t which is 64 bits (per double) in memory and 32 bits on file).

Whoops yes, you're right, I've fixed the description.

To follow the pattern the new type should be HalfFloat_t: 16 bits in memory and 16 bits on file.

The question is how to represent this in memory. From C++23 it will be obvious, but right now some compromise would be needed. There is the _Float16 type that works one some architectures with some compilers, but this is to brittle. The most portable solution would be to use an unsigned short/std::uint16_t, but this comes with the caveat that it must first be converted into a proper float or similar representation to do anything meaningful with it, which seems to go against the other typedefs in RtypesCore.h. Another option would be to do the same with Float16_t, where it is 16 bits on disk but still 32 bits in memory.

[pcanal]

I can only see 2 viable options. EIther we have a platform independent version that is 16 bits in memory (and 16 bits on file) or we explicitly only support it on the platform that do (where it will be 16 bits in memory and 16 bits on disk) and tweak the I/O so that on the other platforms they can be read in the larger types (directly)

[jblomer]

Here is my understanding:

• We add an RNTuple column type (i.e., on-disk representation) for IEEE half precision float
• We allow, on all platforms, reading a half precision on-disk float into an in-memory float or double
• When the time of f16 comes (C++23), we of course also enable reading a half precision on-disk float into the half precision in-memory type

Now:

• We add add a new typedef to float, whose name we need to agree on, e.g. FloatHalf_t. This new typedef is analogous to Float16_t. It indicates the users intent to store a float with half precision on-disk but to use it with single-precision in memory. Using the new typedef with RNTuple means that we store a float field, having its type alias set to FloatHalf_t, and an attached column of type kReal16.

The new typedef is not strictly necessary to use half precision floats. Users can enforce a certain column representation of fields and sub fields. But it makes it a lot easier to use "float-in-memory-half-on-disk" types as part of other types (classes, collections).

[pcanal]

< We add add a new typedef to float, whose name we need to agree on, e.g. FloatHalf_t. This new typedef is analogous to Float16_t. It indicates the users intent to store a float with half precision on-disk but to use it with single-precision in memory. Using the new typedef with RNTuple means that we store a float field, having its type alias set to FloatHalf_t, and an attached column of type kReal16.

I am confused. Here/above it seems to describe 'strictly' Float16_t i.e. "intent to store a float with half precision on-disk but to use it with single-precision". The difference with the new typedef (not always present) would be that the intent is to use half-of-single-precision in memory too.

[enirolf]

For RNTuple's current purposes, what Jakob proposes would suffice. It is also consistent with the way Float16_t is represented. The purpose of this issue was mostly to gauge whether this is indeed a reasonable addition since this change RtypesCore concerns the entire project and not just RNTuple, or if there are any strong reasons not to do it this way. In any case, I think making the in-memory representation platform-dependent will lead to confusion and potential errors.

[jblomer]

I am confused. Here/above it seems to describe 'strictly' Float16_t i.e. "intent to store a float with half precision on-disk but to use it with single-precision". The difference with the new typedef (not always present) would be that the intent is to use half-of-single-precision in memory too.

The Float16_t type is not half precision on disk. It is single precision with a shortened mantissa.

[pcanal]

Fair enough. We need to make that the distinction is clear.

[enirolf]

Based on the discussions regarding this PR I think that for now we should leave RtypesCore (and friends) alone. For the RNTuple use case we can use a less invasive solution until std::float16 is properly supported.