-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
something awry in documentation for spral_scaling #217
Comments
I would assume not as the example code explicitly passes Lines 396 to 398 in 4a0a722
I guess that it is the output for an earlier run/version of the docs where an unsymmetric example was used. Note that in #205 we plan to fix these scaling algorithms so that they always return zeros for unmatched as per your suggestion (and in line with what the documentation actually says that they do), but this will not affect the scalings. |
On reading this documentation more carefully, it is clear that the optimization problem posed in the auction and Hungarian sections is incorrect; the objective can't involve the product as stated, since only one of the sigma_i,j in each row/column can be nonzero, and thus the stated product is always zero. Duff & Koster take the product over only nonzero sigma_i,j (and a_i,j), which makes sense, while Hogg & Scott state the incorrect objective but then use a (log) transformed version of Duff & Koster instead (which is what I presume is implemented). |
Looks like a typo from the paper, we should probably correct the docs to say that the product is over nonzero sigma_i,j. |
I was just looking in the docs for spral scaling, and in particular for the output for the hungarian_scale_sym_example. The input matrix is symmetric, but the output claims that it is unsymmetric (but the values shown are symmetric). Was this output actually generated by the test example ? ... really in docs it always should be!
No big deal, and indeed I just realised that hungarian_scale_unsym and auction_scale_unsym may be exactly what I want to detect dependencies in GALAHAD calculations ... and better than the rather dodgy heuristics I current use! So, good work, team.
The text was updated successfully, but these errors were encountered: