Re: [PHP-DEV] [RFC] intdiv()
On 18 Jul 2014, at 04:39, Tjerk Meesters tjerk.meest...@gmail.com wrote: 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. That’s the current proposal in the RFC. A 2/3 operator vote simultaneous with a fallback 50%+1 function vote. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 04:23, Sara Golemon poll...@php.net wrote: Do we need a new operator for that? It feels un-php to me, and the kind of problem bigint objects should be meant to solve. On the other hand, having $a/$b != $a/$b (Off by more than 100 in this instance). But back on the first hand, that's consistent with other operations on large floats anyway. PHP_INT_MAX + 1 != One more than PHP_INT_MAX, Actually, my bigints RFC would retain the existing / behaviour (float result if non-zero remainder), so to avoid an unnecessary divisibility check or to deliberately ignore the remainder you’d need some sort of integer division operator there. On the other hand, that RFC would also see ext/gmp always available, I suppose. Of course this isn’t what ext/gmp does *now*, where it makes / be integer division (yuck). I think the / operator’s behaviour makes complete sense and Python 3 actually does exactly the same thing as PHP here, because what / does is the most intuitive thing. I suppose a function alone might do, but it feels a bit lacking to me not to have an operator for this. I’d also argue it’s not really un-PHP to add this, we already have the mod (%) operator and the bitwise operators also operate only on integers. Furthermore division ignoring the remainder is actually a fairly common use case (time for example), so I think there should be some way to do that when you need it. I wonder if the intent there might be clearer, too, than using floor() or (int). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 01:11, Bishop Bettini bis...@php.net wrote: As another contender, how about: $x = 242 %/ 7; $x %/= 13; The % reflects the relationship to modulus, while the / reflects the division effect. I think %/ looks worse, but I think it seems more apropos. I also quite like this one, and I’d prefer %/ to /%. What are internals's thoughts on this? Do you like %/ but not %%? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Wednesday, July 16, 2014 6:15 PM To: bis...@php.net Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() The RFC has been updated to v0.2. It now proposes a %% operator for integer division (with corresponding %%= assignment operator). However, it returns 0 for the PHP_INT_MIN overflow case like %, rather than FALSE and an E_WARNING. Guys, From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Thursday, July 17, 2014 6:02 AM To: Andrea Faulds Cc: Stas Malyshev; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On Tue, Jul 15, 2014 at 5:13 AM, Andrea Faulds a...@ajf.me wrote: Perhaps the RFC could have two options for approval; one with %% and the other with either %/ or /%. Thoughts? Yes, horrible ones :) I can't believe we're seriously considering adding an operator for something so uncommon. I'm actually in favor of adding APIs, but absolutely not an obscure operator. We're not Perl. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) Also, while ** is great for some applications, it’s not going to be used much by others. Is the same not true of an integer division operator? On 17 Jul 2014, at 07:31, Zeev Suraski z...@zend.com wrote: I can't believe we're seriously considering adding an operator for something so uncommon. I'm actually in favor of adding APIs, but absolutely not an obscure operator. We're not Perl. Nor are we Python, but it is worth looking at just how many other languages support this considering it’s actually very useful in some situations. I can think of C, C++, C#, Java, Objective-C, Visual Basic, Pascal, Python and Ruby to name a few popular ones. If you say that some of these implement it just because C does, I’m not sure that’s fair, as there are plenty of bad ideas in C which these don’t implement. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi Andrea, On Thu, Jul 17, 2014 at 8:44 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) Also, while ** is great for some applications, it’s not going to be used much by others. Is the same not true of an integer division operator? The rare cases where I had to do that, I relied on bcmath or gmp. Yes, I needed some extra ops to actually achieve what this RFC proposes but it is good enough. The new ops overloading for extension simplifies that a lot as well. I am sorry but I'd to say -1 on this addition, not worse a new operator or function for this. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 07:56, Pierre Joye pierre@gmail.com wrote: The rare cases where I had to do that, I relied on bcmath or gmp. Yes, I needed some extra ops to actually achieve what this RFC proposes but it is good enough. The new ops overloading for extension simplifies that a lot as well. I am sorry but I'd to say -1 on this addition, not worse a new operator or function for this. How on earth is adding a nearly-universal function everywhere else to PHP’s math library so controversial, let alone as an operator? Yes, you *can* do it with bcmath or gmp, but one should question why you *should*, given that it’s a horrible workaround. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Thursday, July 17, 2014 9:44 AM To: Zeev Suraski Cc: bis...@php.net; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can't, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it's common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. I think the RFC should mention that it's already possible to do it using bcmath or gmp; That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Also, while ** is great for some applications, it's not going to be used much by others. Is the same not true of an integer division operator? To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 08:02, Zeev Suraski z...@zend.com wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. Yes, but as previously mentioned, beyond 2^52 it breaks down. What’s more worrying is the code out there written by people obviously unaware of this, but I shouldn’t use MtGox’s incompetence as a reason to fix PHP ;) I think the RFC should mention that it's already possible to do it using bcmath or gmp; It’s not possible to do with bcmath or gmp within the brief of “find the quotient of the division of two longs without requiring an extension”. Neither bcmath nor gmp is core PHP, and neither operate on longs, though you can be silly and convert a long to a string, in bcmath’s case, or a gmp object, in gmp’s case, then do the operation, then convert back, checking for the two failure cases, of course. That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Well, that’s better than nothing I suppose, but I’d still rather use something infix. To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl… Huh? ** was added by an RFC this year. Actually, since 5.6 isn’t out yet, it’s technically not part of PHP yet... -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi! * Time (actually pretty common in web apps, though we have a DateTime class) Admittedly, we're getting closer to the dreaded year 2038, but what does it actually mean to divide current Unix timestamp by 3 and why one would ever want to do this? We also have classes for real datetime calculations. * Splitting into rows and columns * Pagination Here you are onto something, but how often you paginate data sets of MAXINT size and need exact number of pages? * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) If you're using ints for currency, you're probably doing it wrong. If you're dividing currency using integer division, I don't even know what you are trying to do, except reenacting Office Space :) * Nearest-neighbour scaling You mean image processing? If 53 bit precision is not enough there, I'm not even sure PHP should be doing that. IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Thursday, July 17, 2014 10:09 AM To: Zeev Suraski Cc: bis...@php.net; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On 17 Jul 2014, at 08:02, Zeev Suraski z...@zend.com wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. Yes, but as previously mentioned, beyond 2^52 it breaks down. What's more worrying is the code out there written by people obviously unaware of this, but I shouldn't use MtGox's incompetence as a reason to fix PHP ;) I think the RFC should mention that it's already possible to do it using bcmath or gmp; It's not possible to do with bcmath or gmp within the brief of find the quotient of the division of two longs without requiring an extension. Neither bcmath nor gmp is core PHP, and neither operate on longs, though you can be silly and convert a long to a string, in bcmath's case, or a gmp object, in gmp's case, then do the operation, then convert back, checking for the two failure cases, of course. It's still possible to do. When people vote on a new feature the full context should be clear. Again, I'm supporting your RFC (in its original form at least) - but we should provide as much information as possible in the RFC to give voters the full context. That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Well, that's better than nothing I suppose, but I'd still rather use something infix. PHP's not Perl. Let's keep it that way please... To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl. Huh? ** was added by an RFC this year. Actually, since 5.6 isn't out yet, it's technically not part of PHP yet... OK, this RFC passed well under my radar. I thought we had it forever, and indeed I never found a reason to use it :) I'd probably vote against it if I was aware of it, but given it's common in other languages, I wouldn't have strongly opposed it. I don't think it makes sense to add a specialized integer division operator when we do have a different division operator, and I don't think other dynamic languages have such an operator - so unlike **, there's no established precedent... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17/07/14 04:23, Sara Golemon wrote: Wow. I just finally understood what your RFC was going for. I thought you were trying to cover the case where ($a%$b)==0, but you're not, you're trying to do truncated integer division regardless of remainder. I also missed the fact that div_function does the right thing already as well. My bad for emailing from the bus. Okay, that's another animal entirely. Displaying time intervals is probably one of the best examples of what is needed, but the 'different animal' that I'd like to be able to handle transparently is a 'bigint' based index key. One that provides clean 64bit results what ever the hardware base, 'intdiv' and 'mod' giving 'bigint' results which are the two elements of a 'moddiv' result. I am perhaps a little spoilt since I can do all of this already in the Firebird database layer ... and since it's the data from there I'm working with in private code I do not have a problem, but Firebird's 'arithmetic' is not consistent with other engines or PHP. One useful feature on Firebird is (26 / 3) gives 8 while (28 / 3.00) gives 8.66 - one can tailor the accuracy of the result simply be loading the input. This can be irritating at first, but surprisingly useful at times! Time handling in Firebird introduces another variation which I duplicate to other engines when needed! A timestamp is essentially 2 32 bit integers ... one for days and the other 'part of day' - time as a fraction of day. This can be used as a 'bigint' value for array indexes - calendar elements is a good example - or can be split essentially like the 'moddiv' result to give two integer keys but 32bit ones. Conversion of this to a 64bit 'unit seconds based' time is a point where one does not want results wrapped to PHP float values ;) The point I'm trying to reiterate and expand on is that the integer base size is as important here as integer division, and one size does not fit all. -- 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] [RFC] intdiv()
On 17 Jul 2014, at 08:19, Zeev Suraski z...@zend.com wrote: PHP's not Perl. Let's keep it that way please… I don't think it makes sense to add a specialized integer division operator when we do have a different division operator, and I don't think other dynamic languages have such an operator - so unlike **, there's no established precedent… True, but PHP clearly drew inspiration from Perl, and C, which also has integer division. Many of these languages don’t have an integer division operator simply because they don’t need one. In most C-like languages and plenty of non C-like, an integer divided by an integer is always an integer, and you only get a float result if one or more operands are a float. However, in languages like PHP, Python, Visual Basic and Pascal, the division operator is unusually (though I’d say more intuitively) defined as sometimes giving a float for integer operands. In the case of PHP and Python, this is only when the the second operand isn’t a factor, while in the case of VB and Pascal, / always results in a float. It is in these languages that we find the much rarer integer division operator (Python has //, Visual Basic has \, Pascal has div) because you can’t do it the “normal” way. In this respect, it’s rather unusual that PHP lacks an integer division operator, or even some built-in way to do integer division at all, given that all its peers do support it. There are also languages which don’t have integers, like JavaScript. In JS there’s no need for such an operator as, since it doesn’t have integers anyway, Math.floor(x / y) isn’t going to lose any accuracy. Makes me wonder why we don’t have one after all these years. I assume either the division operator hasn’t always done what id does now (I’m not a historian, so I couldn’t tell you that), or that people have tended to just go for floor(x / y). After all, that works perfectly on 32-bit platforms. ;) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17/07/14 08:02, Zeev Suraski wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. What has happened in the intervening 20 years is that we have moved from having 16 bit computer systems on the desk to 64bit computers on our wrists? Coming up with some new operator is a pointless distraction. The ones we have are enough, they just need to be brought into the 21st century consistently, yet still work on the historic machines some people stile prefer ... just as PHP needs to handle unicode transparently it also needs to handle 64bit integers ... -- 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] [RFC] intdiv()
On 17 Jul 2014, at 08:17, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! * Time (actually pretty common in web apps, though we have a DateTime class) Admittedly, we're getting closer to the dreaded year 2038, but what does it actually mean to divide current Unix timestamp by 3 and why one would ever want to do this? We also have classes for real datetime calculations. To divide by three is probably a bad example, but it’s fair to point out that anything with UNIX timestamps would work fine with just floats as we don’t need 53 bits yet. Here you are onto something, but how often you paginate data sets of MAXINT size and need exact number of pages? Rarely, I suspect, but it would still be nice to have a proper way of doing the division If you're using ints for currency, you're probably doing it wrong. If you're dividing currency using integer division, I don't even know what you are trying to do, except reenacting Office Space :) A lot of people use ints as a poor man’s fixnum, and sometimes that’s actually the right way to implement them. IIRC, Bitcoin is implemented using 64-bit integers internally. You mean image processing? If 53 bit precision is not enough there, I'm not even sure PHP should be doing that. True, but again, you should still ask why PHP doesn’t support integer division in the first place. IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/. %/ and %% are hardly the nicest operators, no. Myself I like %% as % being one part and %% being the other part of an integer division makes sense to me, but I can see why others might not like it. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 2:25 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds a...@ajf.me wrote:
Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be
subject to change, though I think it’s the best I’ve heard so far. ;)
Nor am I. Here's a thought though: How about just making / return int
when there's no remainder.
Looking at this code, you might think it's inefficent:
double dres = a / b;
long lres = a / b;
if (a % b) {
return dres;
} else {
return lres;
}
But in fact at -O1, gcc will optimize this (probably clang and others
as well) to a single idivq instruction and only do the cvtsi2sdq in
the dres case.
My point being, we can just make division with an integral result
return a result of integer division without altering the syntax or
adding a perf hit.
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.
Nikita
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 10:24, Nikita Popov nikita@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
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@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. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@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
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@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. --Kris
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@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
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@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
Re: [PHP-DEV] [RFC] intdiv()
On 16 Jul 2014, at 02:51, Bishop Bettini bis...@php.net wrote: TL;DR -- I agree with the principal but want implemented as the infix operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING). The RFC has been updated to v0.2. It now proposes a %% operator for integer division (with corresponding %%= assignment operator). However, it returns 0 for the PHP_INT_MIN overflow case like %, rather than FALSE and an E_WARNING. The original intdiv() proposal is kept as a fallback; two votes will be held simultaneously, one 2/3 vote for the %% operator and a 50%+1 for the intdiv() function. If the first fails, then if the second did not, the intdiv() function is implemented instead. This way we’ll still at least have a way to do integer division in PHP, if not a full operator. Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be subject to change, though I think it’s the best I’ve heard so far. ;) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
As another contender, how about: $x = 242 %/ 7; $x %/= 13; The % reflects the relationship to modulus, while the / reflects the division effect. I think %/ looks worse, but I think it seems more apropos. On Jul 16, 2014 11:15 AM, Andrea Faulds a...@ajf.me wrote: On 16 Jul 2014, at 02:51, Bishop Bettini bis...@php.net wrote: TL;DR -- I agree with the principal but want implemented as the infix operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING). The RFC has been updated to v0.2. It now proposes a %% operator for integer division (with corresponding %%= assignment operator). However, it returns 0 for the PHP_INT_MIN overflow case like %, rather than FALSE and an E_WARNING. The original intdiv() proposal is kept as a fallback; two votes will be held simultaneously, one 2/3 vote for the %% operator and a 50%+1 for the intdiv() function. If the first fails, then if the second did not, the intdiv() function is implemented instead. This way we’ll still at least have a way to do integer division in PHP, if not a full operator. Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be subject to change, though I think it’s the best I’ve heard so far. ;) -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] [RFC] intdiv()
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds a...@ajf.me wrote:
Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be subject
to change, though I think it’s the best I’ve heard so far. ;)
Nor am I. Here's a thought though: How about just making / return int
when there's no remainder.
Looking at this code, you might think it's inefficent:
double dres = a / b;
long lres = a / b;
if (a % b) {
return dres;
} else {
return lres;
}
But in fact at -O1, gcc will optimize this (probably clang and others
as well) to a single idivq instruction and only do the cvtsi2sdq in
the dres case.
My point being, we can just make division with an integral result
return a result of integer division without altering the syntax or
adding a perf hit.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi Sara,
On Thu, Jul 17, 2014 at 8:25 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds a...@ajf.me wrote:
Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be
subject to change, though I think it’s the best I’ve heard so far. ;)
Nor am I. Here's a thought though: How about just making / return int
when there's no remainder.
Looking at this code, you might think it's inefficent:
double dres = a / b;
long lres = a / b;
if (a % b) {
return dres;
} else {
return lres;
}
But in fact at -O1, gcc will optimize this (probably clang and others
as well) to a single idivq instruction and only do the cvtsi2sdq in
the dres case.
Just out of curiosity, does the compiler optimise it into something like
this?
if (a % b) {
return a / b;
} else {
return (double)a / b;
}
Or, would writing it like that skip the optimisation of being able to fetch
the division result from %rax?
My point being, we can just make division with an integral result
return a result of integer division without altering the syntax or
adding a perf hit.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On Wed, Jul 16, 2014 at 6:51 PM, Tjerk Meesters
tjerk.meest...@gmail.com wrote:
Just out of curiosity, does the compiler optimise it into something like
this?
if (a % b) {
return a / b;
} else {
return (double)a / b;
}
Ya know what? I feel dumb. FP division is a whole separate
instruction. I forgot that (int/int) is always int, even if you're
storing in a double. Derp.
So yeah, In that code you pasted, you get a single idivq in the int
args with no remainder case, but you do have to do a divsd in the
remainder exists case. So not as perf neutral as I was thinking.
Beneficial in the int case since idivq is less costly than divsd, but
the common case may well be ((a%b)!=0), so it's probably harmful more
often than not.
All that said, *I* think the tradeoff of an extra idivq in the
(probably more common) remainder case is worth it in the interest of
keeping PHP's syntax simple.
If we're really set on adding a new operator, I'd vote for something
which provides dividend *and* remainder in some way. (Useful for time
arithmetic, for example)
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On July 17, 2014 at 3:17 AM Sara Golemon poll...@php.net wrote: All that said, *I* think the tradeoff of an extra idivq in the (probably more common) remainder case is worth it in the interest keeping PHP's syntax simple. What are you suggesting you do for an integer division, then? ($a - ($a % $b)) / $ b? The division operator already returns an integer. Or should I just use intdiv()? If we're really set on adding a new operator, I'd vote for something which provides dividend *and* remainder in some way. (Useful for time arithmetic, for example) Isn't that the division operator? ;) In all seriousness, you could just have the compiler optimise using % and %% successively with the same operands to just be a single division, if that's possible. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds a...@ajf.me wrote: What are you suggesting you do for an integer division, then? ($a - ($a % $b)) / $ b? The division operator already returns an integer. Or should I just use intdiv()? It does, but it returns the float truncated result of division. I'm suggesting having it to integer division. So you'd do: $a / $b and it's be smart enough to do the right method. If we're really set on adding a new operator, I'd vote for something which provides dividend *and* remainder in some way. (Useful for time arithmetic, for example) In all seriousness, you could just have the compiler optimise using % and %% successively with the same operands to just be a single division, if that's possible. Assuming you meant / and %, then probably in opcache+'s optimizer. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On Tue, Jul 15, 2014 at 5:13 AM, Andrea Faulds a...@ajf.me wrote: On 15 Jul 2014, at 06:50, Kris Craig kris.cr...@gmail.com wrote: While a practical argument can certainly be made that existing solutions can fit the examples OP cited, I don't think that takes away from the underlying principle of the argument: That there's no reason *not* to include a basic integer division in PHP. It's never made sense to me why it wasn't included. Rather than an intdiv() function, though, I wonder if an operator would be a better approach. Some languages I've seen that use / as the division operator will use a \ as the integer division operator. We use \ for namespaces, and Python 3’s // obviously can’t be used, so I might suggest Pascal’s div operator: Oh, derp. On Wed, Jul 16, 2014 at 5:11 PM, Bishop Bettini bis...@php.net wrote: As another contender, how about: $x = 242 %/ 7; $x %/= 13; I like this idea! I haven't seen anyone else respond to it yet, though. My only question would be whether %/ or /% would be more appropriate. Perhaps the RFC could have two options for approval; one with %% and the other with either %/ or /%. Thoughts? --Kris
Re: [PHP-DEV] [RFC] intdiv()
On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds a...@ajf.me wrote: What are you suggesting you do for an integer division, then? ($a - ($a % $b)) / $ b? The division operator already returns an integer. Or should I just use intdiv()? Wow. I just finally understood what your RFC was going for. I thought you were trying to cover the case where ($a%$b)==0, but you're not, you're trying to do truncated integer division regardless of remainder. I also missed the fact that div_function does the right thing already as well. My bad for emailing from the bus. Okay, that's another animal entirely. Do we need a new operator for that? It feels un-php to me, and the kind of problem bigint objects should be meant to solve. On the other hand, having $a/$b != $a/$b (Off by more than 100 in this instance). But back on the first hand, that's consistent with other operations on large floats anyway. PHP_INT_MAX + 1 != One more than PHP_INT_MAX, for example. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi all, On Thu, Jul 17, 2014 at 12:23 PM, Sara Golemon poll...@php.net wrote: On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds a...@ajf.me wrote: What are you suggesting you do for an integer division, then? ($a - ($a % $b)) / $ b? The division operator already returns an integer. Or should I just use intdiv()? Wow. I just finally understood what your RFC was going for. I thought you were trying to cover the case where ($a%$b)==0, but you're not, you're trying to do truncated integer division regardless of remainder. I also missed the fact that div_function does the right thing already as well. My bad for emailing from the bus. Okay, that's another animal entirely. Do we need a new operator for that? It feels un-php to me, and the kind of problem bigint objects should be meant to solve. On the other hand, having $a/$b != $a/$b (Off by more than 100 in this instance). But back on the first hand, that's consistent with other operations on large floats anyway. PHP_INT_MAX + 1 != One more than PHP_INT_MAX, for example. It would be better to implement it as functions like GMP, BCMath. http://jp2.php.net/manual/en/ref.gmp.php http://jp2.php.net/manual/en/ref.bc.php Since we have prefix_name() naming standard, functions name should int_div() int_mod() int_mul() etc It's consistent with standard and existing functions. I understand functions are inconvenient, but they will have limited usage. We may decide to have operators later, if we really need them. BTW, I'll be +1 for int_div(), etc. Undecided for operators, -1 probably. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] intdiv()
On 15/07/14 06:17, Stas Malyshev wrote: Both of those are likely not to be installed on most systems. Why do Why not? bcmath is in core since forever and has no external requirements, gmp builds practically everywhere too. AFAIR all distros have it. Taking this in isolation is wrong ... It is essentially linked up with all of the discussion on '64bit' processing. What seems to be ignored so far is the simple 'bigint' value. Limiting 32 bit systems to only support 32 bit integers may be the easy solution, but bigint is an essential element of most database type sets these days, so should be supported transparently. If a primary key is provided as part of a database result set, then do we really want the situation where some installs fall over with an overflow of that key on 32 bit systems? Having to use a secondary level function exclusively simply because the core processing gets it wrong is another mistake? Certainly it's not going to be easy to handle, and may not even be practical? But even the discussion on 'type hinting' seems to ignore the range problem where a 64bit value may be required but the installation on4y supports 32bit integers. Currently the value simply works with the string 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] [RFC] intdiv()
On 15 Jul 2014, at 03:31, Bishop Bettini bis...@php.net wrote: I need some education. Can you elaborate on the specific situations where integer division would be used without other functions from bcmath or gmp? I see in the RFC you mention seconds to hh:mm and index to rows/cols, but can you give some actual before and after samples? Like this is how it would be done today without intdiv, and here's how it would be done after? Sure. Say I have a number of seconds which I wish to split into years, days, hours, minutes and seconds, for example: $s = 100; $seconds = $s % 60; $minutes = intdiv($s, 60) % 60; $hours = intdiv($s, 3600) % 24; $days = intdiv($s, 3600 * 24) % 365; $years = intdiv($s, 3600 * 24 * 365); Currently, you’d have to cheat and use floating-point division: $x = 100; $seconds = $s % 60; $minutes = (int)($s / 60) % 60; $hours = (int)($s / 3600) % 24; $days = (int)($s / (3600 * 24)) % 365; $years = (int)($s / (3600 * 24 * 365)); The second one is a bit of a hack, really, but it would probably work most of the time since realistically nobody is using 53-bit time values at the moment (though people are using 32-bit values, so that 64-bit RFC can’t come soon enough given Y2K38). However, intdiv() is perhaps not the best way to implement it or the best syntax. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 15 Jul 2014, at 06:50, Kris Craig kris.cr...@gmail.com wrote: While a practical argument can certainly be made that existing solutions can fit the examples OP cited, I don't think that takes away from the underlying principle of the argument: That there's no reason *not* to include a basic integer division in PHP. It's never made sense to me why it wasn't included. Rather than an intdiv() function, though, I wonder if an operator would be a better approach. Some languages I've seen that use / as the division operator will use a \ as the integer division operator. We use \ for namespaces, and Python 3’s // obviously can’t be used, so I might suggest Pascal’s div operator: $minutes = ($s div 60) % 60; Failing that, div() as a built-in function much like pow() is: $minutes = div($s, 60) % 60; -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 15 Jul 2014, at 08:06, Lester Caine les...@lsces.co.uk wrote: Taking this in isolation is wrong ... It is essentially linked up with all of the discussion on '64bit' processing. What seems to be ignored so far is the simple 'bigint' value. Limiting 32 bit systems to only support 32 bit integers may be the easy solution, but bigint is an essential element of most database type sets these days, so should be supported transparently. If a primary key is provided as part of a database result set, then do we really want the situation where some installs fall over with an overflow of that key on 32 bit systems? Having to use a secondary level function exclusively simply because the core processing gets it wrong is another mistake? Certainly it's not going to be easy to handle, and may not even be practical? But even the discussion on 'type hinting' seems to ignore the range problem where a 64bit value may be required but the installation on4y supports 32bit integers. Currently the value simply works with the string version … Yeah, hence why I’m also proposing the bigint RFC, which intdiv() would work nicely with. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 15 Jul 2014, at 06:17, Stas Malyshev smalys...@sugarcrm.com wrote: Why not? bcmath is in core since forever and has no external requirements, gmp builds practically everywhere too. AFAIR all distros have it. Partly practicality, partly principle. A barebones installation of PHP may not include gmp or bcmath. If my bigint RFC got in, it would have to include the former, but that is a possible future and not the present reality. I should point out that while, yes, bcmath could be used here, it is not efficient to do it by string manipulation (this is a type *natively supported* by literally every semi-modern processor and an operation built into C!). Also, gmp does the wrong thing, as will give you a gmp number result, whereas what I want is an integer. To use gmp is just as hackish as doing a floating-point division and casting, as the values we pass in would be converted to big integers, divided, then the resulting big integer would need to be manually converted back to a long. It would make far more sense to simply support this basic, widely-supported and somewhat common operation than to encourage programmers to use poor workarounds which do not even work when a basic PHP installation is used. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi Andrea,
On Tue, Jul 15, 2014 at 11:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds a...@ajf.me wrote:
PHP currently lacks a way to do integer division. You can floor or int
cast a floating-point division, but beyond 53-bits that produces the wrong
result:
$ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));'
int(3074457345618258432)
Furthermore, using a floating-point division isn’t really a proper way to
do it; it’s a workaround for a lack of language support for a quite basic
operation. This RFC proposes a function for integer division, intdiv(). It
would work properly with 64-bit values:
$ sapi/cli/php -r 'var_dump(intdiv(PHP_INT_MAX, 3));'
int(3074457345618258602)
We have GMP object from 5.6 and we can do
[yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i / 3;
var_dump($a);'
object(GMP)#2 (1) {
[num]=
string(4) 7114
}
[yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i *
; var_dump($a);'
object(GMP)#2 (1) {
[num]=
string(13) 2134199978658
}
IMHO, GMP is the choice when precise computation is needed as it could be
any number.
Native integer type is much faster for sure. Question is do we really need
it?
If we are going to have integer arithmetics, it may be better to have full
set of operators/functions
https://bugs.php.net/bug.php?id=30701
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] intdiv()
On 15 Jul 2014, at 23:12, Yasuo Ohgaki yohg...@ohgaki.net wrote: If we are going to have integer arithmetics, it may be better to have full set of operators/functions https://bugs.php.net/bug.php?id=30701 I’d rather not go to that length, but if someone wants to do that, they may. Bigints might help here… although they might also cause more problems in places. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi Andrea,
TL;DR -- I agree with the principal but want implemented as the infix
operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).
As a user, I could implement intdiv and get the same functionality as
proposed:
function intdiv($n, $d) { return (int)($n / $d); }
Heck, I could even simplify further:
function intdivmod($n, $d, $m = 1) {
return (int)($n / $d) % $m;
}
Though an internal implementation would be faster and would bypass the
float truncation issue (which IMO is a separate issue and neither a pro nor
con for this RFC), I feel like we need to confer additional benefit if we
implement this in core.
Specifically, I'd want this implemented infix. Let's call it // for now.
I'd like to be able to:
$x = 247 // 5;
$x //= 5;
The functional notation doesn't afford assign equals. It collides with
user functions. It complicates expressions. (I also don't like pow()
functionally and wish PHP had an operator like ** for powers.) So, why not
implement this as an actual operator?
As far as an operator, that's trickier. // and \ would be most like
existing languages, but those are problematic as already stated. We could
overload /, relying on the left and right operands to be int to induce
integer division... but I'm pretty sure that would be more hassle than it's
worth. So the best I can think of is %%. That seems ok to me, since there
is some family resemblance between modulus and integer division.
Finally, I think a test on the other side of the spectrum is needed:
PHP_INT_MIN %% -1. Mathematically that should be PHP_INT_MAX+1, I believe,
so a warning and false seems appropriate.
Regards,
bishop
On Jul 15, 2014 8:11 AM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 03:31, Bishop Bettini bis...@php.net wrote:
I need some education. Can you elaborate on the specific situations
where integer division would be used without other functions from bcmath or
gmp?
I see in the RFC you mention seconds to hh:mm and index to rows/cols,
but can you give some actual before and after samples? Like this is
how it would be done today without intdiv, and here's how it would be done
after?
Sure. Say I have a number of seconds which I wish to split into years,
days, hours, minutes and seconds, for example:
$s = 100;
$seconds = $s % 60;
$minutes = intdiv($s, 60) % 60;
$hours = intdiv($s, 3600) % 24;
$days = intdiv($s, 3600 * 24) % 365;
$years = intdiv($s, 3600 * 24 * 365);
Currently, you’d have to cheat and use floating-point division:
$x = 100;
$seconds = $s % 60;
$minutes = (int)($s / 60) % 60;
$hours = (int)($s / 3600) % 24;
$days = (int)($s / (3600 * 24)) % 365;
$years = (int)($s / (3600 * 24 * 365));
The second one is a bit of a hack, really, but it would probably work most
of the time since realistically nobody is using 53-bit time values at the
moment (though people are using 32-bit values, so that 64-bit RFC can’t
come soon enough given Y2K38).
However, intdiv() is perhaps not the best way to implement it or the best
syntax.
--
Andrea Faulds
http://ajf.me/
Re: [PHP-DEV] [RFC] intdiv()
On 16 Jul 2014, at 02:51, Bishop Bettini bis...@php.net wrote:
Hi Andrea,
TL;DR -- I agree with the principal but want implemented as the infix
operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).
%% is perhaps the only good non-keyword syntax choice. I like that.
As a user, I could implement intdiv and get the same functionality as
proposed:
function intdiv($n, $d) { return (int)($n / $d); }
You could, yes, but it wouldn’t return the correct result beyond 53-bit
integers, and I’m not sure it would handle $x/-1 particularly well.
Heck, I could even simplify further:
function intdivmod($n, $d, $m = 1) {
return (int)($n / $d) % $m;
}
Though an internal implementation would be faster and would bypass the
float truncation issue (which IMO is a separate issue and neither a pro nor
con for this RFC), I feel like we need to confer additional benefit if we
implement this in core.
Specifically, I'd want this implemented infix. Let's call it // for now.
I'd like to be able to:
$x = 247 // 5;
$x //= 5;
The functional notation doesn't afford assign equals. It collides with
user functions. It complicates expressions. (I also don't like pow()
functionally and wish PHP had an operator like ** for powers.) So, why not
implement this as an actual operator?
PHP *does* have an operator “like **” for powers… the ** operator. Did you
somehow miss that RFC passing? :)
As far as an operator, that's trickier. // and \ would be most like
existing languages, but those are problematic as already stated. We could
overload /, relying on the left and right operands to be int to induce
integer division... but I'm pretty sure that would be more hassle than it's
worth. So the best I can think of is %%. That seems ok to me, since there
is some family resemblance between modulus and integer division.
Right. This is just returning the other part of an integer division, the actual
result itself, not the remainder.
Finally, I think a test on the other side of the spectrum is needed:
PHP_INT_MIN %% -1. Mathematically that should be PHP_INT_MAX+1, I believe,
so a warning and false seems appropriate.
The patch currently returns zero because I don’t want to yield a float like /
does, but E_WARNING and FALSE sounds good, we do that for integer division
anyway.
Do others on internals think that %% is a good syntax choice? Does anyone have
an objection to it? It wouldn’t conflict with anything, it uses punctuation,
and it makes sense.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] intdiv()
Good evening again, PHP currently lacks a way to do integer division. You can floor or int cast a floating-point division, but beyond 53-bits that produces the wrong result: $ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));' int(3074457345618258432) Furthermore, using a floating-point division isn’t really a proper way to do it; it’s a workaround for a lack of language support for a quite basic operation. This RFC proposes a function for integer division, intdiv(). It would work properly with 64-bit values: $ sapi/cli/php -r 'var_dump(intdiv(PHP_INT_MAX, 3));' int(3074457345618258602) It works exactly as you’d expect it to. If you divide by zero, it does exactly the same thing the division operator does (E_WARNING and returns FALSE). While this is simple enough, I’m also considering possibly shortening it to div() (more likely to cause conflicts, but easier to type), implementing it as an internal function (à la pow()), and perhaps implementing it as an infix operator (3 div 2 === 1). The RFC is here: https://wiki.php.net/rfc/intdiv It elaborates a little more, so I’d suggest reading it first. What are your thoughts? I think this is a simple and obvious addition. 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] [RFC] intdiv()
Hi! It elaborates a little more, so I’d suggest reading it first. What are your thoughts? I think this is a simple and obvious addition. INT_MAX is kind of an edge case, if you need arbitrary-length precision you can always use gmp or bcmath. I'm not sure this one-off use case that is already covered by two extensions really needs another function. Practically, where would you need exact division up to 53 bits but not beyond? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 15 Jul 2014, at 01:58, Stas Malyshev smalys...@sugarcrm.com wrote: INT_MAX is kind of an edge case, It’s just an obvious example, integers beyond 2^53 fulfill this. if you need arbitrary-length precision you can always use gmp or bcmath. I’m not asking for arbitrary-length precision, I’m asking for an integer division operator for PHP’s integer type. Granted, this function would be even more useful if my bigints RFC got in, but it’s useful now. I'm not sure this one-off use case that is already covered by two extensions really needs another function. Both of those are likely not to be installed on most systems. Why do you need to install gmp or bcmath to do a basic operation with two 64-bit integers yielding a 64-bit integer? Many languages support this (C, C++, C#, Java, Python, to name a few). Why shouldn’t PHP? Practically, where would you need exact division up to 53 bits but not beyond? No idea. This RFC isn’t proposing that. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
Hi Andrea,
On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds a...@ajf.me wrote:
PHP currently lacks a way to do integer division. You can floor or int
cast a floating-point division, but beyond 53-bits that produces the wrong
result:
$ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));'
int(3074457345618258432)
Furthermore, using a floating-point division isn’t really a proper way to
do it; it’s a workaround for a lack of language support for a quite basic
operation. This RFC proposes a function for integer division, intdiv(). It
would work properly with 64-bit values:
$ sapi/cli/php -r 'var_dump(intdiv(PHP_INT_MAX, 3));'
int(3074457345618258602)
We have GMP object from 5.6 and we can do
[yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i / 3;
var_dump($a);'
object(GMP)#2 (1) {
[num]=
string(4) 7114
}
[yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i *
; var_dump($a);'
object(GMP)#2 (1) {
[num]=
string(13) 2134199978658
}
IMHO, GMP is the choice when precise computation is needed as it could be
any number.
Native integer type is much faster for sure. Question is do we really need
it?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] intdiv()
Hi Andrea, I need some education. Can you elaborate on the specific situations where integer division would be used without other functions from bcmath or gmp? I see in the RFC you mention seconds to hh:mm and index to rows/cols, but can you give some actual before and after samples? Like this is how it would be done today without intdiv, and here's how it would be done after? Regards, bishop On Jul 14, 2014 8:15 PM, Andrea Faulds a...@ajf.me wrote: Good evening again, PHP currently lacks a way to do integer division. You can floor or int cast a floating-point division, but beyond 53-bits that produces the wrong result: $ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));' int(3074457345618258432) Furthermore, using a floating-point division isn’t really a proper way to do it; it’s a workaround for a lack of language support for a quite basic operation. This RFC proposes a function for integer division, intdiv(). It would work properly with 64-bit values: $ sapi/cli/php -r 'var_dump(intdiv(PHP_INT_MAX, 3));' int(3074457345618258602) It works exactly as you’d expect it to. If you divide by zero, it does exactly the same thing the division operator does (E_WARNING and returns FALSE). While this is simple enough, I’m also considering possibly shortening it to div() (more likely to cause conflicts, but easier to type), implementing it as an internal function (à la pow()), and perhaps implementing it as an infix operator (3 div 2 === 1). The RFC is here: https://wiki.php.net/rfc/intdiv It elaborates a little more, so I’d suggest reading it first. What are your thoughts? I think this is a simple and obvious addition. 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] [RFC] intdiv()
Hi! Both of those are likely not to be installed on most systems. Why do Why not? bcmath is in core since forever and has no external requirements, gmp builds practically everywhere too. AFAIR all distros have it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On Mon, Jul 14, 2014 at 10:17 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Both of those are likely not to be installed on most systems. Why do Why not? bcmath is in core since forever and has no external requirements, gmp builds practically everywhere too. AFAIR all distros have it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php While a practical argument can certainly be made that existing solutions can fit the examples OP cited, I don't think that takes away from the underlying principle of the argument: That there's no reason *not* to include a basic integer division in PHP. It's never made sense to me why it wasn't included. Rather than an intdiv() function, though, I wonder if an operator would be a better approach. Some languages I've seen that use / as the division operator will use a \ as the integer division operator. --Kris
