Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86681 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97467 invoked from network); 15 Jun 2015 21:00:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jun 2015 21:00:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=bishop.bettini@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bishop.bettini@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender) X-PHP-List-Original-Sender: bishop.bettini@gmail.com X-Host-Fingerprint: 209.85.215.47 mail-la0-f47.google.com Received: from [209.85.215.47] ([209.85.215.47:34012] helo=mail-la0-f47.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C7/13-15639-EEC3F755 for ; Mon, 15 Jun 2015 17:00:31 -0400 Received: by labbc20 with SMTP id bc20so29790937lab.1 for ; Mon, 15 Jun 2015 14:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jZNXQWp4tRP0uLw+aoHfvDqEvnk62+NF50I1TuOQPy4=; b=QOJJk65lt0CfPhrc/ax4MY0g517WLvrrUUeeoQGKKzfj1AKz0dmVHTNQUy0Zq/94Ca 4/80yKXy3dMHSQ5mm2JE3ix7OYB71bFJdyJHyEedqz3QP22qNX2yHBoqz8CYCZ643qlE CBLtzeUwkfupmIFbtJT3MLvIxQTxt3oO3Z98yb1l7S/iwJ89jbWa3CO7ONAeSqiO6ylx R2SmnfWqb70vrW12dXfy+ilmB6EP/bhnsxU4g7Tq5tCaz2vnr35Z9GJ+D/OYYL/xfbNO HOzL59TEoF/IBj/9086X32DGcDZuV/vzam17BLdHX0YZrKOoGFbf1BggvuaqEKRTGCcH UQjg== MIME-Version: 1.0 X-Received: by 10.112.204.199 with SMTP id la7mr1957285lbc.114.1434402027584; Mon, 15 Jun 2015 14:00:27 -0700 (PDT) Reply-To: bishop@php.net Sender: bishop.bettini@gmail.com Received: by 10.152.6.197 with HTTP; Mon, 15 Jun 2015 14:00:27 -0700 (PDT) In-Reply-To: <06AFCBA8-CEB0-4AC1-BB72-ACA6213F4334@gmail.com> References: <06AFCBA8-CEB0-4AC1-BB72-ACA6213F4334@gmail.com> Date: Mon, 15 Jun 2015 17:00:27 -0400 X-Google-Sender-Auth: z3U5WzNCBUEIR7eDG8-AsJzGJYk Message-ID: To: Rowan Collins Cc: PHP Internals Content-Type: multipart/alternative; boundary=001a11c3bb3051c20b051894bf46 Subject: Re: [PHP-DEV] Spaceship and NaNs From: bishop@php.net (Bishop Bettini) --001a11c3bb3051c20b051894bf46 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 4:45 PM, Rowan Collins wrote: > On 15 June 2015 20:55:04 BST, Bob Weinand 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 --001a11c3bb3051c20b051894bf46--