Re: [fricas-devel] AlgebraicNumber
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
Re: [fricas-devel] AlgebraicNumber
On 3/22/24 17:14, Waldek Hebisch wrote:
You asked almost the same thing on 6 Jul 2023.
Do you see a problem?
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?
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",...)
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?
I still think that "retractIfCan" in Expression(Complex Integer) should
be able to yield an AlgebraicNumber if possible.
Ralf
%%% (57) -> z :=
sqrt(184726398605281*sqrt(-163)+14962838287027761)/(17502080*sqrt(20010))::Expression(Integer)
++
| +-+
\|184726398605281 \|- 163 + 14962838287027761
(57) ---
+-+
17502080 \|20010
Type: Expression(Integer)
%%% (58) -> rsimp(numer z)$RootSimplification
+---+
+-+|184726398605281
(58) (\|- 163 + 163) |---
\| 326
Type: Union(Expression(Integer),...)
%%% (59) -> rootSplit rsimp(numer z)$RootSimplification
+-+
13591409 \|- 163 + 2215399667
(59) --
+---+
\|326
Type: Expression(Integer)
%%% (60) -> rootSplit rsimp(numer z)$RootSimplification / denom z
+-+
13591409 \|- 163 + 2215399667
(60) --
+---+ +-+
17502080 \|326 \|20010
Type: Expression(Integer)
%%% (61) -> % :: AlgebraicNumber
+-+ +---+ +-+
(13591409 \|- 163 + 2215399667)\|326 \|20010
(61) --
114170618380800
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/3df92a9a-200e-4290-b080-c783fef0dc3d%40hemmecke.org.
Re: [fricas-devel] AlgebraicNumber
On Fri, Mar 22, 2024 at 08:59:23PM +0800, Qian Yun wrote: > Line 615 of expr.spad. > > (Related function: smp2an, k2an, R2AN). This handles case of Expression(Integer). But to convert %i to AlgebraicNumber one needs to do what ITRIGMNP is doing. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/Zf2wog9JHEdkha9n%40fricas.org.
Re: [fricas-devel] AlgebraicNumber
On Fri, Mar 22, 2024 at 01:22:23PM +0100, Ralf Hemmecke wrote: > Suppose by some computation I get an expression like > > z := (10*sqrt(163)+11*%i)/13/sqrt(105) > > I would like to transform it into an element of AlgebraicNumber. > > Unfortunately, up to now I was unable to find a function that helps to to > the retraction. > > Does someone know a way for cases where I know that the input actually can > happily live in AN? You asked almost the same thing on 6 Jul 2023. My anwer looked like this: Well, the trouble is %i, if you use sqrt(-1), then you will get Expression(Integer) and things will be easy. But one can do (1) -> eI := Expression(Integer) (1) Expression(Integer) Type: Type (2) -> eCI := Expression(Complex(Integer)) (2) Expression(Complex(Integer)) Type: Type (3) -> iTM := ITRIGMNP(Integer, eI, eCI) (3) InnerTrigonometricManipulations Integer , Expression(Integer) , Expression(Complex(Integer)) Type: Type (4) -> z := (10*sqrt(163)+11*%i)/13/sqrt(105) +---+ 10 \|163 + 11 %i (4) - +---+ 13 \|105 Type: Expression(Complex(Integer)) (5) -> FG2F(z)$iTM +---+ +---+ 10 \|163 + 11 \|- 1 (5) - +---+ 13 \|105 Type: Expression(Integer) (6) -> %::AlgebraicNumber +---+ +---+ +---+ +---+ 10 \|105 \|163 + 11 \|- 1 \|105 (6) - 1365 Type: AlgebraicNumber > 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. 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... -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/Zf2uaTGPA7_5kBs6%40fricas.org.
Re: [fricas-devel] AlgebraicNumber
Cool, Qian! You are a genius. You seem to have digged out the right place. Now, of course, the question is how to condition that part. For map(x+->(real x + sqrt(-1)@AN*imag(x)), z) to work R must provide "real" and "imag" and their target should be coercible to AN. I think, just testing "R is Complex Integer" or "R is Complex Fraction Integer" would already be quite some progress in my eyes. I only hope that this does not change the behaviour of the interpreter too much so that, i.e. the interpreter shouldn't invest time in trying to needlessly coerce something to AN. Ralf On 3/22/24 13:59, Qian Yun wrote: Line 615 of expr.spad. (Related function: smp2an, k2an, R2AN). - Qian On 3/22/24 20:57, Ralf Hemmecke wrote: Maybe this signature retractIfCan : % -> Union(AlgebraicNumber,"failed") should support it, when % is EXPR COMPLEX INT. Implemented where? Ralf -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/9263c19a-ce19-49be-bedd-a6ce965ab657%40hemmecke.org.
Re: [fricas-devel] AlgebraicNumber
Line 615 of expr.spad. (Related function: smp2an, k2an, R2AN). - Qian On 3/22/24 20:57, Ralf Hemmecke wrote: Maybe this signature retractIfCan : % -> Union(AlgebraicNumber,"failed") should support it, when % is EXPR COMPLEX INT. Implemented where? Ralf -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/d81c3807-46b2-49e4-ba01-ca6f0dc3f7f8%40gmail.com.
Re: [fricas-devel] AlgebraicNumber
Maybe this signature retractIfCan : % -> Union(AlgebraicNumber,"failed") should support it, when % is EXPR COMPLEX INT. Implemented where? Ralf -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/041ebf88-5c3c-4309-ab31-154605af283e%40hemmecke.org.
Re: [fricas-devel] AlgebraicNumber
Maybe this signature retractIfCan : % -> Union(AlgebraicNumber,"failed") should support it, when % is EXPR COMPLEX INT. - Qian On 3/22/24 20:38, Ralf Hemmecke wrote: Oh, for my case I have found a simple trick. First map to Expression(Complex Intger) to Expression(AN) and then retract. i := sqrt(-1)@AN; za := map(x+->(real x + i*imag(x)), z) Ralf PS: Yes, Qian, your answer looks close. On 3/22/24 13:22, Ralf Hemmecke wrote: Suppose by some computation I get an expression like z := (10*sqrt(163)+11*%i)/13/sqrt(105) I would like to transform it into an element of AlgebraicNumber. Unfortunately, up to now I was unable to find a function that helps to to the retraction. Does someone know a way for cases where I know that the input actually can happily live in AN? Thank you in advance. Ralf PS: That is one of the situations where things that look simple are hard for users to actually perform. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/f6564365-829f-4c5f-9345-1dae7772f546%40gmail.com.
Re: [fricas-devel] AlgebraicNumber
Oh, for my case I have found a simple trick. First map to Expression(Complex Intger) to Expression(AN) and then retract. i := sqrt(-1)@AN; za := map(x+->(real x + i*imag(x)), z) Ralf PS: Yes, Qian, your answer looks close. On 3/22/24 13:22, Ralf Hemmecke wrote: Suppose by some computation I get an expression like z := (10*sqrt(163)+11*%i)/13/sqrt(105) I would like to transform it into an element of AlgebraicNumber. Unfortunately, up to now I was unable to find a function that helps to to the retraction. Does someone know a way for cases where I know that the input actually can happily live in AN? Thank you in advance. Ralf PS: That is one of the situations where things that look simple are hard for users to actually perform. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/aa04dbfa-472e-4a88-89af-9312d587cac7%40hemmecke.org.
Re: [fricas-devel] AlgebraicNumber
I can only think of this way: (real z + sqrt(-1)*imag z)::AN - Qian On 3/22/24 20:22, Ralf Hemmecke wrote: Suppose by some computation I get an expression like z := (10*sqrt(163)+11*%i)/13/sqrt(105) I would like to transform it into an element of AlgebraicNumber. Unfortunately, up to now I was unable to find a function that helps to to the retraction. Does someone know a way for cases where I know that the input actually can happily live in AN? Thank you in advance. Ralf PS: That is one of the situations where things that look simple are hard for users to actually perform. -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/67fe6c95-33b9-4a9e-b95d-3bc9864f252c%40gmail.com.
Re: [fricas-devel] AlgebraicNumber
On 06/10/2010 12:43 PM, Bertfried Fauser wrote: a := sqrt((sqrt(5) + 3)/2) b := (sqrt(5)+1)/2 (51) - (a=b)::Boolean (51) true c:= -(sqrt(5)+1)/2 (4) - (a=c)::Boolean (4) true (6) - (b=c)::Boolean (6) false Type: Boolean so equality is here a fishy concept... P why is it always me that runs into bugs? Anyway, I actually suspected something like this, but I did not try out your c. Obviously we should take sqrt : % - % ++ sqrt(x) returns the square root of x. The branch cut lies ++ along the ++ negative real axis, continuous with quadrant II. into account. But in fact, it made me already wonder why FriCAS did not simplify in the first place. Well, the domain is AlgebraicNumber. So seeing sqrt(2) does mean what exactly? A number x such that x^2=2 or the positive number y such that y^2=2? Anyway, AlgebraicNumber claims: ++ Description: Algebraic closure of the rational numbers, with ++ mathematical = Is a non-transitive = still mathematical? BTW, = is mapped to trueEqual from InnerAlgebraicNumber. And that says. trueEqual : (%,%) - Boolean ++ trueEqual(x,y) tries to determine if the two numbers are equal That is not a specification. If I were a programmer that were asked to implement such a function, I would write a function that throws a dice and depending on the output returns true or false. At least my function has tried. ;-) Anyway, without knowing which of the possible roots the given element is, there is no way to compare correctly. Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] AlgebraicNumber
Ralf Hemmecke wrote: On 06/10/2010 12:43 PM, Bertfried Fauser wrote: a := sqrt((sqrt(5) + 3)/2) b := (sqrt(5)+1)/2 (51) - (a=b)::Boolean (51) true c:= -(sqrt(5)+1)/2 (4) - (a=c)::Boolean (4) true (6) - (b=c)::Boolean (6) false Type: Boolean so equality is here a fishy concept... P why is it always me that runs into bugs? I would not call the above a bug: this is fundamental limitation of AlgebraicNumber. Conceptually it similar to fact that you can not divide by 0. If you are unhappy with limitations of AlgebraicNumber use RealClosure(Fraction(Integer)) or possibly Complex(RealClosure(Fraction(Integer))). Note however that also RealClosure currently does not simplify your expression. Simply, detecting that number is a square requires extra effort. In simple cases like your example an ad-hoc rule would do. But Axiom philosophy was to strive for general solution and general solution requires much more work. -- Waldek Hebisch hebi...@math.uni.wroc.pl -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] AlgebraicNumber
P why is it always me that runs into bugs? I would not call the above a bug: this is fundamental limitation of AlgebraicNumber. Well, I call it a bug if the specification doesn't match the implementation. Even if the documentation is wrong (which obviously is then), it's a bug. But Axiom philosophy was to strive for general solution and general solution requires much more work. I know and I like that. Actually, Axiom failed why nobody would admit that the answer that was returned by Axiom was right, even if it was unexpected. As I said, in some sense I believe that it is right to not simplify. That is probably similar to the bug of simplifying sqrt(x^2) to x for any x. Anyway... lots of work ahead of us. ;-) Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
