kreckel wrote: I think the benefit would still be large, even if coverage isn't 100%. See below. This is exactly what I have done. As mentioned, I will post that solution here in the next few days. This works well, but is very slow, as it takes something that is sub-linear in the size of the expression tree and makes it O(n^2). If GiNaC expression tree nodes had a unique identifier, this approach could achieve sub-linear performance. Specifically, it would be linear in the size of the unique subexpressions, not the size of the actual expression. (If you have a lot of sharing, your expression can be large, but the number of unique expressions can be small.) Even if GiNaC doesn't identify every single instance of a shared sub-expression, the benefits could still be large. In fact, I tried an experiment to test this. I treated ex::gethash() as a unique identifier, even though it isn't. The code I generated was wrong, of course, but it was very fast to generate it, and very fast to compile and execute. Thus, whatever number of unique expressions were not actually identified as such was small enough that this approach would still be quite useful. Also, FYI, when using the hash value as a unique identifier, I only got a few collisions out of thousands of sub-expressions. That is, I only found a few expressions with the same hash even though they were different expressions. Thanks, Doug |