#4771 algsys fails due to 0 resolvent

[Eric Majzoub]

Given

eqs:[g17762*sqrt(sin(p)^2*sin(t)^2+cos(p)^2*sin(t)^2+cos(t)^2)
         +g17761*(%i*sin(p)*sin(t)+cos(p)*sin(t))-g17762*cos(t),
        g17761*sqrt(sin(p)^2*sin(t)^2+cos(p)^2*sin(t)^2+cos(t)^2)
         +g17762*(cos(p)*sin(t)-%i*sin(p)*sin(t))+g17761*cos(t)];
unks:[g17761,g17762];

algsys fails:

(%i18) algsys(eqs,unks);
(%o18) [[g17761 = 0,g17762 = 0]]

linsolve succeds:

(%i19) linsolve(eqs,unks);
solve: dependent equations eliminated: (2)
(%o19) [g17761 = %r3,
        g17762 = -(((%i*%r3*sin(p)+%r3*cos(p))
               *sqrt(sin(p)^2*sin(t)^2+cos(p)^2*sin(t)^2+cos(t)^2)
               +(%i*%r3*sin(p)+%r3*cos(p))*cos(t))
               /((sin(p)^2+cos(p)^2)*sin(t)))]

After using trigsimp on the equations they reduce to:

g1*exp(%i*p)*sin(t)+g2*(1-cos(t))=0
g1(1+cos(t)) +g2*exp(-%i*p)=0

solving by hand yields

g2*( ( sin(t)^2-sin(t)  )/(cos(t)-1) )=0

The function ( ( sin(t)^2-sin(t) )/(cos(t)-1) ) has a simple pole at t=%pi, but I don't know if this is the issue.

Strangely linsove fails after trigsimp-ing the equations.

(%i20) linsolve(trigsimp(eqs),unks);
(%o20) [g17761 = 0,g17762 = 0]

A combo of chatGPT and Claude came up with (after lots of prompting and eliminating false fixes):

Claude says: (after it's own failed guesses)
That's a good lead from ChatGPT. Let me trace through the logic
carefully.Now I have enough to give a precise answer. Let me trace the
full execution path for your input.

---

The Real Bug: presultant Returns Zero, Then lofactors Returns

(0), Causing a Spurious g17761 = 0 Solution

ChatGPT is on the right track but slightly imprecise about where the
zero is introduced. Here is the exact chain:

Step 1: What your equations look like as polynomials

Your two equations are linear in g17761 and g17762:

eq1 = g17761 * A(p,t) - g17762 * B(p,t)    (linear in both gensyms)
eq2 = g17761 * C(p,t) + g17762 * D(p,t)

where A, B, C, D are trig expressions in p and t that are
not polynomial in the solution variables [g17761, g17762] —
they're just coefficients.

Step 2: algsys1 calls presultant to eliminate one variable

algsys1 picks (say) g17762 as vartorid and calls:

(presultant eq1 eq2 g17762)

The resultant of two linear polynomials f = A·x + B and `g = C·x

• Dwith respect tox` is:

Res(f, g, x) = A·D - B·C

This is the Sylvester determinant — a 2×2 determinant. For your
system, this works out to:

A(p,t)·D(p,t) + B(p,t)·C(p,t)

Now here is the crux: your equations are constructed such that this
combination of trig functions is identically zero for all p and
t. (This makes sense — the system is underdetermined or the two
equations are proportional up to the trig structure.) So presultant
returns the polynomial 0.

Step 3: lofactors on zero returns (0)

(defun lofactors (poly)
  (let ((main-var-poly (pfreeofmainvarsp poly)))
    (cond
      ((pzerop main-var-poly) '(0))   ;<--- hits this branch
      ...)))

So lofactors on the zero resultant returns '(0).

Step 4: combiney silently drops (0) entries

(defun combiney (listofl)
  (unless (member nil listofl)
    (combiney1 (delete '(0) listofl :test #'equal))))

The (0) from the zero resultant is deleted before combiney1
runs. This means the resultant equation contributes no constraint at
all — it's as if it never existed. The system is then solved with
only the remaining equations, which is incomplete.

Step 5: bakalevel1 falls into the single-polynomial branch

With the zero resultant discarded, algsys recurses with a reduced
system. Eventually bakalevel1 hits the (t ...) branch (single poly,
single var) and calls callsolve on one of the original linear
equations — say g17761 * A(p,t) - g17762 * B(p,t) — treating g17762
as already known (but it isn't!). Since g17762 has no assigned value,
the coefficient of g17761 is treated as a non-constant expression,
and callsolve / solve extracts g17761 = 0 as a solution (it
factors out g17761 as if the coefficient of the remaining term might
be zero, or the polynomial is seen as g17761 · (something) and
g17761 = 0 is extracted as a root of the leading coefficient being
zero).

The actual root cause

The resultant of the two equations with respect to a solution variable
is identically zero because the system is not overdetermined in
the trig variables — the two equations are essentially proportional
in [g17761, g17762] space when viewed through the resultant. The zero
resultant carries no information about the relationship between
g17761 and g17762, but instead of propagating "underdetermined —
free parameter", the (0) deletion in combiney + subsequent
callsolve manufactures a spurious g17761 = g17762 = 0 solution.

Where to look for the fix

The problem is in how algsys1 handles a zero resultant. When
presultant returns zero, it means the two equations are
algebraically dependent with respect to vartorid — they don't
uniquely determine it. The correct behavior is to recognize this and
either:

1. Try a different variable to eliminate (since eliminating
   vartorid gave no information), or
2. Treat one equation as redundant and continue with the other plus
   a free parameter.

Currently neither happens. Instead the zero just propagates silently
through lofactors → combiney → deletion, losing the constraint
entirely, and then callsolve produces a degenerate zero solution from
an unconstrained polynomial.

The most targeted fix would be in algsys1: check whether presultant
returns zero before proceeding, and if so, either skip that variable
choice or fall back to bakalevelsolve/addparam logic.

[David Scherfgen]

Fixed formatting so that one can copy & paste into Maxima.

[Eric Majzoub]

Also, the function ( ( sin(t)^2-sin(t) )/(cos(t)-1) ) is zero everywhere but near the pole.

[Stavros Macrakis]

1) Please specify the version. In 5.49.0, I get a solution.
2) It is only zero when t is a multiple of 2*%pi and has poles for odd multiples of %pi.
But algsys is actually completely oblivious to that. You can substitute sp for sin(p) etc. and get the same results.

[Eric Majzoub]

Thank you for checking, that lead me to the solution. Please mark this as not a bug. There was a tellsimpafter rule in my qm-maxima package that somehow causes the algsys failure. If I don't load the package or remove the tellsimpafter rules, algsys returns an answer. Please forgive all the noise.

[Robert Dodier]

Eric, thanks for following up. I've marked this ticket as "not a bug" as you suggested.