DrudgeCAS / gristmill / 31897820394

92%

push

github

fix: Stop unordered iteration deciding the optimization result (#39)

Two containers with unspecified iteration order were feeding the result.

`_optimize_prod` built its dimension-to-factor map from `factor.atoms(Symbol)`,
a set.  That order set the insertion order of `factors_with`, then of
`involv_dims`, then the order the dimension chunks were built in and the
order of dimensions within each chunk, and finally the index order of the
intermediates.  `dim_chunks.sort()` does not repair it, since `Tuple4Cmp`
compares on its first element alone.  Eight `PYTHONHASHSEED` values gave
eight different evaluation sequences for the CCSD energy equation.

The memoir from libparenth arrives as a dictionary built from a C++
`std::unordered_map`, whose iteration order is implementation defined.
libstdc++ and libc++ disagree, so the subproblems were visited in a
different order on Linux and on macOS.  That decides which intermediates
get matched against each other, and macOS was landing on a worse answer
than Linux for the same input: on Linux the effective T of the CCSD energy
equation was found and both matrix factorizations worked, on macOS none of
the three did.

Sort both.  Ubuntu and macOS now give identical results, 37 passed on
each, and eight hash seeds give one answer.

With that the `> 0` assertion in `test_ccsd_energy` holds again and both
xfails in the matrix tests pass, so all three markers come off.

The descending sort is a choice rather than a formality, since ascending
loses the effective T.  That the answer depends on the order at all is
tracked separately in #43.

Also import `Symbol` in the matrix tests, where
`test_factorization_needing_canonicalization` had been dying on a
`NameError` before reaching any assertion, hidden by its xfail mark.

Closes #31

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

3 of 3 new or added lines in 1 file covered. (100.0%)

1782 of 1953 relevant lines covered (91.24%)

0.91 hits per line