strict equality of complexes

[mahrud]

I closed my earlier issue because the issue is in using === for complexes, not truncation itself:

i1 : R = QQ[x];

i2 : complex R === complex R

o2 = false

This is because Complex inherits from mutable hash table, and there isn't another === method installed.

So perhaps really the issue is using === or =!= for complexes, for instance in liftMapAlongQuasiIsomorphism:

M2/M2/Macaulay2/packages/Complexes/ChainComplexMap.m2

Line 1279 in a816bf9

if N =!= target beta then error "expected targets of two maps to be the same complex";

[mahrud]

The particular issue with the truncation functions (#3865) is that they always construct a new complex, hence they will never be functorial as long as === behaves the way it currently does:

i16 : C = complex R

       1
o16 = R
       
      0

o16 : Complex

i17 : canonicalTruncation(C, (1,1)) === canonicalTruncation(C, (1,1))

o17 = false

[n-m-g]

Yes, the use of "===" is something to be aware of. If this is already causing bugs here then it might also be causing bugs say in the Complexes "Hom" and/or "TensorProduct" chain complexes implementation. However, if one is willing to keep track of "prunning maps" then "==" can sometimes be used as a work around. This might also explain why some examples are returning in error when trying to install the SpectralSequences package. (See the PR #3807).

Do keep me posted.

[mahrud]

I don't think these are related issues.

[n-m-g]

Yes, probably not but do let me know if you encounter any additional bugs with the Complexes package. None of us have yet looked into seriously with issues with why #3807 doesn't work with the latest M2 release (except looking into that code which uses "===" quite a bit may be a place to look at more seriously).

[n-m-g]

As one follow-up, do you know if any of this "===" and/or the Hom/Tensor product code changed from 1.24 to 1.25?

[mahrud]

I have looked into it, and it is not related to === or Hom or tensor. Let's keep this issue focused.

[mahrud]

@mikestillman @ggsmith I understand the reason for making Complex inherit from mutable hash tables. I presume you don't want to change this, so should === and =!= basically never be used with them? e.g. should liftMapAlongQuasiIsomorphism use != instead, or something else?

[ggsmith]

Complex inherits from mutable hash tables because we want the differential to be a ComplexMap. However, we "treat" it as an immutable object.

I think that =!= in liftMapAlongQuasilIsomorphism is correct. We want the targets to literally be identical.

[mahrud]

Do you consider this a bug?

R = QQ[x, y, z] / (x*y - z^2);
C = res(M = R^1 / (x), LengthLimit => 5)
D = res(N = R^1 / (x,y,z), LengthLimit => 5)

f = extend(D, C, cover inducedMap(N, M))
g = id_D
h = f // g
assert(f == g * (f // g)) -- works fine

So targets of f and g are literally the same object here, but in implementing Orlov's functors I needed truncated complex maps and ran into a version of this:

c = concentration C
f' = canonicalTruncation(f, c)
g' = canonicalTruncation(g, c)
f' // g' -- fails with error:
-- i12 : stdio:14:3:(3): error: expected targets of two maps to be the same complex
target f' == target g' -- true

Note that targets of f' and g' are mathematically identical, not just isomorphic:

i15 : target f'

       1
o15 = R  <-- cokernel {1} | 0  -z y  0  |
                      {1} | -z 0  0  x  |
      0               {1} | y  x  -z -z |
              
             1

o15 : Complex

i16 : target g'

       1
o16 = R  <-- cokernel {1} | 0  -z y  0  |
                      {1} | -z 0  0  x  |
      0               {1} | y  x  -z -z |
              
             1

o16 : Complex

So this is failing only because the target is a mutable hash table.

If you also consider this a bug, not a feature, where would you say the source is? I can think of three options:

• === for mathematically identical complexes (not just isomorphic) should be true, but this can't work because they are mutable
• // should not use =!=, which you said is not the case
• canonicalTruncation (and probably many more methods) should produce identical objects given the same input

But maybe I'm missing another option.

[ggsmith]

I do consider this a bug: canonicalTrunction should cache the truncations of the source and target so that it produces identical objects given the same input.

I am reluctant to change the =!= to a == in the method liftAlongQuasiIsomorphism because I fear that it would significantly reduce performance. Testing the equality of complexes can be quite expensive.

[mahrud]

That makes sense. How about comparing the content like C.module === D.module and C.dd.map === D.dd.map instead of C === D? There could be an internal function like isIdentical to do this.

[mahrud]

I just ran into // not working again, and at the core the issue was the following:

R = QQ[x,y];
C = koszulComplex vars R
C === C[1][1][-2] -- false

Same with other things like complex(C[i], Base => 0) === C. Simple caching in Complex[ZZ] doesn't fix this, unless you either have a distinguished shift a complex where all other shifts are cached under, or fundamentally change how the concentrations of complexes are handled so that all shifts of a complex are internally the same.

I also tried to extract the problem in the Orlov functor computation which I mentioned before, but it's pretty convoluted.