Issues with the bottom-up similarity calculator

[bburlacu]

The ​bottom-up tree distance was developed by G. Valiente as an efficient and more flexible alternative to the edit distance. The HL implementation SymbolicExpressionTreeBottomUpSimilarityCalculator follows in detail the algorithm described in the paper, but suffers currently from two issues:

1) The returned similarity incorrectly takes into account the ProgramRootSymbol and StartSymbol for each tree, even though these are always the same, leading to artificially inflated similarity measures

2) No option for loose matching of constants and variable weights

3) The paper suggests handling unordered trees (which is the case when we deal with commutative symbols) by sorting the list of graph nodes associated with the children of the two tree nodes being compared for equality. However, any kind of such sorting may deliver incorrect results in rare cases when a shallow comparison (eg by node label or similar property) does not produce the correct order when the children are same. In such cases when the children appear in different respective orders under the two parent nodes being compared sorting fails to produce a consistent ordering and the matching fails.

[bburlacu]

r16278: Address the issues described in the ticket.

r16279: Simplify code, improve performance, fix another potential bug in relation with 3).

r16283: Refactor bottom-up similarity calculator methods (main logic stays the same, better implementation), update unit tests (more tests will be added).

[gkronber]

Please complete your changes to the trunk until the end of the year.

[bburlacu]

The similarity calculator is done. I need to add more unit tests and then this ticket will be ready for review.

[gkronber]

Please add the unit tests.

[gkronber]

Please make required changes and move to review phase.

[bburlacu]

r16867: Add more unit tests for tree matching, and test bottom-up calculator against hash-based calculator for consistency.

In my opinion, the bottom-up calculator is ready for review. Aside from added unit tests, the calculator successfully validates against the hash-based approach, producing exactly the same average similarity.

[bburlacu]

r16869: Fix compilation errors.

[gkronber]

Reviewed the changesets related to this ticket and made a small change with r17077.

[abeham]

r17091: merged revisions 16278, 16279, 16283 to stable

remaining revisions after #2520: 16867, 16869

[abeham]

r17143: merged 16867, 16869 to stable

[gkronber]

r17160: merged r17077 from trunk to stable (missed while merging the ticket)