From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 21 Aug 2013 10:34:38 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <6ee41a996f876d895cfdb23a2fda5a06@hamnavoe.com> References: <6ee41a996f876d895cfdb23a2fda5a06@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] comparisons with NaN Topicbox-Message-UUID: 73099f4e-ead8-11e9-9d60-3106f5b1d025 amd64 does yet something else. amd64 (a == b) (a >= b) (a > b) (b == a) (b >= a) (b > a) 386 (a < b) (a <= b) (a == b) (b < a) (b <= a) (b == a) arm (a < b) (a <= b) (a != b) (b < a) (b <= a) (b != a) mips (a < b) (a <= b) (a != b) (b < a) (b <= a) (b != a) > mainly the assumption, in the compiler and linker, that something like this: > if (a < b) f(); > can safely be transformed to this: > if (a >= b) goto skip; > f(); > skip: > Unfortunately if a or b is NaN, the conditional will be false in both cases. > > So is this a feature, or a bug that needs fixing? how about another option, just a bug. there are other issues with the floating point, including the fact that -0.0 is transformed both by the compiler, and by print(2) to 0.0. ape's printf prints -0.0 correctly. at least in terms of passing floating point test suites (like python's) the NaN issue doesn't come up, but the -0 issue breaks a number of tests. - erik