denest roots

[Ralf Hemmecke]

Does someone know a FriCAS function that returnss a from w?
If possible it should also work over Expression(X) in particular when
complex numbers are involved.

Of course, I could program something, but maybe it's already there and I
am just not able to find it.

Thank you
Ralf


(233) -> a := 1+sqrt(2)

+-+
(233) \|2 + 1
Type: AlgebraicNumber
(234) -> h := a^2

+-+
(234) 2 \|2 + 3
Type: AlgebraicNumber
(235) -> w := sqrt h

+----------+
| +-+
(235) \|2 \|2 + 3
Type: AlgebraicNumber

[Waldek Hebisch]

No function doing what you want. Using eqisting functionality
you can do:

(5) -> kw := kernels(w).1

+----------+
| +-+
(5) \|2 \|2 + 3
Type: Kernel(AlgebraicNumber)
(7) -> awe := (argument(kw).1)::EXPR(INT)

+-+
(7) 2 \|2 + 3
Type: Expression(Integer)
(8) -> eF := EFACTOR(INT, EXPR(INT))

(8) ExpressionFactorPolynomial(Integer,Expression(Integer))
Type: Type
(9) -> factor(monomial(1, 2)$SUP(EXPR(INT)) - awe)

+-+ +-+
(9) (? - \|2 - 1)(? + \|2 + 1)
Type: Factored(SparseUnivariatePolynomial(Expression(Integer)))

Given factorization you can produce denested root. Of course, there is
still problem of choosing between a and -a.

That is easy to implement way of denesting, however it convers only
"trivial" cases, namely when argument to root is a power. There
are denestings when argument is not a power ant that is much more
tricky. Your case is made easier by fact that integers extended by
square root of 2 have unique factorization, but we do not have
this in general case.

Extra thing: I do not know why you want to simplify roots, but
some simplification, including this one, should be done by
normalize. More precisely, normalize should detect "dependent
roots" and what you gave is one of simplest examples of dependent
roots. OTOH some denstings are unrelated to dpendent roots.
Also, removal of squares (powers in general) from roots strictly
speaking is not necessary for normalize. And once expression
is properly normalized you should be careful when transforming
kernels, well-intendend transformation can destroy effect of
normalization.

--
Waldek Hebisch

[Ralf Hemmecke]

Dear Waldek,

thank you for your reply.
It does, however not work for this case.

f :=
sqrt(184726398605281*%i*sqrt(163)+14962838287027761)/(17502080*sqrt(20010))

Another related question. I there an easy way to turn (computed with
type Expression(Complex(Integer)) into Expression(Integer) or even
Algebraic number?

If I input the above expression with sqrt(-163) instead of %i*sqrt(163),
I get AlgebraicNumber as type. But I am not entering f. It's otherwise
given.

> That is easy to implement way of denesting, however it convers only
> "trivial" cases, namely when argument to root is a power.

Yes. But some people get frustrated over the simple things. I know that
FriCAS has its strength somewhere else, but if I can collect some of
such stuff (where I am struggeling myself) into a jfricas notebook and
put it only, maybe it helps some people not to run away too quickly from
FriCAS.

> Extra thing: I do not know why you want to simplify roots,

Just because simple roots look nicer.

> More precisely, normalize should detect "dependent roots" and what
> you gave is one of simplest examples of dependent roots.

I have read this while browsing the sources, but normalize did not help
out of the box in my case, so I was looking for something else.

Ralf

[Waldek Hebisch]

On Wed, Jul 12, 2023 at 02:26:21PM +0200, Ralf Hemmecke wrote:
> Dear Waldek,
>
> thank you for your reply.
> It does, however not work for this case.
>
> f :=
> sqrt(184726398605281*%i*sqrt(163)+14962838287027761)/(17502080*sqrt(20010))

You did not say what you _really_ want. AFAICS the element above
has degree 4 over complex rationals, so in this sense is the
simplest expression. Over rationals one could replace %*sqrt(163)
by sqrt(-163), so that degree of f equals degree of extension
given by kernels. One can factor out squares from numerator and
denominator, but otherwise it is not clear what you may want.

> Another related question. I there an easy way to turn (computed with
> type Expression(Complex(Integer)) into Expression(Integer) or even
> Algebraic number?

On July 5 I answered this: use FG2F, not so easy since one needs
to give parameters to the package, but single function call.

> > That is easy to implement way of denesting, however it convers only
> > "trivial" cases, namely when argument to root is a power.
>
> Yes. But some people get frustrated over the simple things. I know that
> FriCAS has its strength somewhere else, but if I can collect some of
> such stuff (where I am struggeling myself) into a jfricas notebook and
> put it only, maybe it helps some people not to run away too quickly from
> FriCAS.

I appreciate the need and your effort. And I ask questions to
know what is needed. And I think that we could provide better
routines than what is currently available in FriCAS.

> > Extra thing: I do not know why you want to simplify roots,
>
> Just because simple roots look nicer.

OK, if that is for printing purposes, then it makes sense to
use "heavier" methods (needing more compute time). Also,
it makes sense to break current rule that type is the only
thing deciding how things are printed. Instead we could
have print routines covering some common cases.

OTOH for me important criterion is usefulness for further
computations, which means that at least in default settings
FriCAS may give different form of answer that users want.

To say the truth, users expectations seem to be widely divergent.
To handle diverging expectaions Maxima and Reduce have tens
(or maybe hundereds) of flags which affect what the system will
do. This works nice in simple cases, but IMO does not scale:
there are latent bugs when routines are called with unexpeceted
combination of flags. There is uneasy choice what to do when
routine needs a specific flag setting, but is is called with
different setting: signaling error discourages users, using
user flag setting can lead to wrong results, replacing user
setting by a working one leads to dissatisfaction that flag
is ignored. In FriCAS we have 'setSimplifyDenomsFlag' but
otherwise probably no flags affectig computations and I
prefer to _not_ add more flags (rather, I would prefer to
improve FriCAS so that 'setSimplifyDenomsFlag' is no
longer needed). One alternative to global flags is to
have opions to routines. ATM plots and guessing package
use options, but it would be natural to have options
to say 'simplify'.

> > More precisely, normalize should detect "dependent roots" and what
> > you gave is one of simplest examples of dependent roots.
>
> I have read this while browsing the sources, but normalize did not help out
> of the box in my case, so I was looking for something else.

I wrote "should", ATM normalize will fail to do what it should
do in presence of nestend roots. And even for non-nested
roots normalize handles only simplest cases.

--
Waldek Hebisch