Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75681 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48273 invoked from network); 18 Jul 2014 04:18:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2014 04:18:51 -0000 Authentication-Results: pb1.pair.com header.from=tjerk.meesters@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tjerk.meesters@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender) X-PHP-List-Original-Sender: tjerk.meesters@gmail.com X-Host-Fingerprint: 209.85.220.173 mail-vc0-f173.google.com Received: from [209.85.220.173] ([209.85.220.173:47839] helo=mail-vc0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DC/F2-31967-920A8C35 for ; Fri, 18 Jul 2014 00:18:49 -0400 Received: by mail-vc0-f173.google.com with SMTP id hy10so6388617vcb.32 for ; Thu, 17 Jul 2014 21:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ikOu5cBU8dQiU4cZU3cwU1psLkQL9ps78kEIdqmiuU=; b=LeKFNhkz3Sh4yunnoJBt26rWyr9qtZqDP2ItDKQ5TySBsVy5hS0NEnMxGxAJBIntIG Q02jn8Z74Y0rwo9URD7vzq0Baxd/wOyX3nZMdTIuXEJrjb5R8IRMREyBoMhSjUYr8KvS g/rrW1YH1s4JnEFCYVRosk5OBWO70MT2N58CrxicHDvx20fC1Pk7y2AOxEtM+V6xFNPG SssH99VKsNJabDg31vZ9jYpOCVedVpjKOmds+g8stDXCiMy9tShYVgB5COe4hMmtweaN NmCt19I7tin1o5BBIuaMcYRy/7hwaQ+KjP85FyjP6fIkI192ih3CwK1PsyRELOivaSHV 2QdQ== MIME-Version: 1.0 X-Received: by 10.220.252.198 with SMTP id mx6mr1650254vcb.15.1405657126637; Thu, 17 Jul 2014 21:18:46 -0700 (PDT) Received: by 10.58.89.170 with HTTP; Thu, 17 Jul 2014 21:18:46 -0700 (PDT) In-Reply-To: References: <7646A8D1-69A2-4255-B048-D3B9F28B422F@ajf.me> <37F89E54-C5B9-4E81-9D1B-660190BDB1FF@ajf.me> Date: Fri, 18 Jul 2014 12:18:46 +0800 Message-ID: To: Kris Craig Cc: Andrea Faulds , Nikita Popov , Sara Golemon , bishop@php.net, PHP internals Content-Type: multipart/alternative; boundary=089e013a044ab597d604fe700d20 Subject: Re: [PHP-DEV] [RFC] intdiv() From: tjerk.meesters@gmail.com (Tjerk Meesters) --089e013a044ab597d604fe700d20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig wrote: > > > > On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters > wrote: > >> >> >> >> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig >> wrote: >> >>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote: >>> >>> > >>> > On 17 Jul 2014, at 10:24, Nikita Popov wrote: >>> > >>> > > This is already what is currently happening, see >>> > > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. >>> > > >>> > > Andreas proposal is only useful in the case that the numbers don't >>> divide >>> > > exactly and you need round-down/truncation behavior and your number= s >>> are >>> > in >>> > > a range where the indirection through double arithmetic results in >>> > > precision loss. >>> > >>> > It=E2=80=99s still useful regardless as it saves you implementing it = in terms >>> of >>> > floats. >>> > >>> > I mean, you can implement a right shift (rarely used outside bit >>> masks) in >>> > terms of multiplication and exponentiation, but that doesn=E2=80=99t = mean you >>> > shouldn=E2=80=99t have a right shift. >>> > >>> > -- >>> > Andrea Faulds >>> > http://ajf.me/ >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > >>> There seems to be a pretty even split on this. Personally, I'm a +1 fo= r >>> it. PHP has tons of obscure, rarely used functions. Even if the gain = is >>> relatively minor, there's really no cost that I can think of. So from = a >>> cost-benefit standpoint, even a minor improvement is still desirable wh= en >>> there's no practical downside to it. >>> >>> Given the number of options that are coming up, I'd suggest you break t= he >>> RFC down into two votes: A simple yes/no vote followed by an "if yes, >>> how >>> should it be implemented?" vote with the various options (the operators= , >>> functions, etc). If the RFC passes, then whichever option got a >>> plurality >>> of the votes would be the implemented option. >>> >> >> This makes it more complicated because a language change requires 2/3 >> majority while a new function requires 50% + 1. >> >> To make things simpler - and I believe it had been proposed before - the >> main vote should include the implementation as a function and the second= ary >> vote should be for the operator. >> >> >>> >>> So yeah, I'd say bring it to a vote and that'll settle it one way or >>> another. >>> >>> --Kris >>> >> >> >> >> -- >> -- >> Tjerk >> > > The problem is that, since that suggestion, other variations have been > proposed with no clear favorite. How should we decide *which* proposed > operator, for example? There have been several mentioned. > If the author can't settle on a particular operator, then a third vote would be necessary for those who vote to have an operator in the first place; perhaps a simple majority required for that. > > --Kris > > --=20 -- Tjerk --089e013a044ab597d604fe700d20--