"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> The pow() regression test is failing due to this strange characteristic:
(...)
}
> ie. pow(2147483647,1) returns a float where one would expect it to return
> an int. Off by one error somewhere?
I'm quite certain (but not 100% certain of course) this is not the case. The
issue here is that in order to check wether the result is small enough to
fit into a float, I did a exp(log(base) * exp) (line 478), and check that
against long_max/min. Because of fp characteristics, this will give a false
alarm near the boundary: the check says it won't fit into int, but actually,
it does.
I could modify it to run the integer algorithm anyway, and check there for
overflows. Then no false alarms. Because the algorithm is very fast,
performance is not the issue.
Or just leave the code as it is, since the test nearly only exists of rare
boundary cases, it's not realistic. But agreed: it'd be better if always int
is returned when possible.
> Same thing happens on the negative boundary.
Here neither is a off-by-one issue, though the code could have a bit more
comments. On entering this loop:
while (lexp > 0) {
if (lexp & 1) /* odd */
Z_LVAL_P(return_value) *= lbase;
lexp >>= 1;
lbase *= lbase;
}
lbase will be negative if it was originally, and if the result is negative,
lexp will be odd of course. So already in the first iteration return_value
will be negative, and that won't change anymore because lbase is squared,
and thus there will be taken full advantage of the larger negative range.
If you found a flaw/bug in the code, please mail me.
--Jeroen
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
