substitute rejects a partial generator list between two identically-constructed rings, where map(S,R) succeeds

[d-torrance]

This issue was triaged from bugs/dan/1-ring-maps, one of the 857 files removed from the pre-GitHub bugs/ tree by d2c8d27826 and catalogued in #36. The commentary below was written by Claude (Claude Opus 5, via Claude Code), not by @d-torrance, whose account posted it -- please weigh it accordingly.

The original file, verbatim

sigh:

    i11 : R = F()[x,y];I=ideal(x-R_2); S = F()[x,y]; I, sub(I,{R_2=>S_2})

    o12 : Ideal of R
    stdio:5:47:(1):[0]: error: expected ww to be a generator of R

Where it stands today

This still happens, and it is broader than the transcript above suggests: the failure is not about the
coefficient generator, it is about substituting any generator between two rings that were built
separately from the same recipe.

Reproducing it

The F() in the note returns a plain quotient coefficient ring. That detail matters — with GF or
with toField, the coefficient generator is not reachable by index at all and R_2 is
index 2 out of bounds 0 .. 1, so the transcript cannot even be started. With a plain quotient:

zzF = () -> (k0 := ZZ/2[ww]; k0/(k0_0^2 + k0_0 + 1))
R = zzF()[x,y]
S = zzF()[x,y]

R_2                              -- ww     (past numgens, into the coefficient ring)
I = ideal(R_0 - R_2)             -- ideal(x+ww)

sub(I, {R_2 => S_2})
     error: expected substitution values and omitted generators to be in compatible rings

The message differs from the 2009 one ("expected ww to be a generator of R"), but the call still fails.

It is not the coefficient generator

Substituting an ordinary generator fails identically, while the full ring map works:

sub(I, {R_0 => S_0})      -- same error
(map(S,R)) I              -- ideal(x+ww)

So substitute declines a job that map performs, on the same two rings.

What is arguably right about the error

With y omitted from the substitution list, the ring of the result is genuinely ambiguous: y lives in
R, the supplied value lives in S, and M2 has no way to know which the caller wants. Refusing is
defensible on those grounds.

What makes it look incidental rather than principled is that the identical shape is accepted without
complaint when R and S are the same ring, and that map(S,R) demonstrates the intended answer is
computable. If refusing is the right behaviour, the diagnostic is the thing to fix — it does not say that
R and S are distinct rings that happen to print the same way, which is the whole of the difficulty
and is invisible in a transcript where both are displayed as ww.

Related, but not this

• #1224 is QQ[a,a,a] — repeated names within one ring.
• #1183 is about GaloisField coefficient rings, which is
  the shape that here fails earlier, at R_2.
• #1011 asks that the documentation say M2 does not enforce
  well-definedness of ring maps.

_{open · disposition issue · source of truth: bug-triage/catalog.tsv}