On a similar tangent to the idea I presented in another thread of re-using the
top byte of a 32bit code containing a Unicode code point in the lower bits,
there is a space of NaN representations in a double that could be overlaid
to store or transport data or control metadata in the same channel.

Under what circumstances would a language implementation wish to
use NaN codes overlaid in IEEE doubles?

On 07/11/2022 21:21, luserdroog wrote:

> On a similar tangent to the idea I presented in another thread of re-using the
> top byte of a 32bit code containing a Unicode code point in the lower bits,
> there is a space of NaN representations in a double that could be overlaid
> to store or transport data or control metadata in the same channel.
>
> Under what circumstances would a language implementation wish to
> use NaN codes overlaid in IEEE doubles?

Hard to say. What you suggest sounds a bit like a solution looking for a
problem. It may be better to get everything working with floats and
metadata occupying separate fields and only combine them later as an
optimisation, if you still think it's doable at that time.

--
James Harris

keep in mind that not all hardware leaves the nan bits alone.

it seems to be more common of late thast they specify that all nan
results are canonical nans. whether signalling or quiet.

that was why R stopped using a specific nan payload to represent its NA
(Not Available) value. and canonical-only has only gotten more common
since then.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6