Re: [RFC] intdiv()

On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters <tjerk.meesters@gmail.com> wrote: > > > > On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig <kris.craig@gmail.com> wrote: > >> >> >> >> On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters <tjerk.meesters@gmail.com >> > wrote: >> >>> >>> >>> >>> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig <kris.craig@gmail.com> >>> wrote: >>> >>>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds <ajf@ajf.me> wrote: >>>> >>>> > >>>> > On 17 Jul 2014, at 10:24, Nikita Popov <nikita.ppv@gmail.com> 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’s 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’t mean you >>>> > shouldn’t 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 for >>>> 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 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 secondary >>> 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