package name confict
dribnet opened this issue · 5 comments
Would you consider changing the name of this package? It has a naming conflict with this lapjv which is pip installable. I have a proof of concept here where I have renamed it lapjv1, and it works fine. Happy to contribute that or rename it to something else.
Separately but relatedly, would you consider changing the API to return arguments to this:
rowsol_c, colsol_c, cost = lapjv(cost_matrix)This would match the API of the other lapjv implementation so that they could be swapped out programatically.
Yes, to both if you are able to create a PR.
Out of curiosity, what is the reason not to use this package exclusively (a missing pypi entry)?
BTW, the other lapjv has a shady license as it uses the original MagicLogic code which is under a restrictive license.
The rename would actually make sense also because now there is not only the original lapjv algorithm for dense matrices but also the lapmod for sparse matrices. Let's rename it to "lap".
Hi again. I've finally renamed the library again from lapjv to lap in #6 - please let me know what you think. I've tested this with a downstream dependency and it works, but I didn't run any of the unit tests so it's not fully tested.
To answer your other question: the main reason to not use this package exclusively is that for me it seems to hang on larger problems. I can run a cost matrix with lapjv to 500x500 or so in about 8 seconds (and get great results), but if I try 700x700 it doesn't return for at least a few minutes. I can try to debug further if you are curious.
Thanks for the PR, it really helped, I just needed to make some small changes such as removing the cython output cpp.
Concerning the runtime. I am definitely interested in the matrices that trigger the long runtimes. I use the library routinely with >1000x1000 matrices (dense) and >15000x15000 (sparse), usually it runs in a fraction of a second. If it runs significantly more than a second, I'd consider it a bug. I've made some changes now that might improve the situation. Could you give it try and let me know?
If you wanted to debug yourself, I would start with looking at the augmenting row reduction. it is one preprocessing step that can get very long to finish and although it usually helps, it is not absolutely necessary.