[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Feb 2019 08:50:52 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: FE Exception triggered by comparison
Hi Markus, Jens,
Thanks for the replies.
On Sun, 24 Feb 2019, Jens Gustedt wrote:
>> with c99 annex F, c == and != operators are mapped to ieee 754
>> compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
>> but signals invalid with sNaN inputs, so in practice sNaN != sNaN
>> will signal in c.
I guess I am still trying to figure out where/when sNaN will appear so I
can code defensively to protect my code. The C interface like 'isless' and
friends are really woeful performers.
>> i think it's better to look at the ieee 754 spec instead
>> of the c spec, drafts are at http://754r.ucbtest.org/drafts/
I agree. But while I found the 1985 standard readable and clear, all the
subsequent revisions have sections, especially related to exceptions, that
are difficult to comprehend. And I thought I spoke English. The language
is convoluted.
> Yes, we are currently integrating parts 1 and 2 of this TS into the
> standard. Usually you should be able to see a first version of that in
> a few weeks in the pre-London mailing.
Thanks.
> For the moment they are integrated "as such" that is with "WANT"
> macros that make these "new" interfaces optional.
Hmmm. Scary. I
The context of this is that I want a coding style which means I can
compare numbers without affecting the exception state. And it must have
zero overhead, and not affect the readability of the code, i.e. no
function calls.
I want to know that
x != x
will always detect any NaN with affecting the exception status and that
comparisons like
if (x == x) { ... }
else if (x > y) { .... }
else if (x < y) { .... }
else { x or y are NaN }
will similarly also not modify the exception status, and in the last
section let me process how I interpret the NaNs.
Otherwise, avoidance of creating spurious exceptions forces you to start
working at the IEEE 754 encoding level. This is counterproductive to clear
and concise programming. Such a style is riddled through a lot of the
maths routines in MUSL and the libraries that came before it. It also
means that all these magic constants start to appear in the code, severely
affecting comprehensibility. Any generic coding style is just stopped in
its tracks.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
