Infix/postfix/nary redefinition issue (was loading to_poly_solve has side-effect).
serge de marre <[email protected]> Tue, 28 Jul 2026 13:01:11 +0200
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <CAON_BKy+ncem=6JBSu9P-0YU6KRE2nfaNWcZ0wttjtw_gzFQ6g@mail.gmail.com> |
--===============5779222411273654401== Content-Type: multipart/alternative; boundary="0000000000006344440657a9c24f" --0000000000006344440657a9c24f Content-Type: text/plain; charset="UTF-8" Hi all, Turns out the issue has nothing to do with to_poly_solve itself, but with operator (re)definitions. it's not just with nary, but also with prefix, postfix, infix, nofix and matchfix. I've added a bug entry in sourceforge ( Maxima -- GPL CAS based on DOE-MACSYMA / Bugs / #4883 Redefining an operator to be infix/postfix/nary causes a parser bug <https://sourceforge.net/p/maxima/bugs/4883/> ) , with steps to reproduce. I've also attached a testcase to that sourceforge issue, a testcase that currently fails and that should pass (I think). I've used claude to assist with the investigation (and the writing of the test), and it suggested 2 fixes that I can provide (or I could create a pull request), The fixes make the provided testcase pass, as well as the 19700+ tests of the current run_testsuite(share_tests=true); serge --0000000000006344440657a9c24f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div id=3D"gmail-:2i6" class=3D"gmail-Am gmail-aiL gmail-a= O9 gmail-Al editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label=3D"Me= ssage Body" role=3D"textbox" aria-multiline=3D"true" tabindex=3D"1" style= =3D"direction:ltr;min-height:85px" aria-controls=3D":2kv" aria-expanded=3D"= false"><div id=3D"gmail-:2i6" class=3D"gmail-Am gmail-aiL gmail-aO9 gmail-A= l editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label=3D"Message Body= " role=3D"textbox" aria-multiline=3D"true" tabindex=3D"1" style=3D"directio= n:ltr;min-height:85px" aria-controls=3D":2kv" aria-expanded=3D"false">Hi al= l,<div><br></div><div>Turns out the issue has nothing to do with to_poly_so= lve itself, but with operator (re)definitions.</div><div>it's not just = with nary, but also with prefix, postfix, infix, nofix and matchfix.</div><= div>I've added a bug entry in sourceforge ( <a href=3D"https://sourceforge.net/p/maxima/bugs/4883/">Maxima -- GPL CAS b= ased on DOE-MACSYMA / Bugs / #4883 Redefining an operator to be infix/postf= ix/nary causes a parser bug</a>=C2=A0) , with steps to reproduce.</div><div= >I've also attached a testcase=C2=A0to that sourceforge issue, a testca= se that currently fails and that should pass (I think).</div><div>I've = used claude to assist with the investigation (and the writing of the test),= and it suggested 2 fixes that I can provide (or I could create a pull requ= est),</div><div>The fixes make the provided testcase pass, as well as the 1= 9700+ tests of the current run_testsuite(share_tests=3Dtrue);</div><div><br= ></div><div>serge</div></div></div></div> --0000000000006344440657a9c24f-- --===============5779222411273654401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5779222411273654401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Maxima-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maxima-discuss --===============5779222411273654401==--