[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Signaling NaNs
Re: Signaling NaNs
Thu, 09 Dec 2021 22:49:37 +0100
> I have been searching through the list of modules but haven't been able to
> find it: Does Gnulib offer a way to store a signaling NaN in a memory
> location (if supported by the platform)
It doesn't, because quiet NaNs are easier to work with.
> The forthcoming C2x standard will have FLT_SNAN, DBL_SNAN, and LDBL_SNAN,
> but before that there doesn't seem to be a portable way to get signaling
... indeed, when you have a non-optimizing compiler, how to prevent the
compiler from generating instructions that produce a floating-point exception
earlier than desired?
> and some way to check a memory
> location whether it contains a signaling NaN?
Why would you need that? If you are using floating-point operations
(such as addition, square root, etc.) the signaling NaN will produce an
exception, as desired. Whereas if you are implementing some extra floating-
point operation by looking at the precise bit pattern (using integer
arithmetic), the standards  tell you which bit pattern to look for.
> In case the following problem is easier: What I really need is a bit
> pattern for a double that won't be returned by the usual floating-point
When you look at  and , all bit patterns have a meaning.
So, you could
- either use one of the many particular quiet NaN values, and hope that
no other code produces it, or
- (like what the IA64 CPU does in hardware) work with 65-bit units,
where the 65th bit means "uninitialized", or
- reserve a couple of extra bits for a type tag on every value, like
what some Lisp implementations do (e.g. GNU clisp).
I think valgrind uses one of the latter two techniques as well.
- Signaling NaNs, Marc Nieper-Wißkirchen, 2021/12/09
- Re: Signaling NaNs,
Bruno Haible <=