oldk1331 wrote:
>
> > Yes. I am not sure how big is result of extendedEuclidean,
>
> It is not big. I computed it by resultantEuclidean in 50s,
> (semiResultantEuclidean2 in 30s).
You mean for the extendedEuclidean in
integrate((f^2 + x^2)/((x - a)* (x - b)* (x - c)* (x - d)), x)
> > - skipping extendedEuclidean is likely to lead to larger results
>
> Yes, in mapleok.input, there are a dozen examples affected by
> extendedEuclidean. But interestingly, there are a few examples,
> which removal of extendedEuclidean makes the result simpler.
Given logarithmic term log(P(x, a)) where a is algebraic constant
we have choice of normalization: multiplying P by constant
changes log by additive constant so resulting integrals are
equvalent up to constant term. Subresultant PRS tends to
produce spurious constant factors, and such factors may be
big. In purely transcendental case 'primitivePart' removes
such constant factors. But in presence of algebraic constants
we may loose uniqeness of factorization so 'primitivePart'
is unable to remove spurious algebraic factors. Normalizing
P so that leading coefficient of P does not contain a solves
this problem: after normalization any spurious factor does
not contaion a, so 'primitivePart' will remove it.
Of course, putting P is such normal form has two costs.
First, time to do computation. Second, normal form may
be bigger than alternative forms. In simple cases spurious
factors are small and alternative forms may be smaller
than normal form, so it is tempting to avoid normalization.
But normalization is important to avoid blow up in bad
cases. In integrator there is extra complication:
in 'irexpand.spad' we are doing similar transformations
on log terms. Depending on circumstances this may be
cheaper or more expensive compared to what is done by
SUBRESP. In particular, last testcase in 'r20abugs.input'
takes long time _without_ extendedEuclidean in SUBRESP.
> > - Split integral into parts
>
> I have similar thoughts. I think FriCAS integrator's heuristic
> ability is too weak. For example, we can split (non-algebraic)
> constants first.
You mean we should have more special cases? In general
I am trying to have as little special cases as possible.
They tend to make testing harder. In particular bugs
in rarely used special cases may stay long undetected.
Freqently used special case may mask bugs in handling
general case. Once bug is detected special cases
make it harder to determine guilty routine.
Some of our worst integrals were due to special cases
(using substitutions to simplify integral). For
trigonometric integrals Bronstein implemented tangent
case with idea that special case should lead to
better results. But removing this special case
means that now trigonometric functions benefit
from improvements in other parts of integrator.
To put it differently: properly handling trigonometrics
in general integrator looks easier than implementing
all things needed for quality integrals twice
(in general integrator and in tangent case).
Comming back to rational functions. In this specific
example it is not clear how useful good handling
of integrals like in the report is. Rubi testsuite is
full of similar examples. People sometimes want to get
"generic" solutions and write expression with several
transcendental parameters. OTOH in many cases
computation only works for special values of parameters.
Arguably, when there are several parameters and result
is simple we should be able to produce it using modular
methods. So possibly instead of seeking special
cases we should use modular methods. In particular
it would be interesting to see how our modular
gcd routine performs for computing logaritmic
terms.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
