mailing list of musl libc
 help / color / mirror / code / Atom feed
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


  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).