DrudgeCAS / gristmill / 31896575864

91%

master: 92%

push

github

fix: Stop unordered iteration deciding the optimization result

Two containers with unspecified iteration order were feeding the result.

`_optimize_prod` built its dimension-to-factor map by looping over
`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.  Fingerprinting
the CCSD energy evaluation over eight `PYTHONHASHSEED` values gave eight
different answers.

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 `for k, v in res.items()` visited the
subproblems in a different order on Linux and on macOS.

The second one was not cosmetic.  The order the intermediates are formed
in decides which 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.  Everything previously recorded about
these being broken was measured on macOS.

Loop over the dimensions in their own order, which is deterministic and
also the natural one, and sort the memoir before walking it.  Eight hash
seeds now 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.

Note the descending sort is a choice, not a formality: ascending loses the
effective T.  That the answer depends on the order at all is a weakness of
the greedy constriction, and is left as it is.

Also import `Symbol` in the matrix tests.  It is used by
`test_factorization_needing_canonicalization`, which had been dying on a
`... (continued)

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

1783 of 1954 relevant lines covered (91.25%)

0.91 hits per line