int->pow(float) gives same result as int->pow(floor(float)).
4->pow(2.9);
(2) Result: 16
this is not restricted to Hilfe.
Sorry, my fault, ->pow() is declared to return Gmp.mpz, but I certainly didn't expect that.
On 6/22/05, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
Ok, it still is a bug, as floor(pow(4, 1.66)) is 9.0, not 4.0
4.0? (I failed to make sense of the above.)
4->pow(1.66) is 4. it should be 9. if ->pow() only "uses the floor" of the float passed as argument, ->pow() should probably not take floats as arguments, as this behaviour is highly illogical.
Ah. Yes, it seems broken that Gmp.mpz->pow accepts floats when it just truncates the input and then does integer math.
If you use pow() instead of Gmp.mpz->pow() (4->pow(), in your example) this flaw won't bite you until your base is too large not to fit in a machine native signed integer: (example from my machine)
pow( (1<<31) - 1, 0.5 );
(1) Result: 46340.949219
pow( 1<<31, 0.5 );
(2) Result: 1
int->pow(float) gives same result as int->pow(floor(float)).
4->pow(2.9);
(2) Result: 16
I suggest pow(4, 2.9) for that. Your suggested syntax is a side effect of transparent integer to bignum conversion, and would be more similar to (int)Gmp.mpz(4)->pow( 2.9 ) behind the scenes, I think.
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Tobias Josefowitz