OpenFermion-Cirq
OpenFermion-Cirq copied to clipboard
quantumlib
Test that code in Jupyter notebooks gives correct output
I've found that this currently does not work because of things like
print(operator)
where operator is a SymbolicOperator from OpenFermion. The reason is that SymbolicOperator.__str__ iterates over the terms dictionary and the order of iteration is unpredictable in versions of Python less than 3.7. This causes Jupyter notebooks run in different environments (e.g. my computer vs. Travis's server) to have different outputs. One solution to this is to have SymbolicOperator store terms as an OrderedDict.
I don't think we want these to be OrderedDicts. Why do you care if it prints terms in a different order? Just for testing purposes? That is not a good reason to make this fairly substantial change to perhaps the most important data structure in OpenFermion.
Okay, then what do you think about having SymbolicOperator print its terms in some canonical order? I think this would be useful anyway for visually comparing different operators. I don't think we need to worry about the cost of sorting the terms because if your operator is large enough where it matters then you probably don't want to be printing it out anyway.
That sounds like a better idea. I'm not opposed to it but I also don't view this is a priority.
I recommend sorting the terms in __str__ before you output them. That's what I always do (e.g. see XmonSimulateTrialResult in cirq). It makes the method actually testable.
The test was removed in #158 so this is an issue again. Not a high priority for me right now though.
This is not a super high priority, but its pretty important because otherwise future changes to the library will definitely break the tutorials without us noticing. Is there a problem with what I did in OpenFermion? Not fancy enough for you? lol
The way OpenFermion currently tests notebooks doesn't test that the output is correct. I guess it's better than nothing though. I can easily add a test that simply runs the code though without checking the output though.
Well very often the sort of changes we're most worried about are changes to the interface that cause very obvious execution failures rather than a subtle change to the output. So this is definitely better than nothing.