On Tue, Nov 21, 2023 at 06:31:27PM +0800, Qian Yun wrote:
>
>
> On 11/21/23 09:52, Waldek Hebisch wrote:
> > On Tue, Nov 21, 2023 at 08:33:50AM +0800, Qian Yun wrote:
> > >
> > >
> > > On 11/20/23 10:08, Waldek Hebisch wrote:
> > > >
> > > > There is question in which cases your apprach works. Examples
> > > > in mapleok.input which work have minimal polynomial for residues
> > > > which is variation of x^4 + a^4 where a is a rational constant
> > > > or x^4 + 2*x^2 + 2 or x^4 + x^2/64 + 1/8192. x^4 + a^4 factors
> > > > in extention by square root of 2:
> > >
> > > In theory this approach should work with higher degree of polynomial.
> > > After all as you said, it is about finding a algebraic extension to
> > > factor the polynomial into simpler ones.
> >
> > Yes. However, explict formulas for root are possible only in
> > special cases. And even when possible are likely to use
> > complex expressions for real roots. AFAICS biquadratic case,
> > that is degree 4 polynomial containing only even powers
> > should work. I am not sure if out solver is smart enough,
> > but symmetric degree 4 polynomial should work. Basically
> > polynomials which one can solve repeatedly solving quadratic
> > equations. Once solution involves general formula for degree 3
> > or degree 4 polynomial we will get complex expressions.
>
> How do you suggest to proceed? Write a special case for biquadratic?
Well, as I wrote we can recognize favourable case by factoring.
This is probably most general method.
> > > Let's see if I can find out such an example.
> > >
> > > >
> > > > Groebner produces sensible thing:
> > > >
> > > > (50) -> groebner([PP::POLY(INT), QQ::POLY(INT), 8*u^3 - 6*u + 1])
> > > >
> > > > 2 2 3
> > > > (50) [v + u - 1, 8 u - 6 u + 1]
> > > >
> > > > and solution of this could be passed to Rioboo. But TransSolvePackage
> > > > can not usefully handle it.
> > > >
> > >
> > > How can this go further? Return rootSum in Rioboo?
> >
> > Possibly. Or do what we do now, that is use symbolic roots.
> > For degree 3 after you add symbolic root polynomial splits
> > into linear term and quadratic (or into linear terms).
> >
> > rootSum is the future, but as long as limit can not handle
> > rootSum we have to use symbolic roots.
> >
>
> If current limit can handle result from integrate, then the limit
> can expand the rootSum just like integrate does. Not an improvement,
> but also not a step back, right?
Well, we want to handle more cases. But there is also problem
of incorrect results. Old limit code has a few fundamental
problems, basically parts of it work on principle "this
usually produces correct result". But sometimes we get
wrong results. Handling of symbolic roots is in this category.
In MRVLIM I tried to avoid such things. There is still possiblity
that MRVLIM gets something which breaks assumptions from
other parts of FriCAS (or from the user), but I do not want
to deliberatly include unsound code in MRVLIM. To put it
differently, if we allow the same liberty for new code as
for old code, then we will never get rid of unsound parts.
You may ask why unsound parts were included at all? Well,
one thing is research: in research you concentrate on
one part and take other as given, that is the only sane
way of doing research. But when it comes to implementation
it may happen that part treated "as given" is in fact
unavailable. Then you need to substitute something
which works well enough to test the new part. There
is also competitive pressure: if competitor uses
unsound method there is strong pressure to "do something"
which frequently boils down to using the same unsound
method. But IMO there is no compeling reason _now_
to include unsound methods in MRVLIM.
--
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/ZVyeHVbLeqZr34zg%40fricas.org.
