Waldek Hebisch schrieb:
>
> Richard Fateman wrote:
> > I suspect that part of the problem in getting
> > back via differentiation may be that antiderivatives
> > computed using any of the purely algebraic methods
> > are not cognizant of branch cuts or discontinuities
> > at all. I think this analysis-related stuff is deserving of
> > serious consideration, but demanding that some Risch-based
> > procedure produce an optimal (e.g. continuous if possible)
> > antiderivative may not be a "debug this" but "can we make
> > another pass over the answer".
> >
> > It's not that the Risch algorithm(?) is too hard, but that
> > it is not computing what you want...
> >
> > Returning to the integrand via differentiation putting you
> > on the wrong side of a branch cut? Whose fault is that if
> > differential algebra doesn't even have that concept?
>
> Actually, if kernels in the input are independent, then
> algebraic approach has no problem with differentiating
> the result. Namely, independence of kernels implies that
> for each choice of branches we get izomorphic differential
> field. Risch algorithm produces answer from ingredients
> in the field and this anwer as expression should differentiate
> back to original expression. At algebraic level various
> substititions are valid because they are izomorphizms
> of differential fields. So, why troubles? First, one
> have to be careful to undo substitutions. Next, practical
> implementations take shortcuts compared to Risch algorithm
> and those shortcuts may introduce extra terms, outside
> differential field in question. Also, there is problem
> with representing differential fields. In FriCAS
> there is no explicit representation of differential fields.
> Instead, kernels appearing in a function implititely
> determine the field. But this interactcs badly with
> automathic simplifications. For example, we have
> sqrt(3/4) and this gets simplified to sqrt(3)/2.
> Lovers of principal branches consider this valid,
> but such change destroys structure of fields.
> So really trouble were due to imperfect implementation.
> Let me add that _most_ brach problem in FriCAS were
> due to non-Risch parts of the integrator.
>
> Of couse dependent kernels cause trouble for algebraic
> approach, but this is more on pragmatic level. Namely, should
> integrator try to solve potentially hard (unsolvable)
> problems which actually have little to do with integration.
> ATM in case of dependent kernels FriCAS assumes that
> branches will simplify. But in principle other approaches
> are possible.
>
> Anyway, the example that started this disscusin, namely
>
> acos(x^2 - sqrt(1 - x^2))
>
> has independent kernels.
>
I am certainly willing to accept your (Waldek's) repeated statement that
Risch integrators, including the Bronstein-Trager procedure for
algebraico-transcendental integrands, when properly implemented, should
deliver results that differentiate back: the former branch problems for
Timofeev's integrals listed on the FriCAS website seem to have
disappeared, as far as integrands with "independent kernels" are
concerned.
On the other hand, the modified Bondarenko integrand acos(x^2 - sqrt(1 -
x^2)) was perhaps my tenth invocation of the FriCAS integrator this year
(after trying some Goursat pseudoelliptics for cube roots long ago, and
then fiddling with a few variants on Timofeev 1.64) for no reason but
curiosity if it could solve it - yet the branches were messed up! Was I
merely 'lucky'? Can all of the replacements needed in preparation of the
switch to differential fields, along with compensatory postprocessing
where necessary, really be expected to preserve input branches in the
next version of FriCAS, say? Selective repairs on demand, perhaps just
sweeping problems from one corner into another, won't erase the bad
impression created in the past.
As to the remaining source of incorrect antiderivatives, namely the
simplistic conversion of integrands with "dependent kernels" to
differential fields in FriCAS by selecting one case over the others
where all of them should be processed in parallel: processing all of
them would not be computationally intensive since their number is
usually small, often 1 or 2, rarely perhaps 4 or 8, although a
satisfactory implementation may involve substantial work.
A purely transcendental example: FriCAS gets INT(LOG(z)*LOG(z^2), z)
wrong because the preprocessor converts to 2*INT(LOG(z)*LOG(z^2), z).
Instead it should convert to INT(LOG(z)*(2*LOG(z) - pwc(z)), z) where
pwc(z) = 2*LOG(z) - LOG(z^2) is a piecewise constant that equals either
0 or 2*pi*#i. The integral must then be fed to the main algorithm for
both of these values, and the final result be assembled from the partial
ones, giving INT(LOG(z)*LOG(z^2), z) = z*LOG(z^2)*(LOG(z) - 1) -
2*z*(LOG(z) - 2). This is just what Derive computes (and Mathematica and
Maple and Rubi too, I suppose).
So this is just another input replacement problem. Since FriCAS must be
able to detect the dependence of LOG(z) and LOG(z^2) already, such an
extension is absolutely straightforward to implement; in particular, no
"potentially hard (unsolvable) problems which actually have little to do
with integration" arise. For the multiplicative piecewise constant
required to handle Timofeev's INT(ASIN(z/a)^(3/2)/SQRT(a^2-z^2), z)
correctly, the situation is very much the same; and the problem
integrals from his Chapter 5 that are not listed on the FriCAS website
can be resolved similarly.
Martin.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
