Skip to content
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

Open
nimgould opened this issue Jun 25, 2024 · 3 comments
Open

something awry in documentation for spral_scaling #217

nimgould opened this issue Jun 25, 2024 · 3 comments
Labels

Comments

@nimgould
Copy link
Contributor

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.

@jfowkes
Copy link
Contributor

jfowkes commented Jun 25, 2024

I would assume not as the example code explicitly passes SPRAL_MATRIX_REAL_SYM_INDEF to the matrix printing utility and that should print out that it is a real symmetric indefinite matrix as you can see from its printing code here:

spral/src/matrix_util.f90

Lines 396 to 398 in 4a0a722

case(SPRAL_MATRIX_REAL_SYM_INDEF)
write(lp, "(a)", advance="no") &
"Real symmetric indefinite matrix, dimension "

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.

@jfowkes jfowkes added the docs label Jun 25, 2024
@nimgould
Copy link
Contributor Author

nimgould commented Jul 7, 2024

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).

@jfowkes
Copy link
Contributor

jfowkes commented Jul 8, 2024

Looks like a typo from the paper, we should probably correct the docs to say that the product is over nonzero sigma_i,j.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants