hp.cc modifications

[AndresFerCervell]

Description of the changes in this PR

This PR has two goals:
-Adjust the orientation that takes the tracer when hp algorithm begins.
-Refactor the termination_condition so that it does not rely on magical numbers, and it adapts to each game.

The first part is already complete. As mentioned in PR #1007, 8 games from contrib/games did not reach an equilibirum because in the first steps of the tracing procedure, the orientation was wrong and it started with negative values of t, leading to a wrong result, or an infinite loop.

Now, if that happens, (t <wrong_orientation_tol = -1.0e-4), the tracer starts again from the beginning with the orientation inverted. This way it is ensured that t increases this second try.

After doing this, only wink3.nfg fails to converge to an equilibrium, with a regret of 4.15e-05.
This problem can be easily solved by adjusting c_maxDist =0.2 , in path.cc.

Callback function has been simplified to make it more legible.

How to review this PR

Test some of the games from catalog and contrib and check whether they reach an equilibrium or not.

[AndresFerCervell]

This new commit identifies whether the result is an equilibrium or not, considering how far we are from the target t value. If the profile´s MaxRegret is higher than the error tolerance (derived from the paper´s formula when t = 1 +- delta), an empty list is returned.

The previously mentioned game (contrib/games/wink3.nfg) fails this condition, and an empty list is returned as expected.

Last meeting we also discussed a better way to stop exactly when t=1. Regarding that, I have observed that some games do indeed stop too far from 1 using the current method. For example:

-contrib/games/vd.nfg keeps running until t=1.50231. The regret of the result is low (it returns a NE of the game), so the tests does not fail.

-g2.nfg and g1.nfg show similar problems, reaching t=1.40793 and t=1.32698 respectively.

This happens because I allow it in the termination function when stating that t can grow until 1.5. If I reduce that number, some games, when the step is larger, do not reach t=1. You proposed that it would be great to dynamically change the step size.

The only way that I have found to do so, is by changing path.cc. And it works!
Adding a line such as:
h = std::min(h, std::abs((1.0 - x[1]) / (t[1] * p_omega)) * 0.7); before the predictor step fixes the problem of wink3 and gets that the max t reached in every game is exactly 1. Note that multiplication 0.7 intends to reduce the size of the step so that it never outreaches t=1.

Using this, t_tol can be reduced from 0.5 to 1e-7 and still pass every test.
The problem is, of course, that this line is only useful for hp and would destroy logit. In tomorrow´s meeting I would like to discuss this topic to find the best way to refactor path.cc.

[tturocy]

The orientation fix is a good catch and actually this is normal in these systems - the orientation of the curve is in some sense arbitrary so we need something which figures out which is the direction that goes the way we want to go (into positive t). Let's just make this change separately as it's an independent matter.

The refinement of the termination condition is a separate item and also touches on some of the problems you're seeing in the test cases - I'll comment on those there.

[tturocy]

See comment in main thread - let's make a PR focusing just on the orientation issue and figure the best way to handle it.

Termination is a separate question and we should deal with that in a separate line.