"Stavros Macrakis" <stavros.macrakis@verizon.net> writes:
>> integrate(sqrt(1-cos(x)),x) returns a result which is valid on
>> [0,%pi] but not on (%pi, 2*%pi]
>
> Isn't this a special case of a more general problem, the representation
> and manipulation of multivalued functions?
>
> The integral of sqrt(1-cos(x)) is -2*sqrt(cos(x)+1). Let's look at the
> function f(x)=sqrt(1+cos(x)). The standard convention for square roots
> makes it non-negative everywhere. But this makes it non-differentiable
> at odd multiples of %pi. Wouldn't it be nice if we could talk about the
> analytical continuation of its value at 0 instead, so that f'(%pi)=-1,
> f(0)=f(4*%pi)=sqrt(2) and f(2*%pi)=f(6*%pi)=-sqrt(2)?
To make this more explicit, we can write the integrand sqrt(1-cos(x))
as abs(-sin(x))/sqrt(1+cos(x)), so that u(x)=1+cos(x) may be regarded
as parametrisation of a path of integration. The trick here is that
we can omit the ABS by switching branches of sqrt instead. And since
-2*sqrt(z) (as function on the Riemann surface of sqrt) is a primitive
function of the differential -dz/sqrt(z) we can forget about this path
altogether and calculate the result as -2*(-sqrt(2))-(-2)*sqrt(2).
I find your viewpoint very interesting and it gives additional insight
but I don't know whether it should be regarded as a deeper reason for
such bugs.
>From a different perspective this particular example is another
instance of the one failure we have in our test suite. The reason is
well known, we just haven't fixed it, viz. INTFORM in sin.lisp binds
$RADEXPAND to $ALL in two cases.
Wolfgang