BGL Johnson's algorithm has undocumented "subtractability" requirement on DistanceMap value type

[Luis G. Torres <lgtorres42@…>]

In the reweighting step of Johnson's algorithm, the implementation assumes that subtraction has been defined on DistanceMap's value type, e.g.

put(w_hat, *e, combine(get(w, *e), (get(h, a) - get(h, b))));

I've thought about whether the reweighting can be done purely through combine() calls, but it seems that the correctness proof for the reweighting relies on the distance value type having subtraction (or equivalently, an inverse).

If this algorithm indeed requires a subtraction/inverse operation on DistanceMap value types, then for consistency it might make sense to include a named parameter for another functor, e.g. distance_subtract.

Another, related issue: the documentation states that distance_combine is a binary function with the 1st parameter as a DistanceMap value type, and the 2nd argument as a WeightMap value type. However, in the following line:

put(w_hat, *e, combine(get(w, *e), (get(h, a) - get(h, b))));

the distance_combine functor is being applied with the arguments in reverse order.

(P.S. I know I've been submitting lots of reports; I really appreciate the hard work that makes BGL awesome!)

[Jeremiah Willcock]

(In [83845]) Flipped arguments to combine calls to match documentation; refs #8428

[Jeremiah Willcock]

(In [83857]) Fixed documentation to be correct; fixes #8428