Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75682 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50695 invoked from network); 18 Jul 2014 04:34:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2014 04:34:15 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.49 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 209.85.219.49 mail-oa0-f49.google.com Received: from [209.85.219.49] ([209.85.219.49:45497] helo=mail-oa0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BA/73-31967-6C3A8C35 for ; Fri, 18 Jul 2014 00:34:15 -0400 Received: by mail-oa0-f49.google.com with SMTP id eb12so2286317oac.36 for ; Thu, 17 Jul 2014 21:34:12 -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=mn144I2OoXb/yniROyq4w2Wbg6ghm8QKxFKytYi6Kzk=; b=Pt44NxUPuqCMAPLPsC2i194kOKDwCo2c4ri0EI1LaEg5v4MhTZ41wSsQzxUPa2VRoa tZdwsX+tHAIziVtyk7JKdJ9TCd4vZgMkPT2TneTUtFoH+S2Utaa+e1Fo4rNMp0RNExOx qaFed14Qn2phJWYDPaCPlmZEM/MPARZF/fYfLOoDpKfcY/pvEQQZyuxfSD9NS3aTT6a4 SDbAzqby0DTJ99mv6udGeRUrg/J0rk6R09DoOQOwqw76IzQzIIT3yuwnK6q5+dbcLqd5 iKaYwkwKBVUOWebkfqh8ZKk/qrO8m6Ov6F0gen2JB3nPudp4HwHN8gh3Zxmrnab15dgy TMHg== MIME-Version: 1.0 X-Received: by 10.182.236.225 with SMTP id ux1mr2145131obc.57.1405658051744; Thu, 17 Jul 2014 21:34:11 -0700 (PDT) Received: by 10.202.15.72 with HTTP; Thu, 17 Jul 2014 21:34:11 -0700 (PDT) In-Reply-To: References: <7646A8D1-69A2-4255-B048-D3B9F28B422F@ajf.me> <37F89E54-C5B9-4E81-9D1B-660190BDB1FF@ajf.me> Date: Thu, 17 Jul 2014 21:34:11 -0700 Message-ID: To: Tjerk Meesters Cc: Andrea Faulds , Nikita Popov , Sara Golemon , bishop@php.net, PHP internals Content-Type: multipart/alternative; boundary=001a11c2fad0d9985b04fe7044d9 Subject: Re: [PHP-DEV] [RFC] intdiv() From: kris.craig@gmail.com (Kris Craig) --001a11c2fad0d9985b04fe7044d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters wrote: > > > > 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 >>>> numbers 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 f= or >>>> 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 >>>> when >>>> there's no practical downside to it. >>>> >>>> Given the number of options that are coming up, I'd suggest you break >>>> the >>>> 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 operator= s, >>>> 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 - th= e >>> main vote should include the implementation as a function and the secon= dary >>> 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 >> >> > > > -- > -- > Tjerk > Hmm ok that sounds reasonable. --Kris --001a11c2fad0d9985b04fe7044d9--