Fix DiscreteFactorGraph::optimize to return MPE

[dellaert]

Major Changes

This PR fixes #1048. In particular:

• DiscreteFactorGraph::optimize now really computes the MPE (maximum probable explanation)
• added a method DiscreteFactorGraph::maxProduct
• created two versions of each to take OrderingType or Ordering
• deprecated DiscreteBayesNet::optimize and DiscreteConditional::solve, as they do nothing really useful
• removed optimalAssignment in gtsam_unstable/discrete: redundant with optimize. Not deprecated, just gone!

Max-product details:

I introduce two new classes (in one header/cpp):

• DiscreteLookupTable: inherits from DiscreteConditional to play well with generic elimination, but is supposed to be a lookup table of the maximum values obtained during max-product
• DiscreteLookupDAG: a DAG of lookup tables. Made this separate from BayesNet as to not confuse.
• maxProduct is implemented with a custom Eliminate function in DiscreteFactorGraph.cpp

[dellaert]

@keevindoherty FYI. If you relied optimize, there might be discrepancies with the actual MPE.

[varunagrawal]

A few comments. I can address them if need be to save time.

[dellaert]

@varunagrawal sign off? Do you know what could be up with failing CI?

[varunagrawal]

This is the same issue that Fan had, it's a deprecation of the setup.py install command for python.
You can cherry pick this commit to fix it 2a023f7

[dellaert]

Thanks. Done. Note it's not approved yet so I can't merge... Is there anything else?

[varunagrawal]

LGTM

[varunagrawal]

I was literally in the middle of the review :)

[dellaert]

Hmmm, after the cherry-pick, 10 runs are failing rather than 2… any ideas?

[dellaert]

@varunagrawal could you please explain more about your fix? Linux complains:

Disabling all use of wheels due to the use of --build-options / --global-options / --install-options

What was the issue you tried to solve? What article described the fix? You said “ deprecation of the setup.py install command for python”. Where was it=t deprecated?

finally, use of pip directly seems wrong. If anything, $PYTHON$ -m pip ?

[dellaert]

Also, why does not affect the entirety of GTSAM? If so, seems worthy of its own PR in GTSAM, with explanation of issue in PR description.

[varunagrawal]

The Python Packaging Authority has decided to deprecate direct builds via calling setup.py (aka python setup.py install) due to the need to enforce a standard for wheel builds. More details here.

This effect first showed up on MacOS with the following error:

python3 setup.py install --user --prefix=
PACKAGES:  ['gtsam', 'gtsam_unstable', 'gtsam.utils', 'gtsam.examples', 'gtsam_unstable.tests', 'gtsam_unstable.examples']
running install
/usr/local/lib/python3.9/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/usr/local/lib/python3.9/site-packages/setuptools/command/easy_install.py:156: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.

I myself use a pip install -e . for all my projects which basically asks pip to install the local directory in editable mode. Editable mode means the install reflects any local changes we make, making iterative development very easy.

We are now seeing the deprecation effects in Ubuntu as well, so yeah this is going to need a bit of refactoring of the CI. This is something that really annoys me about Github Actions is that they run environment upgrades pretty arbitrarily. I imagine this will effect the entirety of GTSAM going forward.

About using pip directly compared to ${PYTHON} -m pip, they are equivalent. The pip binary is a tiny python script that imports the pip module and executes the command, making it easier. I can do the latter if you'd like.

[dellaert]

Awesome description above. Perhaps you can copy/paste some of the comment above in the (rather terse) comment of #1054 ?

About GA: can't we specify whatever exact version we want ?

About pip: just heard that sometimes pip on path is a different version so #PYTHON -m pip ensures you have the pip version paired with the python version.

[varunagrawal]

We can always do pip$PYTHON_VERSION aka the exact pip version to match the python version as well, but I agree with using python -m pip.