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/
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
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
Hi all,
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
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/
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