Efficient Discrete Elimination

[varunagrawal]

Updated the discrete elimination process to be ultra performant.

Current timing results:

-Total: 0 CPU (0 times, 0 wall, 0.01 children, min: 0 max: 0)
|   -SmootherEstimation: 0.05 CPU (1 times, 0.050323 wall, 0.01 children, min: 0 max: 0)
|   |   -SmootherUpdate: 0.04 CPU (20 times, 0.047821 wall, 0.01 children, min: 0 max: 0)
|   |   |   -assembleGraphTree: 0 CPU (40 times, 0.000758 wall, 0 children, min: 0 max: 0)
|   |   |   -HybridBayesNet PruneDiscreteConditionals: 0 CPU (20 times, 0.008828 wall, 0 children, min: 0 max: 0)
|   |   |   |   -HybridBayesNet DiscretePruning: 0 CPU (20 times, 0.006462 wall, 0 children, min: 0 max: 0)
|   |   |   -HybridBayesNet UpdateDiscreteConditionals: 0.01 CPU (20 times, 0.012406 wall, 0.01 children, min: 0 max: 0)
|   |   |   -HybridBayesNet PruneMixtures: 0 CPU (20 times, 0.001607 wall, 0 children, min: 0 max: 0)

We have successfully obtained sub-millisecond performance on this test.

[dellaert]

Again a PR that seems to be mixing a key new implementation of probabilities and some unrelated TableFactor changes? Split if possible, and I'd love to see

• an explanation in the code as to how the new implementation works and how it assigns a probability for all assignments
• some unit tests with pruned trees? Do they exist already?

[dellaert]

const & ?

[dellaert]

I'd prefer if you don't use the lambda in place but create op using an auto and properly document what it does.

[varunagrawal]

Done

[dellaert]

What is happening here? probs is a vector, right?

[varunagrawal]

Yes. This is adding the value p to probs, nrAssignments times.

[varunagrawal]

Again a PR that seems to be mixing a key new implementation of probabilities and some unrelated TableFactor changes? Split if possible, and I'd love to see

This is because TableFactor is half-baked (the burden of which is again falling on me) and I used this branch to test using the TableFactor in elimination (which doesn't work due to implicit conversions to the DecisionTreeFactor), hence the melding of 2 things.

I also didn't want to waste CI resources and have to wait potentially another couple of weeks for a review, hence the kitchen sink approach.

[varunagrawal]

@dellaert updated as per review. I already have a whole unit test dedicated to pruning in testDecisionTreeFactor.cpp line 126.

[varunagrawal]

@dellaert we'll have to merge in #1592 first in order to get all the tests passing here.