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&#39;s not just =
with nary, but also with prefix, postfix, infix, nofix and matchfix.</div><=
div>I&#39;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&#39;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&#39;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==--