Remove csc_permute and ereach from base/sparse/csparse.jl

[dmbates]

The csc_permute and ereach functions defined in base/sparse/csparse.jl are not exported and, I expect, not used. I have an unregistered CSparse.jl package which I will move to the JuliaSparse group. When that package is registered I suggest that those functions be removed, or if that is too drastic, deprecated then removed.

[tkelman]

Would be best to check whether there are packages currently using that functionality. If there are, I'd rather go with deprecation prior to 0.4 (if you're in a hurry) and/or removal afterwards.

[tkelman]

@KristofferC are you using csc_permute anywhere? You touched it in #12734, any objections to moving it somewhere else, e.g. https://github.com/dmbates/CSparse.jl?

[KristofferC]

I don't use it. I just saw it was untested and found a bug when I added a test for it. Fine by me to move.

[Sacha0]

What are current plans for etree, ereach, symperm, and csc_permute? I am contemplating whether I should replace anything further from base/sparse/csparse.jl after #14702 and #14798, and if so what next. csc_permute should be a short child of qftranspose!, though with multiple dispatch permute(A::SparseMatrixCSC, pinv, q) seems better name-wise. symperm could also be a short child of qftranspose!, though I imagine more efficient approaches to symmetric permutation exist. Thanks, and best!

[tkelman]

symperm and etree are exported, documented and probably more useful than the other two.

It's an outstanding TODO to move SuiteSparse bindings out to a package for licensing (among other) reasons, and I think when that happens it would be natural to move at least the unexported functions (and possibly the exported ones too) at the same time.

[KristofferC]

What is the status on this? Is CSparse.jl ready to be tagged? Now when we have a good sparse function we could probably get rid of all csparse stuff from base julia.

[KristofferC]

cc @dmbates

[dmbates]

The symperm function can be done more cleanly in Julia using Symmetric or Hermitian types with SparseMatrixCSC as the matrix type. I'm not sure if it should be deprecated before being removed.
I guess it would depend on whether packages use it.

The etree function is a bit trickier. I have no doubt that there are people who could write a Julia implementation without looking at the CSparse code but I am not such a person. I believe etree is available in Matlab and might be missed by some users if it was not available. I think it would be best if someone could write a native Julia implementation.

[Sacha0]

Apologies for the radio silence since #15242; I've been focusing on a related project. Writing general and symmetric permutation methods for SparseMatrixCSC remains on my radar. Assuming no code appears in the interim, I plan to give those methods a shot once I have a prototype of the aforementioned project out (in a few weeks). Elimination tree generation is on my horizon as well, though distant.

[KristofferC]

As a first step couldn't they be moved to the csparse package? My hunch is that these methods are not extensively used and if we make sure that it is as simple as a Pkg.add to restore the functionality it would be nice to get rid of one GPL part in Base.

@dmbates what do you think about registering your package and pointing people to that package in the same way we do with PkgDev now?

[tkelman]

LGPL. Doug and git do not seem to get along, so perhaps best if he adds you as a collaborator @KristofferC.

[KristofferC]

I have no problem doing the work needed as long as d people think it is a good idea and @dmbates think his package is ready to be registered. Otherwise I can make a new package which would only contain the functions to be moved from Base.

[dmbates]

@KristofferC Although I would like to go back and look at that code and update it I am facing a deadline at the end of the week. Experience suggests that it is best for me not to start looking at other code right now.

I have added you as a collaborator on the repository. If you think it is worthwhile registering the package please do so. Next week I will try to look at documentation, etc. for this package. I haven't worked on it for a long time.

[tkelman]

closed by #17033, thanks again @Sacha0!!!

[Sacha0]

Thanks to @KristofferC for doing the work rather :).