rsimp

[Ralf Hemmecke]

Hi Waldek,

I know that rsimp is not yet perfect, but would it be hard to convince
rsimp to give a positive result if the argument is positive?

%%% (401) -> u := 69961-12432*sqrt(5)

+-+
(401) - 12432 \|5 + 69961
%%% (402) -> u::Float, sqrt(u)::Float

(402)
[42162.202903722614494241152950332773841,
205.3343685400050472861798319504493703494]
%%% (403) -> v := rsimp(sqrt(u))$RootSimplification

+-+
(403) 24 \|5 - 259
%%% (404) -> v :: Complex(Float)

(404) - 205.3343685400050472861798319504493703494


Oh, maybe it is not necessary for me.
AFAIU, rsimp is for root expressions like

nthRoot(a1*nthRoot(b1,n2)+a2)

or maybe a little more complicated, but not considering deeper nesting.
And it is not applying the rules recursively.

Is that right?

I'm also missing in the docstring, that rsimp definitely returns failed,
if the argument is not of the form nthRoot(...). It would be helpful to
add that.

Ralf

[Waldek Hebisch]

On Wed, Jul 10, 2024 at 12:08:07AM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
>
> I know that rsimp is not yet perfect, but would it be hard to convince rsimp
> to give a positive result if the argument is positive?
>
> %%% (401) -> u := 69961-12432*sqrt(5)
>
> +-+
> (401) - 12432 \|5 + 69961
> %%% (402) -> u::Float, sqrt(u)::Float
>
> (402)
> [42162.202903722614494241152950332773841,
> 205.3343685400050472861798319504493703494]
> %%% (403) -> v := rsimp(sqrt(u))$RootSimplification
>
> +-+
> (403) 24 \|5 - 259
> %%% (404) -> v :: Complex(Float)
>
> (404) - 205.3343685400050472861798319504493703494

Does not look very hard. Basically main work of 'rsimp' is to
find appropriate expression that is k-th power. Algebraically, we
could take any of the roots, so basicaly what is needed is sign
determining procedure (we have some already) and of course we
would have to add calls to it in right places. There is a little
twist to that: in many cases the k-th power is uniqely determined,
but there are also cases with multiple solutions. And one
solution may lead to positive root while other may be inherently
complex.

> Oh, maybe it is not necessary for me.
> AFAIU, rsimp is for root expressions like
>
> nthRoot(a1*nthRoot(b1,n2)+a2)
>
> or maybe a little more complicated,

There may be multiple roots and for roots of order bigger than 2
there are powers.

> but not considering deeper nesting.

Currantly.

> And it is not applying the rules recursively.

Currently.

> Is that right?
>
> I'm also missing in the docstring, that rsimp definitely returns failed, if
> the argument is not of the form nthRoot(...). It would be helpful to add
> that.

I plan to improve 'rsimp' and this is one of things that should be
changed. Currently 'rsimp' implements one "basic step", that is
handling of at single nesting level. There is still some work to
do here, mainly in step which tries to replace root of degree k
of root of degree k by root of degree k^2. Related is theoretical
works: when this apprach succeds? There is second "basic step",
that is detectiong dependencies. Detecting dependencies in input
should allow finding dependencies that are otherwise missed.
By the way of working currently 'rsimp' will not introduce
depenedent roots. But if we want to extend it that detecting
dependencies may be important.

Concerning deeper nesting, there is relatively simple way to
extend the method to deeper nesting. Main issues here are
theoretical, basically describing when this apprach works
and if some variation could give better result.

Let me mention that for me 'rsimp' is a way to simplify
description of algebraic extentions of fields. This is
different than most of literature that I found. Namely,
typical statement requests decreasing nesting depth even
if that leads to bigger field. I want to find denesting
_inside_ given field, that probably is not always possible
(but I have no proof either way). And I want usable performance
which means that theortically good approaches, like computing
Galois group are not good for me (unless I can find cheap
method of computing Galois groups). 'rsimp' heavily uses
factorization over algebraic extentions, so I may decide
to improve factorizers first.

--
Waldek Hebisch