On Sun, Nov 19, 2023 at 07:17:14PM +0800, Qian Yun wrote:
> Some of the integration results are pages long --
> because IntegrationResult often has a 'logpart', aka
> a rootSum form.
>
> 'lg2func' in IR2F uses 'zeroOf' which can introduce
> large radicals into the result.
>
> For example
>
> internalIntegrate(1/(z^4+1),z)
>
> internalIntegrate((1+z^2)^4/ (1+z^4)^4,z)
>
> Until recently I found that Rioboo's algorithm described in
> Manuel Bronstein's book, at the end of section 2.8, covers
> this situation.
Hmm, I am not sure what you want to say here. We use Rioboo's
algorithm, but in some cases it does not give us enough
improvement.
AFAICS most significant reason for troubles is "atan doubling"
or even tripling: trying to keep things real we get square
(or higer power) of argument to logaritm. And we use changes
of variables which require kind of "to real" transform when
coming back. This in principle could be solved by factoring
arguments of logs.
> The core idea is that for polynomials with real coefficient,
> its roots come in pairs (symmetric over the real axis).
> So in the following computation of the rootSum of ilogs,
> many terms can cancel with each other.
>
> Sympy implements it, see 'log_to_real':
>
> https://github.com/sympy/sympy/blob/67e4a5c07c390d648601e8fbd6937c877c7438bb/sympy/integrals/rationaltools.py#L327C15-L327C15
>
> Of course, this algorithm is not limited to rational function
> integration, it can improve other integrals as well.
>
> I have worked out a version in FriCAS, it's not a replace for
> 'lg2func' yet -- so my new function 'lg2func2' will try first,
> if it can't handle, then pass to 'lg2func'.
>
> The very rough first version only has 3 failures. I'm still
> working on them.
>
> Now, some questions:
>
> My code needs to use solve$TransSolvePackage. Because the
> resultant method mentioned in the book can't handle
> coefficients of EXPR. Are there alternatives?
>
> And will solve$TransSolvePackage only introduce necessary extra
> root kernels?
I would rather avoid TransSolvePackage. Main approach to Expression
is convert it to polynomial (with Expression coefficients), say using
'univariate'. Once you have polynomials you can use resultants
or Groebner bases to solve systems of equations.
> TransSolvePackage is fixed to work with EXPR, not a generalized
> domain like the second parameter to IR2F.
>
> This doesn't work very well with integrals with parameters,
> because there will be branches -- is sqrt(-a) real or not?
Yes, integrals with parameters cause troubles. IMO those troubles
can be mostly ignored for indefinite integration. We can not
avoid branch troubles for definite integration, but for definite
integration we have more info (bound of integration interval)
and some extra possiblities (for example split integral into
sum of integrals on smaller intervals).
Anyway, my opinion is that we should do generaly applicable
simplification on indefinte integral, but leave thing which
say require looking at sign to definite integrator.
> For even higher degree polynomials, I think it's wise to
> return rootSum instead of give results containing algebraic
> numbers, which causes trouble for sagemath.
I posted a patch to do this some time ago. But it causes
regression in definite integrator. AFAICS, currently we
pass complex algebraic numbers to limit code which is wrong.
But in some cases we get sensible results. Once we have
rootSum limit code sees that there is trouble and gives up.
General case of limit of rootSum looks tricky. There is
good chance that with moderate effort we could improve
limit to handle cases that currently work using algebraic
numbers (and fail on other cases).
> I'll post patch after I reviewed the test failures and do more
> testing.
Could you test interaction of your patch with attached patch.
Attached patch remove (I think) last call to 'real' from the
integrator. We should do this as call to 'real' causes several
wrong results. But removing call to 'real' breaks some definite
integrals, so I am waiting with this patch for some solution for
definite integrals.
Removing call to 'real' means that following transformations of
integrals will see complex expression. For example, with 'real'
removed we have:
(2) -> integrate(1/(z^4+1),z)
(2)
+---+ +-+ +---+ +-+
(\|- 1 + 1)\|2 log((\|- 1 + 1)\|2 + 2 z)
+
+---+ +-+ +---+ +-+
(\|- 1 - 1)\|2 log((\|- 1 - 1)\|2 + 2 z)
+
+---+ +-+ +---+ +-+
(- \|- 1 + 1)\|2 log((- \|- 1 + 1)\|2 + 2 z)
+
+---+ +-+ +---+ +-+
(- \|- 1 - 1)\|2 log((- \|- 1 - 1)\|2 + 2 z)
/
8
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZVn_XjfXCDD3KBte%40fricas.org.
diff --git a/src/algebra/irexpand.spad b/src/algebra/irexpand.spad
index ead11d7..633ac97 100644
--- a/src/algebra/irexpand.spad
+++ b/src/algebra/irexpand.spad
@@ -281,7 +281,7 @@ IntegrationResultRFToFunction(R) : Exports == Implementation where
if R has imaginary : () -> R then integrate(f, x) == complexIntegrate(f, x)
else
integrate(f, x) ==
- l := [mkPrim(real g, x) for g in expand(internalIntegrate(f, x), x)]
+ l := [mkPrim(g, x) for g in expand(internalIntegrate(f, x), x)]
empty? rest l => first l
l
