At the moment we create a new tensor for every identified common subexpression that we want to eliminate. However, oftentimes these CSEs are used somewhat locally meaning that at a later point in the expression there would be opportunity for reusing the previously created tensor for storing/representing a different CSE. The requirement for this is that the last use of the previous CSE happens before the first use of the new CSE and that both CSEs have the same general shape (i.e. compatible index slots).
This probably doesn't really matter when using SeQuant's evaluation engine but it definitely matters for code export. There, we currently declare thousands of CSE tensors that need to be created and (at least in the current implementation) stored on disk.
We already do this reusage pattern with intermediates that appear due to factorizing everything into binary contractions during export. Presumably, we can salvage quite a few of this logic and also apply it to CSEs.
However, this feature should be optional as it will make the expressions a lot harder to understand for a human being (the same thing can refer to different values, depending on where in the expression you are).
At the moment we create a new tensor for every identified common subexpression that we want to eliminate. However, oftentimes these CSEs are used somewhat locally meaning that at a later point in the expression there would be opportunity for reusing the previously created tensor for storing/representing a different CSE. The requirement for this is that the last use of the previous CSE happens before the first use of the new CSE and that both CSEs have the same general shape (i.e. compatible index slots).
This probably doesn't really matter when using SeQuant's evaluation engine but it definitely matters for code export. There, we currently declare thousands of CSE tensors that need to be created and (at least in the current implementation) stored on disk.
We already do this reusage pattern with intermediates that appear due to factorizing everything into binary contractions during export. Presumably, we can salvage quite a few of this logic and also apply it to CSEs.
However, this feature should be optional as it will make the expressions a lot harder to understand for a human being (the same thing can refer to different values, depending on where in the expression you are).