On 18 Jul 2014, at 04:39, Tjerk Meesters 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
On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters
wrote:
>
>
>
> On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig wrote:
>
>>
>>
>>
>> On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters > > wrote:
>>
>>>
>>>
>>>
>>> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig
>>> wrote:
>>>
On Thu, Jul 17, 2014 at
On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig wrote:
>
>
>
> On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters
> wrote:
>
>>
>>
>>
>> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig
>> wrote:
>>
>>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>>>
>>> >
>>> > On 17 Jul 2014, at 10:24, Nikit
On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters
wrote:
>
>
>
> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig wrote:
>
>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>>
>> >
>> > On 17 Jul 2014, at 10:24, Nikita Popov wrote:
>> >
>> > > This is already what is currently happening, see
On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig wrote:
> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>
> >
> > On 17 Jul 2014, at 10:24, Nikita Popov wrote:
> >
> > > This is already what is currently happening, see
> > > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
> >
On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds wrote:
>
> On 17 Jul 2014, at 10:24, Nikita Popov wrote:
>
> > This is already what is currently happening, see
> > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
> >
> > Andreas proposal is only useful in the case that the numbers do
On 17 Jul 2014, at 10:24, Nikita Popov wrote:
> This is already what is currently happening, see
> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
>
> Andreas proposal is only useful in the case that the numbers don't divide
> exactly and you need round-down/truncation behavior an
On Thu, Jul 17, 2014 at 2:25 AM, Sara Golemon wrote:
> On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds 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:
On 17 Jul 2014, at 08:17, Stas Malyshev 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
> ev
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 wo
On 17 Jul 2014, at 08:19, Zeev Suraski 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
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
> -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 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 calcu
On 17 Jul 2014, at 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 -
> -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 wrote:
>
> &
On 17 Jul 2014, at 07:56, Pierre Joye 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 sor
Hi Andrea,
On Thu, Jul 17, 2014 at 8:44 AM, Andrea Faulds wrote:
>
> On 17 Jul 2014, at 07:29, Zeev Suraski 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 le
On 17 Jul 2014, at 07:29, Zeev Suraski 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 sev
> -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 wrote:
> -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
On 17 Jul 2014, at 01:11, Bishop Bettini 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
On 17 Jul 2014, at 04:23, Sara Golemon 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
Hi all,
On Thu, Jul 17, 2014 at 12:23 PM, Sara Golemon wrote:
> On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds 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
> > intd
On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds 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 tho
On Tue, Jul 15, 2014 at 5:13 AM, Andrea Faulds wrote:
>
> On 15 Jul 2014, at 06:50, Kris Craig 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: Th
On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds 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.
> On July 17, 2014 at 3:17 AM Sara Golemon 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))
On Wed, Jul 16, 2014 at 6:51 PM, Tjerk Meesters
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
Hi Sara,
On Thu, Jul 17, 2014 at 8:25 AM, Sara Golemon wrote:
> On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds 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 though
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds 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.
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" wrote:
On 16 Jul 2014, at 02:51, Bishop Bettin
On 16 Jul 2014, at 02:51, Bishop Bettini 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 corres
On 16 Jul 2014, at 02:51, Bishop Bettini 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,
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,
On 15 Jul 2014, at 23:12, Yasuo Ohgaki 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 he
Hi Andrea,
On Tue, Jul 15, 2014 at 11:10 AM, Yasuo Ohgaki wrote:
> On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds 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:
>>
>> $ s
On 15 Jul 2014, at 06:17, Stas Malyshev 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
On 15 Jul 2014, at 08:06, Lester Caine 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
>
On 15 Jul 2014, at 06:50, Kris Craig 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 div
On 15 Jul 2014, at 03:31, Bishop Bettini 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
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 ...
I
On Mon, Jul 14, 2014 at 10:17 PM, Stas Malyshev
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.
> --
> Stani
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/
--
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 t
Hi Andrea,
On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds 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(3074457
On 15 Jul 2014, at 01:58, Stas Malyshev 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 inte
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
48 matches
Mail list logo
