Re: [fricas-devel] bug?: difficulty to extract imaginary part
Waldek, you are amazing!!! A big thanks for the radicalSolve patch. Ralf On 5/16/24 15:12, Waldek Hebisch wrote: On Tue, May 14, 2024 at 03:04:15PM +0200, Ralf Hemmecke wrote: In fact, the value xx is one of radicalRoots(pp) where pp := x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500 Interestingly, when I put xx into Mathematica, I get a much nicer expressions. In[15]:= p1 = Root[pp, 1] // ToRadicals Out[15]= 250 (2729960418308 + 1930373524352 Sqrt[2] - 23569 Sqrt[2 (13416226688183641 + 9486704869150589 Sqrt[2])]) In[25]:= p3 = Root[pp, 3] // ToRadicals Out[25]= 250 (2729960418308 - 1930373524352 Sqrt[2] - 23569 I Sqrt[2 (-13416226688183641 + 9486704869150589 Sqrt[2])]) Can I somehow "convince" FriCAS to return similarly "simple" radical expresssions? With the attached patch I get: (2) -> radical_solve(univariate(pp)) (2) [ ++ |+-+ \|658730414260118770166403625000 \|2 + 931585485794307216540975125000 + +-+ 482593381088000 \|2 + 682490104577000 , ++ |+-+ - \|658730414260118770166403625000 \|2 + 931585485794307216540975125000 + +-+ 482593381088000 \|2 + 682490104577000 , +---+ \|- 1 * ++ |+-+ \|658730414260118770166403625000 \|2 - 931585485794307216540975125000 + +-+ - 482593381088000 \|2 + 682490104577000 , - +---+ \|- 1 * ROOT +-+ 658730414260118770166403625000 \|2 + - 931585485794307216540975125000 + +-+ - 482593381088000 \|2 + 682490104577000 ] Type: Union(List(Expression(Integer)),...) The result looks more complicated, but this is because FriCAS does not pull squares outside square roots. I would be easy to hook this into 'radicalSolve' so that such result is obtainde by default. -- 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/54b9c853-40f1-4c0a-a2e1-4ed73b53b0fb%40hemmecke.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
On Tue, May 14, 2024 at 03:04:15PM +0200, Ralf Hemmecke wrote: > > In fact, the value xx is one of radicalRoots(pp) where > > pp := > x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500 > > Interestingly, when I put xx into Mathematica, I get a much nicer > expressions. > > In[15]:= p1 = Root[pp, 1] // ToRadicals > > Out[15]= 250 (2729960418308 + 1930373524352 Sqrt[2] - >23569 Sqrt[2 (13416226688183641 + 9486704869150589 Sqrt[2])]) > > In[25]:= p3 = Root[pp, 3] // ToRadicals > > Out[25]= 250 (2729960418308 - 1930373524352 Sqrt[2] - >23569 I Sqrt[2 (-13416226688183641 + 9486704869150589 Sqrt[2])]) > > Can I somehow "convince" FriCAS to return similarly "simple" radical > expresssions? With the attached patch I get: (2) -> radical_solve(univariate(pp)) (2) [ ++ |+-+ \|658730414260118770166403625000 \|2 + 931585485794307216540975125000 + +-+ 482593381088000 \|2 + 682490104577000 , ++ |+-+ - \|658730414260118770166403625000 \|2 + 931585485794307216540975125000 + +-+ 482593381088000 \|2 + 682490104577000 , +---+ \|- 1 * ++ |+-+ \|658730414260118770166403625000 \|2 - 931585485794307216540975125000 + +-+ - 482593381088000 \|2 + 682490104577000 , - +---+ \|- 1 * ROOT +-+ 658730414260118770166403625000 \|2 + - 931585485794307216540975125000 + +-+ - 482593381088000 \|2 + 682490104577000 ] Type: Union(List(Expression(Integer)),...) The result looks more complicated, but this is because FriCAS does not pull squares outside square roots. I would be easy to hook this into 'radicalSolve' so that such result is obtainde by default. -- 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/ZkYGNdknTVOqpxEs%40fricas.org. --- ../fr-build123/src/algebra/ROOTUT.spad 2024-05-14 21:03:24.609019133 + +++ ROOTUT.spad 2024-05-16 13:04:03.656821580 + @@ -14,6 +14,10 @@ ++ complex_roots(p) computes roots of p in terms of radicals ++ separating real and complex roots. ++ Returns "failed" when unsuccessful. +radical_solve : UP -> Union(List(F), "failed") + ++ radical_solve(p) tries to solve polynomial p in terms + ++ of radicals. + ++ Returns "failed" when unsuccessful. quartic2 : (UP, F) -> Union(r_rec, "failed") ++ quartic2(p) should be local but conditional my_sqrt : F -> F @@ -33,6 +37,8 @@ root_pair(a : F, b : F) : C_rec == [a, b] +my_imag := sqrt(-1) + root4(a : F) : F == rec := froot(a, 4)$PolynomialRoots(IndexedExponents(K), K, R, P, F) p1 := monomial(1, rec.exponent)$UP - rec.radicand::UP @@ -249,4 +254,14 @@ (d = 4) => quartic(p) "failed" +radical_solve(p : UP) : Union(List(F), "failed") == +r1u := complex_roots(p) +r1u case "failed" => "failed" +r1 := r1u@r_rec +res := reverse!(r1.reals) +for c1 in r1.complexes repeat +res := cons(c1.real + my_imag*c1.imag, res) +res := cons(c1.real - my_imag*c1.imag, res) +reverse!(res) +
Re: [fricas-devel] bug?: difficulty to extract imaginary part
On Wed, May 15, 2024 at 07:28:50PM +0800, Qian Yun wrote: > OK, so for radicals, there should be a much more effective > method to determine its sign. Seems like current method is > mostly focused on polynomials and pretty limited for radicals. We are looking at sign of argument to a radical. This argument can be a general expression, so we 'sign' needs to handle general expressions. Possibly we could add special case in 'sign' to handle expressions in radicals, I am not sure how much this would help. -- 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/ZkSd08lQlXkUWJEh%40fricas.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
OK, so for radicals, there should be a much more effective method to determine its sign. Seems like current method is mostly focused on polynomials and pretty limited for radicals. - Qian On 5/15/24 19:12, Waldek Hebisch wrote: On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote: You said before AlgebraicNumber should represent any branch of the root, but here we are talking about the sign of radical. Does that mean we are taking a specific branch interpretation here? Yes. Othewise there is problem with meaning of 'imag'. Also note that this is in extra package, not in core domains. -- 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/2a34dffa-4913-492a-827e-6cc0ccda0953%40gmail.com.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote: > You said before AlgebraicNumber should represent any branch > of the root, but here we are talking about the sign of radical. > > Does that mean we are taking a specific branch interpretation here? Yes. Othewise there is problem with meaning of 'imag'. Also note that this is in extra package, not in core domains. -- 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/ZkSYt8EiS26Fl1ac%40fricas.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
You said before AlgebraicNumber should represent any branch of the root, but here we are talking about the sign of radical. Does that mean we are taking a specific branch interpretation here? - Qian On 5/15/24 17:42, Waldek Hebisch wrote: TrigonometricManipulations (which implements imag) is using sign$ElementaryFunctionSign to determine if a root is complex. 'sign' may return "failed" and 'imag' treats this the same as nonnegative, so assumes that root is real. 'sign' for numbers tries interval approximation. If precision it too low, then this fails and 'sign' returns "failed"... Mathematically determining sign of numbers (which is needed to choose form of roots) requires numerical computation potentially of much higher precision than input data. So there will be a cutoff or we would run out of memory (or time) in some cases. So one question is how hard FriCAS should try, currently FriCAS just uses current numeric preciion and do not try to escalate. Another question is what to do in case of failure. Honestly FriCAS should return "failed" or signal error in such case. 'sign' returns "failed" which IMO is OK. Probably 'imag' should signal error. I can guess that possibly users call 'imag' and related functions without real need, so lying (as done now) could be a pragmatic choice. Or simply this is piece of research code that never really get finished. -- 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/a4d24015-4613-4526-9e4e-dbd5ba718c60%40gmail.com.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
Thank you, Waldek, that explains the behaviour much better. I suspected that there must be some numerics involved, but when I had put debugging output near places where I saw Float-s, that never appeared, so I got a bit confused and didn't want to waste more time on this. Potentially, I would be in favour of letting imag or real fail if the sign cannot be determined correctly. In that case the error message should contain a hint that it might be helpful to increase the Float digits. On the other hand, it looks like FriCAS is anyway spitting out radical expressions that are more complicated than needed. I tried rsimp on them but that failed, unfortunately. Seemingly Mathematica is trying harder in ToRadicals. https://reference.wolfram.com/language/ref/ToRadicals.html Side remark. I am actually not so happy with the name rsimp or rootSimp. Cannot FriCAS stick to the convention that we have full words and no abbreviations in function names? 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/6df3d8e5-1027-4b19-a84b-63f404d30780%40hemmecke.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
On Wed, May 15, 2024 at 07:19:08AM +0200, Ralf Hemmecke wrote: > On 5/15/24 01:21, Qian Yun wrote: > > One possible explanation: > > > > )compile a spad file clears internal Kernel cache. > > > > So the following computation can have messed up Kernel order. > > > > So after compiling a spad file, do not use kernels created before that. > > > OK, that explains some of the oddity, but not why "digits 20" makes it to > fail and "digits 21" sometimes helps to make it work and sometimes not. TrigonometricManipulations (which implements imag) is using sign$ElementaryFunctionSign to determine if a root is complex. 'sign' may return "failed" and 'imag' treats this the same as nonnegative, so assumes that root is real. 'sign' for numbers tries interval approximation. If precision it too low, then this fails and 'sign' returns "failed"... Mathematically determining sign of numbers (which is needed to choose form of roots) requires numerical computation potentially of much higher precision than input data. So there will be a cutoff or we would run out of memory (or time) in some cases. So one question is how hard FriCAS should try, currently FriCAS just uses current numeric preciion and do not try to escalate. Another question is what to do in case of failure. Honestly FriCAS should return "failed" or signal error in such case. 'sign' returns "failed" which IMO is OK. Probably 'imag' should signal error. I can guess that possibly users call 'imag' and related functions without real need, so lying (as done now) could be a pragmatic choice. Or simply this is piece of research code that never really get finished. -- 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/ZkSDlnGKt-C-mlBf%40fricas.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
On 5/15/24 01:21, Qian Yun wrote: One possible explanation: )compile a spad file clears internal Kernel cache. So the following computation can have messed up Kernel order. So after compiling a spad file, do not use kernels created before that. OK, that explains some of the oddity, but not why "digits 20" makes it to fail and "digits 21" sometimes helps to make it work and sometimes not. 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/7c8e18f9-b3e0-40d3-9aeb-2a1457a00b79%40hemmecke.org.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
One possible explanation: )compile a spad file clears internal Kernel cache. So the following computation can have messed up Kernel order. So after compiling a spad file, do not use kernels created before that. - Qian On 5/14/24 22:40, Ralf Hemmecke wrote: Some more experiments with the imaginary part... Can someone reproduce/explain the strange behaviour of the attached script? Please modify the path to efstruc.spad accordingly. 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/36eefa4a-975a-4502-8420-95311e4908ff%40gmail.com.
Re: [fricas-devel] bug?: difficulty to extract imaginary part
Some more experiments with the imaginary part... Can someone reproduce/explain the strange behaviour of the attached script? Please modify the path to efstruc.spad accordingly. 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/cf04eed8-78d4-4849-8b86-cb5b23bb1958%40hemmecke.org. pp := x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500 xxx := radicalRoots(pp,'x)$RadicalSolvePackage(INT); x4 := xxx.4 imag x4 -- returns 0 digits 21 -- returns 20 imag x4 -- gives radical expression )co /home/hemmecke/g/fricas/src/algebra/efstruc.spad imag x4 -- returns 0 digits 21 -- returns 20 imag x4 -- returns 0 xxx := radicalRoots(pp,'x)$RadicalSolvePackage(INT); x4 := xxx.4 imag x4 -- gives radical expression digits 20 -- returns 21 imag x4 -- returns 0
Re: [fricas-devel] bug?: difficulty to extract imaginary part
Trying pp := x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500 xxx := radicalRoots(pp,'x)$RadicalSolvePackage(INT) x4 := xxx.4 )set mess bot on in a fresh session gives %%% (14) -> imag(x4) Function Selection for imag Arguments: EXPR(INT) [1] signature: EXPR(INT) -> EXPR(INT) implemented: slot (Expression (Integer))(Expression (Integer)) from TRIGMNIP(INT,EXPR(INT)) [2] signature: EXPR(COMPLEX(INT)) -> EXPR(INT) implemented: slot (Expression (Integer))(Expression (Complex (Integer))) from CTRIGMNP(INT,EXPR(COMPLEX(INT))) (14) 0 Type: Expression(Integer) Interestingly, in the session where I originaly started with, I now get ... (see below). Isn't that weird? Unfortunately, I cannot reproduce what actually caused that different behaviour for the same thing. Oh... the modifying behaviour comes from %%% (20) -> digits 1000 After that, I also get a non-zero expression for imag(x4) Very weird. Ralf %%% (476) -> imag(x4) Function Selection for imag Arguments: EXPR(INT) [1] signature: EXPR(INT) -> EXPR(INT) implemented: slot (Expression (Integer))(Expression (Integer)) from TRIGMNIP(INT,EXPR(INT)) [2] signature: EXPR(COMPLEX(INT)) -> EXPR(INT) implemented: slot (Expression (Integer))(Expression (Complex (Integer))) from CTRIGMNP(INT,EXPR(COMPLEX(INT))) (476) ROOT 9 * ROOT 17298950126166306420162339540714414395414132884375_ 0 * +-+ \|3 + 4115957937119953121577632743454820763125572620312500_ 000 / +-+ 27 \|3 , 3 ^ 2 + - 3353707748962085780804311500 * ROOT 1729895012616630642016233954071441439541413288437_ 50 * +-+ \|3 + 411595793711995312157763274345482076312557262031250_ / +-+ 27 \|3 , 3 + - 2983052524780179281012889654871250 * ROOT 9 * ROOT 172989501261663064201623395407144143954141328_ 843750 * +-+ \|3 + 41159579371199531215776327434548207631255726203_ 1250 / +-+ 27 \|3 , 3 ^ 2 + 1676853874481042890402155750 * ROOT 17298950126166306420162339540714414395414132884_ 3750 * +-+ \|3 + 4115957937119953121577632743454820763125572620312_ 50 / +-+ 27 \|3 , 3 + - 2983052524780179281012889654871250 / 9 * ROOT 1729895012616630642016233954071441439541413288437_ 50 * +-+ \|3 + 411595793711995312157763274345482076312557262031250_ / +-+ 27 \|3 , 3 + 457774470494337034383922238074631487360 * ROOT 1729895012616630642016233954071441439541413288437500_ 000 * +-+ \|3 + 41159579371199531215776327434548207631255726203125_ 0
[fricas-devel] bug?: difficulty to extract imaginary part
Admittedly, it might be difficult to extract the imaginary part of a radical expression. But that seems to look like a bug. %%% (412) -> xx := (sqrt-12669586846893008563685878644359325*sqrt(3)+15974693204716576905254784724655502)*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)^2+(-67615986592587035466691416966582408055125*sqrt(3)+821740289047917709780724897960341922041105837572675)*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)-459312795788070953463924609071094783857961327836964949261184950775056683926250)*sqrt(((-5401066809391479730461765*sqrt(3)+6810039372933885991985941)*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)^2+350309307974348801178797713602530615275150*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)+195805840114519893975560802794745146734717590176215734222479801537500)/138)+(7545807720155193789175416466004323699304125570320134642111002152000*sqrt(3)-9514277361926389947282976273315380030933869226246299623513717108800)*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)^2-48941566061703353092027102734653684371144117066589419560010587508867726730881752*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)+5471190311582478871352357148893202425611330434336312417691091115388863091187332686793683064052757916000)/32996199040131120862458002308760594)-7644000*sqrt(((-5401066809391479730461765*sqrt(3)+6810039372933885991985941)*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)^2+350309307974348801178797713602530615275150*nthRoot(137198597903998437385921091448494025437519087343750*sqrt(3)+172989501261663064201623395407144143954141328843750, 3)+195805840114519893975560802794745146734717590176215734222479801537500)/138)+910529363046002164117823498623484280)/13341283000877183927156400; Type: AlgebraicNumber %%% (413) -> ee := xx::Expression(INT); Type: Expression(Integer) %%% (414) -> imag(ee) $ TrigonometricManipulations(ZZ, EX(ZZ)) (414) 0 Type: Expression(Integer) %%% (415) -> imag ee (415) 0 Type: Expression(Integer) %%% (416) -> ee::Complex(Float) (416) - 69137.1165280576_4221 + 123509.3125610854_8141 %i Type: Complex(Float) In fact, the value xx is one of radicalRoots(pp) where pp := x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500 Interestingly, when I put xx into Mathematica, I get a much nicer expressions. In[15]:= p1 = Root[pp, 1] // ToRadicals Out[15]= 250 (2729960418308 + 1930373524352 Sqrt[2] - 23569 Sqrt[2 (13416226688183641 + 9486704869150589 Sqrt[2])]) In[25]:= p3 = Root[pp, 3] // ToRadicals Out[25]= 250 (2729960418308 - 1930373524352 Sqrt[2] - 23569 I Sqrt[2 (-13416226688183641 + 9486704869150589 Sqrt[2])]) Can I somehow "convince" FriCAS to return similarly "simple" radical expresssions? Thank you 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/e4f512ad-6e32-44eb-a948-b0692f60a460%40hemmecke.org.
