On Mon, Jun 15, 2015 at 4:45 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 15 June 2015 20:55:04 BST, Bob Weinand <bobw...@hotmail.com> wrote: > >As far as I know, we made it that way in order to enforce an int return > >type all the time. > >int(-1) is indeed the sensible value for this. (Mainly int(0) does not > >work because it'd mean equality and so we're left with int(-1) and > >int(1).) > > > >Just because other comparison ops already return a bool, we can return > >bool(false) there. > > This makes a lot of sense. If it returned false, that would just be cast > to 0 in most situations, implying that NaN is equal to everything (rather > than nothing). In other situations, it would simply lead to an error. The > operator would lose much of its value if it had to be surrounded with error > traps and caveats because it didn't reliably return an integer. > Convenience aside, I think it has to be false, or an ERROR, or something other than int. Clause 5.11, paragraph 2 of the 754-2008 standard reads: Four mutually exclusive relations are possible: less than, equal, greater > than, and unordered. The last case arises when at least one operand is NaN. > Every NaN shall compare unordered with everything, including itself. Personally, I'd vote false for consistency and immediacy. Then, I'd suggest we look at handling NaN more predictably. Pretty much whenever NaN enters as a data point, the end result will be NaN, and I want to know that as early as possible. Like an ERROR. bishop
