From: Damian McGuckin <damianm@esi.com.au>
To: musl@lists.openwall.com
Subject: Re: FE Exception triggered by comparison
Date: Mon, 25 Feb 2019 08:50:52 +1100 (AEDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1902250826020.8962@key0.esi.com.au> (raw)
In-Reply-To: <20190224210438.6980bd87@inria.fr>
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
next prev parent reply other threads:[~2019-02-24 21:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-24 13:28 Damian McGuckin
2019-02-24 17:12 ` Markus Wichmann
2019-02-24 19:25 ` Szabolcs Nagy
2019-02-24 20:04 ` Jens Gustedt
2019-02-24 21:50 ` Damian McGuckin [this message]
2019-02-25 5:21 ` Damian McGuckin
2019-02-25 15:51 ` Markus Wichmann
2019-02-26 3:55 ` Damian McGuckin
2019-02-27 14:14 ` Alexander Monakov
2019-02-27 15:38 ` Damian McGuckin
2019-02-27 16:00 ` Alexander Monakov
2019-02-27 16:09 ` Damian McGuckin
2019-02-27 16:14 ` Markus Wichmann
2019-02-27 16:20 ` Damian McGuckin
2019-02-28 1:07 ` Damian McGuckin
2019-02-28 1:27 ` Rich Felker
2019-02-28 2:28 ` Damian McGuckin
2019-02-27 16:32 ` Alexander Monakov
2019-02-27 16:42 ` Rich Felker
2019-02-27 17:08 ` Szabolcs Nagy
2019-02-27 17:14 ` Alexander Monakov
2019-02-27 17:26 ` Rich Felker
2019-02-27 19:36 ` Szabolcs Nagy
2019-02-27 19:48 ` Alexander Monakov
2019-02-27 20:16 ` Szabolcs Nagy
2019-02-27 20:35 ` Rich Felker
2019-02-27 21:03 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.02.1902250826020.8962@key0.esi.com.au \
--to=damianm@esi.com.au \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).