# [RFC] intdiv()

- Thread: https://externals.io/message/75520
- Original archive: https://news-web.php.net/php.internals/75520
- Started by Andrea Faulds on 2014-07-15T00:14:44+00:00
- Messages: 43
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/75520.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #75520 — Andrea Faulds — 2014-07-15T00:14:44+00:00

URL: https://externals.io/message/75520#75520

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/

---

## #75521 — Stas Malyshev — 2014-07-15T00:58:10+00:00

URL: https://externals.io/message/75520#75521 · In reply to: #75520

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/

---

## #75522 — Andrea Faulds — 2014-07-15T01:02:21+00:00

URL: https://externals.io/message/75520#75522 · In reply to: #75521

> 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/

---

## #75523 — Yasuo Ohgaki — 2014-07-15T02:10:24+00:00

URL: https://externals.io/message/75520#75523 · In reply to: #75520

Hi Andrea,



> 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 *
99999999; 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
yohgaki@ohgaki.net

---

## #75524 — Bishop Bettini — 2014-07-15T02:31:03+00:00

URL: https://externals.io/message/75520#75524 · In reply to: #75520

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
 

> 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/

---

## #75526 — Stas Malyshev — 2014-07-15T05:17:09+00:00

URL: https://externals.io/message/75520#75526 · In reply to: #75522

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/

---

## #75527 — Kris Craig — 2014-07-15T05:50:47+00:00

URL: https://externals.io/message/75520#75527 · In reply to: #75526

On Mon, Jul 14, 2014 at 10:17 PM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > […]
>
> 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/
>
> --
> 
> 
>
>
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

---

## #75528 — Lester Caine — 2014-07-15T07:06:15+00:00

URL: https://externals.io/message/75520#75528 · In reply to: #75526

> > […]
> 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

---

## #75532 — Andrea Faulds — 2014-07-15T12:11:34+00:00

URL: https://externals.io/message/75520#75532 · In reply to: #75524

> 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 = 1000000;
$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 = 1000000;
$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/

---

## #75534 — Andrea Faulds — 2014-07-15T12:13:08+00:00

URL: https://externals.io/message/75520#75534 · In reply to: #75527

> 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/

---

## #75535 — Andrea Faulds — 2014-07-15T12:15:45+00:00

URL: https://externals.io/message/75520#75535 · In reply to: #75528

> 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/

---

## #75537 — Andrea Faulds — 2014-07-15T12:20:12+00:00

URL: https://externals.io/message/75520#75537 · In reply to: #75526

> 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/

---

## #75568 — Yasuo Ohgaki — 2014-07-15T22:12:13+00:00

URL: https://externals.io/message/75520#75568 · In reply to: #75523

Hi Andrea,



> 
>
> > […]
>
> 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 *
> 99999999; 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
yohgaki@ohgaki.net

---

## #75569 — Andrea Faulds — 2014-07-15T22:32:13+00:00

URL: https://externals.io/message/75520#75569 · In reply to: #75568

> 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/

---

## #75574 — Bishop Bettini — 2014-07-16T01:51:15+00:00

URL: https://externals.io/message/75520#75574 · In reply to: #75532

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


>
> 
> > […]
> where integer division would be used without other functions from bcmath or
> gmp?
> > […]
> 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 = 1000000;
> $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 = 1000000;
> $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/

---

## #75576 — Andrea Faulds — 2014-07-16T01:57:11+00:00

URL: https://externals.io/message/75520#75576 · In reply to: #75574

> 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/

---

## #75593 — Andrea Faulds — 2014-07-16T15:15:12+00:00

URL: https://externals.io/message/75520#75593 · In reply to: #75574

> 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/

---

## #75620 — Bishop Bettini — 2014-07-17T00:11:33+00:00

URL: https://externals.io/message/75520#75620

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.
 




> 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/

---

## #75621 — Sara Golemon — 2014-07-17T00:25:38+00:00

URL: https://externals.io/message/75520#75621 · In reply to: #75593

> 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

---

## #75624 — Tjerk Meesters — 2014-07-17T01:51:54+00:00

URL: https://externals.io/message/75520#75624 · In reply to: #75621

Hi Sara,



> 
> > […]
> 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
>
> --
> 
> 
>
>


-- 
--
Tjerk

---

## #75626 — Sara Golemon — 2014-07-17T02:17:38+00:00

URL: https://externals.io/message/75520#75626 · In reply to: #75624

On Wed, Jul 16, 2014 at 6:51 PM, Tjerk Meesters
<tjerk.meesters@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

---

## #75630 — Kris Craig — 2014-07-17T03:02:22+00:00

URL: https://externals.io/message/75520#75630 · In reply to: #75534

>
> 
>
> > […]
> 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.



> 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

---

## #75641 — Andrea Faulds — 2014-07-17T06:17:52+00:00

URL: https://externals.io/message/75520#75641 · In reply to: #75620

> 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/

---

## #75643 — Zeev Suraski — 2014-07-17T06:29:00+00:00

URL: https://externals.io/message/75520#75643 · In reply to: #75593

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, July 16, 2014 6:15 PM
> To: bishop@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

---

## #75644 — Zeev Suraski — 2014-07-17T06:31:28+00:00

URL: https://externals.io/message/75520#75644 · In reply to: #75630

> -----Original Message-----
> From: Kris Craig [mailto:kris.craig@gmail.com]
> Sent: Thursday, July 17, 2014 6:02 AM
> To: Andrea Faulds
> Cc: Stas Malyshev; PHP internals
> Subject: Re: [PHP-DEV] [RFC] `intdiv()`
>
> 
> 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

---

Next page: https://externals.io/message/75520.md?page=2