On Fri, Mar 22, 2024 at 08:11:31PM +0100, Ralf Hemmecke wrote:
> On 3/22/24 17:14, Waldek Hebisch wrote:
> > You asked almost the same thing on 6 Jul 2023.
>
> Do you see a problem?
Well, it was intended as gentl remaider that a lot of solutions
are in the mailing list archive. And if mailing list is too
hard to search than maybe stash this in some easily searchable
place.
>
> I have at least 2.
> (1) your solution was too complicated, i.e. hard to remember by heart,
> (2) it involves InnerTrigonometricManipulations.
> I consider an "Inner..." package as something hidden for a user.
> (3) if a user does not know how to achieve
> Expression(Complex(Integer))->AlgebraicNumber,
> then what function name he would search for? "FG2F"?
>
> I much more like Qian's suggestion to add this special case to
> "retractIfCan".
>
> > > PS: That is one of the situations where things that look simple are
> > > hard for users to actually perform.
> >
> > Well, internally Expression(Complex(Integer)) and Expression(Integer)
> > are represented in quite different way, so there is notrivial
> > calculation to convert between the two forms.
>
> Why shouldn't FriCAS help the user by basically exporting the
> functionality of "FG2F" via "retractIfCan"?
> Would you accept such a patch?
Well, it is natural from naive user point of view. But it really
streching concept of retraction. Namely, conceptually we should
have embedding homomorphism (coercion). Retraction is supposed
to check if something is in the image of coercion and if yes
return source element (since we are taking about embedding this
source element should be unique). In particular round trip
retract-corce should be identity on domain of retract. But 'FG2G'
fails this due to root transformations. Maybe convenience here
is more important than principles. Expression mostly tries to preserve
roots but not always, so one can argue that principles are already
broken. ATM I do not have string opinion either way.
> > And at least one reason for types is that we want to do calculations
> > in a single type, without "useless" convertions. So, start from
> > 'sqrt(-1)' and you will consistently get Expression(Integer) or
> > AlgebraicNumber. OTOH if you want Expression(Complex(Integer)) then
> > stay there...
>
> Good suggestion. ;-)
>
> You know that I like FriCAS, because it has types. However, I hate it to
> waste time if I first have to dig deep into the internals until I can do
> seemingly simple transformations.
>
> My actual problem was to denest that expresssion.
>
> %%% (1) -> z :=
> sqrt(184726398605281*sqrt(-163)+14962838287027761)/(17502080*sqrt(20010))
>
> +--------------------------------------------+
> +-----+ | +-----+
> \|20010 \|184726398605281 \|- 163 + 14962838287027761
> (1) -------------------------------------------------------
> 350216620800
> Type: AlgebraicNumber
> %%% (2) -> rsimp(z)$RootSimplification
>
> (2) "failed"
> Type: Union("failed",...)
Well, ATM rsimp works with single kernel. Can do
(7) -> kernels(z)
+--------------------------------------------+
| +-----+ +-----+
(7) [\|184726398605281 \|- 163 + 14962838287027761 , \|20010 ]
Type: List(Kernel(AlgebraicNumber))
(8) -> kernels(z).1
+--------------------------------------------+
| +-----+
(8) \|184726398605281 \|- 163 + 14962838287027761
Type: Kernel(AlgebraicNumber)
(9) -> rsimp(kernels(z).1)$RootSimplification
+---------------+
+-----+ |184726398605281
(9) (\|- 163 + 163) |---------------
\| 326
Type: Union(Expression(Integer),...)
I principle 'rsimp' should do this automatically, and at some moment
probably it will. It is simply not implemented now.
> So I wrote a function that simply solves "x^2-radicand=0". I would have to
> do it over complex numbers otherwise it wouldn't factorize. So I ended in
> Expression Complex Integer.
>
> While writing this mail, I have found out, that meanwhile
> rsimp$RootSimplification can do the trick via ...(see below).
> BTW, I am not sure whether I can trust the result, because there is
> sqrt(-163) so it's over complex numbers and the docstring of rsimp
> http://fricas.github.io/api/RootSimplification.html doesn't say anything
> about how to interpret the result. Is there a particular preference over the
> two possible solutions?
'rsimp' simply returns one of the roots. It is essentially random
which one. One of possible improvements is to have somewhat inteligent
selection of result, to prefer positive/real results. OTOH, for
purely algebraic puproses normalized roots are indistinguishable.
ATM in case of dependent roots 'rsimp' may silently fail. Handling
of dependent root is of rather high priority to me, but things take
time.
--
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/Zf75PtKjZwLkkLdo%40fricas.org.
