From: hebisch@math.uni.wroc.pl
clicliclic@freenet.de wrote:
>
> Waldek Hebisch schrieb:
>
> 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.
ATM I can not claim that all known branch problems in case
of independent kernels were fixed. In the dependent example
that we discussed in the past there was extra sqrt(2). This
means that structure of differential fields still may be
messed up, and regardless of other problems this alone may
lead to branch problems. There is a routine which sometimes
is run at the very end which may mess branches -- this
routine needs to be rewritten. Also, even if all known
problems would be fixed, we know that complex software
have bugs so claiming FriCAS integrator bug-free would be
silly. OTOH significant percentage of bugs discoverd in
FriCAS era are quite old and in particular old bugs are
majority among bugs which require a lot of code to fix.
Newer bugs tend to be shallow ones, usually a simple
point fix is enough. I would say that FriCAS makes
monotonic progress, in particular I avoided changes
that just move problems from one place to another.
Concerning 'luck': you are giving interesting examples,
so have good chance of hitting problems...
> 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).
You mean 2*INT(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.
How do you know that pwc(z) <> 42*pi*#i? Practial problem typicaly
require continuity and continuity may force arbitrary integer
multiple of 2*pi*i. So you get infiite number of values to consider
and combine. In this case one can say pwc(z) = c where c is a
new transtendental constant. But this not always works: it can
happen that integral with arbitrary c does not have closed form,
while integral with symbolic 2*k*pi*i and integer k have
closed form. Or you may have closed form for each separate k,
but no common form for all k. IIUC Derive uses symbolic c,
this is reasonable compromise. But a compromise, in particular
frequently c=0 and taking transtendental c may miss closed form.
Implementing this in FriCAS would not be hard. However,
currently official assumption in FriCAS is that elements
of Expression(Integer) represent real functions, for
which simplifications of logarithms is valid. And
there is no other direct way in FriCAS to say that such
simplification is desirable and allowed.
> 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.
Yes, this is doable (but significantly more work than log
case). However, after such change in integrator other parts
of FriCAS would have to adjusted -- it makes little sense
to preserve branches in integrator if say limit routine or
ODE solver will immediately disregard them. And several
other routines assume no zero divisors (in other words that
we are working with a field). As piecewise constants lead
to zero divisors that would be "sweeping problems from one
corner into another".
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
