Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75634
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAESVnVodJ03HwEAUJ3H+-3pdTxuaWf=8Q+YQokP-CW7XxnVJ1Q@mail.gmail.com>
References: <1240076591.91249.1405564441970.open-xchange@app1.ox.registrar-servers.com>
 <CAESVnVodJ03HwEAUJ3H+-3pdTxuaWf=8Q+YQokP-CW7XxnVJ1Q@mail.gmail.com>
Date: Thu, 17 Jul 2014 13:12:57 +0900
Message-ID: <CAGa2bXYB0uxnmucrhGT6s_xMpX9-QPsaUV636j6MM_u4GG8TqQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Andrea Faulds <ajf@ajf.me>, Tjerk Meesters <tjerk.meesters@gmail.com>, bishop@php.net, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a8776707e6204fe5bdd29
Subject: Re: [PHP-DEV] [RFC] intdiv()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7b3a8776707e6204fe5bdd29
Content-Type: text/plain; charset=UTF-8

Hi all,

On Thu, Jul 17, 2014 at 12:23 PM, Sara Golemon <pollita@php.net> wrote:

> On Wed, Jul 16, 2014 at 7:34 PM, Andrea Faulds <ajf@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
yohgaki@ohgaki.net

--047d7b3a8776707e6204fe5bdd29--