On Sun, Nov 19, 2023 at 08:47:26PM +0800, Qian Yun wrote:
>
>
> On 11/19/23 20:28, Waldek Hebisch wrote:
> I was talking about section 2.8 "Riboo's Algorithm for Real Rational
> Functions", page 65 to 70 for second edition of "Symbolic
> Integration I".
>
> > 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.
>
> This algorithm prevents generation of (unnecessary) complex
> expression from the beginning.
"atan doubling" makes thing harder (increases degrees) and after
doubling Rioboo was failing. Doubling may happen both before
irexpand and after.
> > > 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).
>
> Now my patch has no test failures, because I limit it to
> work on polynomials degree >= 4. Essentially replacing "lg2cfunc".
> (For degree < 4, my patch is not wrong -- just not as optimized
> as "quadratic".)
There are several changes in 'mapleok.input'. Did you look
that they all are improvements?
> > > 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.
>
> Brief test shows no bad interaction -- my patch works at a place
> before yours have effect.
Well, there is interaction, in the following integral.
> > 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
> >
> >
>
> Isn't a real result even better than this?
Real result is better. But applying 'real' is wrong, we need
honest simplification that preserves value. This is one example
which code in trunk was unable to simplify without 'real'.
AFAICS your patch handles this.
--
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/ZVpRxHJP8hWn4eXO%40fricas.org.
