Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30 Jul 2014, at 03:31, Andrea Faulds a...@ajf.me wrote: The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC] intdiv()” thread and the whole RFC before voting. The vote is here: https://wiki.php.net/rfc/intdiv#vote It is opened today (2014-07-30) and ends 2014-08-06. Hi! Voting has ended. The operator vote failed to reach the required 2/3 majority receiving 5 votes in favour and 24 votes against, while the function fallback proposal has been unanimously approved with 28 votes in favour. I’ll merge the function into master shortly. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30/07/2014 04:31, Andrea Faulds wrote: Good evening, The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC] intdiv()” thread and the whole RFC before voting. The vote is here: https://wiki.php.net/rfc/intdiv#vote It is opened today (2014-07-30) and ends 2014-08-06. After speaking with some other members of AFUP (French user-group) about this RFC, here's a short summary of our thoughts, which may sound like an echo to the current results of the vote: * Adding a new operator for a quite specific case seems a bit overkill: it probably won't be used much * Adding a new intdiv() function: why not? Basically, adding a new operator doesn't feel OK for something that wouldn't be used often, as it has some impact on the language itself. But adding a new function feels more OK, as long as it solves a problem (it does, here), as it is only a function, with no impact on the language. As a sidenote: wouldn't using GMP solve this problem, by working with infinite precision integers instead of floats? If so and if using GMP would be a good/better idea, a note about that on intdiv()'s manual page might prove useful for end-users? -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 3 Aug 2014, at 05:39, Kris Craig kris.cr...@gmail.com wrote: Agreed. I'd very much like to see another RFC that proposes more options for creating an operator for this. The vote against %% on this RFC should not be construed-- in my opinion, at least-- as a consensus against having any kind of operator for intdiv. To save hassle, could I not modify the current RFC and hold another vote? I don’t see why we’d need an entirely new RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 03/08/14 12:52, Andrea Faulds wrote: Agreed. I'd very much like to see another RFC that proposes more options for creating an operator for this. The vote against %% on this RFC should not be construed-- in my opinion, at least-- as a consensus against having any kind of operator for intdiv. To save hassle, could I not modify the current RFC and hold another vote? I don’t see why we’d need an entirely new RFC. That the principle of sorting out 64 bit division is accepted is fairly obvious from the current stated of the vote? Personally I still view this as part of the general debate on just how 64bit integers are supported by default in new builds of PHP, in which situation, simply throwing a new operator at it is not fixing the basic fault in (int)(3 / 2)? Having to decided is one needs a different operator on 64bit systems is still wrong what ever that operator is? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 3 Aug 2014, at 13:24, Lester Caine les...@lsces.co.uk wrote: That the principle of sorting out 64 bit division is accepted is fairly obvious from the current stated of the vote? Personally I still view this as part of the general debate on just how 64bit integers are supported by default in new builds of PHP, in which situation, simply throwing a new operator at it is not fixing the basic fault in (int)(3 / 2)? Having to decided is one needs a different operator on 64bit systems is still wrong what ever that operator is? You don’t need a different operator on 64-bit systems, the point is that using (int) with / is an ugly hack that just so happens to only break on 64-bit systems. You could do 3 %% 2 or intdiv(3, 2) on both 32-bit or 64-bit. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Sunday, August 03, 2014 2:52 PM To: Kris Craig Cc: Chris Wright; Adam Harvey; PHP internals Subject: Re: [PHP-DEV] [VOTE][RFC] intdiv() On 3 Aug 2014, at 05:39, Kris Craig kris.cr...@gmail.com wrote: Agreed. I'd very much like to see another RFC that proposes more options for creating an operator for this. The vote against %% on this RFC should not be construed-- in my opinion, at least-- as a consensus against having any kind of operator for intdiv. Based on the discussion on internals@ I'm not sure why it should not be construed as consensus against any kind of operator for intdiv. Quite the contrary, those who opposed it (myself included) opposed it on the grounds that it's not nearly commonly used to be worth a dedicated operator. Quoting one of those who opposed, IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/ (note both the operator being different from the one that ended up being proposed in the RFC, and the key objection being the necessity of needing this as an operator in the first place). To save hassle, could I not modify the current RFC and hold another vote? I don't see why we'd need an entirely new RFC. I think that the best way to save us all hassle is to accept that there's overwhelming majority against introducing a dedicated operator for this use case... I think a revote should be considered only if you come up with a concrete alternative, and you get a pretty good reason to believe that the results will be different (e.g. by asking 5-10 people who voted 'no' on the current RFC and getting a 'yes' from at least some of them). We need to be respectful of people's time - and generally not assume that something that was voted upon and rejected, will be accepted after minor mods. My 2c. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 3 Aug 2014, at 13:51, Zeev Suraski z...@zend.com wrote: Based on the discussion on internals@ I'm not sure why it should not be construed as consensus against any kind of operator for intdiv. Quite the contrary, those who opposed it (myself included) opposed it on the grounds that it's not nearly commonly used to be worth a dedicated operator. Quoting one of those who opposed, IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/ (note both the operator being different from the one that ended up being proposed in the RFC, and the key objection being the necessity of needing this as an operator in the first place). To save hassle, could I not modify the current RFC and hold another vote? I don't see why we'd need an entirely new RFC. I think that the best way to save us all hassle is to accept that there's overwhelming majority against introducing a dedicated operator for this use case... I think a revote should be considered only if you come up with a concrete alternative, and you get a pretty good reason to believe that the results will be different (e.g. by asking 5-10 people who voted 'no' on the current RFC and getting a 'yes' from at least some of them). We need to be respectful of people's time - and generally not assume that something that was voted upon and rejected, will be accepted after minor mods. Right. While I’d love to hold another vote and get it in, I know it’s not going to happen. Just switching to %/ or something is not going to really change the general consensus against the need for %%. At best, it might mean one more vote in favour but it’s hardly going to swing it. Unless someone presents me a proposal that will somehow get this a 2/3 majority and actually pleases everyone, it’s not going to be reopened. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 03/08/14 13:49, Andrea Faulds wrote: That the principle of sorting out 64 bit division is accepted is fairly obvious from the current stated of the vote? Personally I still view this as part of the general debate on just how 64bit integers are supported by default in new builds of PHP, in which situation, simply throwing a new operator at it is not fixing the basic fault in (int)(3 / 2)? Having to decided is one needs a different operator on 64bit systems is still wrong what ever that operator is? You don’t need a different operator on 64-bit systems, the point is that using (int) with / is an ugly hack that just so happens to only break on 64-bit systems. You could do 3 %% 2 or intdiv(3, 2) on both 32-bit or 64-bit. Your missing the point I was trying to make. That (int)(3 / 2) essentially goes wrong only on 64bit systems is the bug that needs fixing. The mistake is having now to use intdiv() just in case an overflow does occur which was not present on the 32bit version? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 3 Aug 2014, at 15:27, Lester Caine les...@lsces.co.uk wrote: Your missing the point I was trying to make. That (int)(3 / 2) essentially goes wrong only on 64bit systems is the bug that needs fixing. (int)(3 / 2) works fine, (int)(PHP_INT_MAX / 3) does not. It’s not a bug, it’s entirely intentional and expected behaviour. You’re doing a floating-point division then casting to integer, which will sometimes lead to a loss of precision. And no, having a division wrapped in (int) work differently from a normal division isn’t a good idea. That means the operator acts differently based on context. It would mean $a = PHP_INT_MAX / 3; $a = (int)$a; would do something entirely different from $a = (int)(PHP_INT_MAX / 3); -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 03/08/14 15:31, Andrea Faulds wrote: Your missing the point I was trying to make. That (int)(3 / 2) essentially goes wrong only on 64bit systems is the bug that needs fixing. (int)(3 / 2) works fine, (int)(PHP_INT_MAX / 3) does not. It’s not a bug, it’s entirely intentional and expected behaviour. You’re doing a floating-point division then casting to integer, which will sometimes lead to a loss of precision. And no, having a division wrapped in (int) work differently from a normal division isn’t a good idea. That means the operator acts differently based on context. It would mean $a = PHP_INT_MAX / 3; $a = (int)$a; would do something entirely different from $a = (int)(PHP_INT_MAX / 3); It may be 'entirely intentional' but that both 32bit and 64bit systems have a binary64 format double may then be wrong? Since most of the processors we are working on these days have quadruple and better precision available, if the '64bit' configuration switched to binary128 floating point, then things work in the same way that they do on 32bit platforms. It's cherry picking individual elements which hides the other aspects of an overview of the problem, and looking at the ranges involved with BIGINT, one either handles the processing via the intdiv() approach, but fixing the range problem on float is an alternative for PHPNext? Of cause no longer relying on 'second' as a base unit is another option, and day based calendar functions will outlive the 52bit rollover ... What ever happened to the x86 80bit precision floating point which had a 64bit fraction ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On Thu, Jul 31, 2014 at 1:53 AM, Chris Wright c...@daverandom.com wrote: On 30 July 2014 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough, the only sensible syntax choice (//) is unavailable to us, and I think the utility of having it baked into the language as an operator is pretty minimal regardless (I coded a lot of Python for scientific research in a previous job, and I don't think I ever used //, and you'd think that's the place where you'd use it). +1 on the function, though — quick searches on Ohloh and Github suggest that there are a grand total of three open source projects that implement a global intdiv() function. Seems safe enough. Adam This describes my voting choice exactly. I'm not against the idea of an operator, but %% is not the right operator choice for me. I could live with /% but it still doesn't feel quite right. I don't have a practical implementable suggestion for an alternative, so I guess we'll just have to live without it. Of course, this does not preclude us from introducing this in the future if someone comes up with a better idea :-) Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Agreed. I'd very much like to see another RFC that proposes more options for creating an operator for this. The vote against %% on this RFC should not be construed-- in my opinion, at least-- as a consensus against having any kind of operator for intdiv. --Kris
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30 July 2014 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough, the only sensible syntax choice (//) is unavailable to us, and I think the utility of having it baked into the language as an operator is pretty minimal regardless (I coded a lot of Python for scientific research in a previous job, and I don't think I ever used //, and you'd think that's the place where you'd use it). +1 on the function, though — quick searches on Ohloh and Github suggest that there are a grand total of three open source projects that implement a global intdiv() function. Seems safe enough. Adam This describes my voting choice exactly. I'm not against the idea of an operator, but %% is not the right operator choice for me. I could live with /% but it still doesn't feel quite right. I don't have a practical implementable suggestion for an alternative, so I guess we'll just have to live without it. Of course, this does not preclude us from introducing this in the future if someone comes up with a better idea :-) Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
-1 explanation: I don't think %% is clear enough, the only sensible syntax choice (//) is unavailable to us, and I think the utility of having it baked into the language as an operator is pretty minimal regardless (I coded a lot of Python for scientific research in a previous job, and I don't think I ever used //, and you'd think that's the place where you'd use it). +1 on the function, though — quick searches on Ohloh and Github suggest that there are a grand total of three open source projects that implement a global intdiv() function. Seems safe enough. Adam On 29 July 2014 19:31, Andrea Faulds a...@ajf.me wrote: Good evening, The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC] intdiv()” thread and the whole RFC before voting. The vote is here: https://wiki.php.net/rfc/intdiv#vote It is opened today (2014-07-30) and ends 2014-08-06. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense? I think the utility of having it baked into the language as an operator is pretty minimal regardless (I coded a lot of Python for scientific research in a previous job, and I don't think I ever used //, and you'd think that's the place where you'd use it). This actually isn’t something I’d expect to see in science. I think it’s more useful in other fields, like any time you wish to divide into rows (%%) and columns(%). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote: On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense? That makes sense in PHP. Probably only in PHP. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30 Jul 2014, at 18:57, Sara Golemon poll...@php.net wrote: On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote: On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense? That makes sense in PHP. Probably only in PHP. Sure. In an ideal world, % would return the quotient and %% the remainder, but alas it is not so. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On 30 July 2014 19:57, Sara Golemon poll...@php.net wrote: On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote: On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense? That makes sense in PHP. Probably only in PHP. Not even in PHP. -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] [VOTE][RFC] intdiv()
On Wed, Jul 30, 2014 at 11:01 AM, Peter Lind peter.e.l...@gmail.com wrote: On 30 July 2014 19:57, Sara Golemon poll...@php.net wrote: On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote: On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense? That makes sense in PHP. Probably only in PHP. Not even in PHP. -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype This is why I still think we'd be better off using %/ or /%. --Kris
Re: [PHP-DEV] [VOTE][RFC] intdiv()
They don’t necessarily need to be symbols. Pascal, for example, uses ‘/' for floating-point division, ‘div' for integer division, ‘mod' for modulus, and ‘rem' for remainder. For example: 20 / 8 = 2.5 20 mod 8 = 4 In PHP, we already have precedence for non-symbol in operators like ‘and', ‘or', and ‘instanceof', so it wouldn’t feel too out of place for less commonly used operators. Just a thought :). -- Robert E. Williams, Jr. Senior Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
