3-arg float pow()

[Marcin 'Qrczak' Kowalczyk]

Tue, 4 Sep 2001 14:50:02 -0400, Tim Peters <tim at zope.com> pisze:

>> I would expect pow to use multiplication when the exponent is an
>> integer (with a signle division if it's negative),
> 
> As I said, that's less accurate than a decent libm pow() when floats
> are involved, so is a bad idea in that case.

Ok, but In pathologic cases it's more accurate, e.g. (-1.)**10000000000L
can't be computed at all using libm pow() when the exponent can't be
represented exactly as a float to see whether it's odd. In Python-2.2a1
this fails.

> Sorry, but a libm that implemented pow(x, y) literally as exp(b*ln(a))
> couldn't be given away (it's numerically atrocious for large |ln(a)|
> and/or large |b|

I'm sorry, I was thinking only about valid domains, not about precision.
And I was wrong even for that: libm pow has larger domain than
exp(b*ln(a)).

I really meant: for exponents of type float IMHO only positive
bases make sense, maybe including 0 for positive exponents.

> decent fp math libraries are much harder to write than I expect
> you're aware of).

I admit that I don't know how to implement accurate fp math.
I only know that it's hard :-)

>> So (-3)**2 would be defined, but (-3)**2.0 would be not.
> 
> Current CVS Python handles both fine, and even a raw libm pow()
> should have no problems with pow(-3, 2.0).

Maybe in C it's justified by not having separate pow(double,int).
I feel strange to have a function which requires an argument of an
inexact type to have exact integral value.

> If we had rationals, sure.  In the meantime 0.1111111111111111 is
> better than 0.

Ok.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK