* Signaling NaNs
@ 2021-12-09 21:18 Marc Nieper-Wißkirchen
2021-12-09 21:49 ` Bruno Haible
0 siblings, 1 reply; 4+ messages in thread
From: Marc Nieper-Wißkirchen @ 2021-12-09 21:18 UTC (permalink / raw
To: bug-gnulib@gnu.org List
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
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) and some way to check a memory
location whether it contains a signaling NaN?
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
NaNs.
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
functions.
Thanks,
Marc
[-- Attachment #2: Type: text/html, Size: 1332 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Signaling NaNs
2021-12-09 21:18 Signaling NaNs Marc Nieper-Wißkirchen
@ 2021-12-09 21:49 ` Bruno Haible
2021-12-10 7:57 ` Marc Nieper-Wißkirchen
0 siblings, 1 reply; 4+ messages in thread
From: Bruno Haible @ 2021-12-09 21:49 UTC (permalink / raw
To: bug-gnulib; +Cc: Marc Nieper-Wißkirchen
Hi Marc,
> 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
> NaNs.
... 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 [1][2] 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
> functions.
When you look at [1] and [2], 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.
Bruno
[1] https://en.wikipedia.org/wiki/Single-precision_floating-point_format
[2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Signaling NaNs
2021-12-09 21:49 ` Bruno Haible
@ 2021-12-10 7:57 ` Marc Nieper-Wißkirchen
2021-12-10 9:13 ` Bruno Haible
0 siblings, 1 reply; 4+ messages in thread
From: Marc Nieper-Wißkirchen @ 2021-12-10 7:57 UTC (permalink / raw
To: Bruno Haible; +Cc: Marc Nieper-Wißkirchen, bug-gnulib@gnu.org List
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
Hi Bruno,
thanks for replying so quickly!
My intention is neither to feed the signaling NaN into floating-point
operations nor to cause it an exception to be raised. What I really want
to do is to model a type whose value is either a floating-point number
(including infinities and the NaNs returned by the floating-point
functions) or a sentinel value. Furthermore, I want this to fit into the
size of a double.
The reason why I thought of using the bit pattern of a signaling NaN is
that such a signaling NaN wouldn't be returned by the usual floating-point
functions. A quiet NaN, which wouldn't either, would also work for my
purpose. This would correspond to the first of your three suggestions. So
I could reformulate my question to: "Is there a way to produce a (quiet)
NaN that won't occur as a result of the C library functions?" This seems to
be possible on most architectures but will need specific code for some
architectures, which is why I thought of Gnulib.
Thanks,
Marc
Am Do., 9. Dez. 2021 um 22:49 Uhr schrieb Bruno Haible <bruno@clisp.org>:
> Hi Marc,
>
> > 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
> > NaNs.
>
> ... 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 [1][2] 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
> > functions.
>
> When you look at [1] and [2], 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.
>
> Bruno
>
> [1] https://en.wikipedia.org/wiki/Single-precision_floating-point_format
> [2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4498 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Signaling NaNs
2021-12-10 7:57 ` Marc Nieper-Wißkirchen
@ 2021-12-10 9:13 ` Bruno Haible
0 siblings, 0 replies; 4+ messages in thread
From: Bruno Haible @ 2021-12-10 9:13 UTC (permalink / raw
To: Marc Nieper-Wißkirchen; +Cc: bug-gnulib
Marc Nieper-Wißkirchen wrote:
> I could reformulate my question to: "Is there a way to produce a (quiet)
> NaN that won't occur as a result of the C library functions?"
There are 2^51 possible quiet NaNs [1]. I would guess that the hardware and
libc functions produce only a small portion of this space (because what
would be the point of encoding additional information in the result of
0.0 / 0.0, sqrt(-31.2), acos(-1.4), etc.?). But I don't really know.
You would need to find out yourself.
Bruno
[2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-12-10 9:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-09 21:18 Signaling NaNs Marc Nieper-Wißkirchen
2021-12-09 21:49 ` Bruno Haible
2021-12-10 7:57 ` Marc Nieper-Wißkirchen
2021-12-10 9:13 ` Bruno Haible
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).