Graph match API decisions

[bdpedigo]

should graph matching functionality remain a class or become a function like in scipy?

we are reassessing api of much of the package because of graspologic merge. not sure if we have talked about this one.

@asaadeldin11 thoughts? any reason to have it be a class/function?

[asaadeldin11]

@asaadeldin11 thoughts? any reason to have it be a class/function?

I think it can work as either; the scipy version has a bunch of optional parameters, and returns an OptimizeResult object, so even with wrapping the new scipy function it can still be a class.

[bdpedigo]

@asaadeldin11 some things I have been thinking about:

1. decide whether we want to support a function API
2. I think init keyword "rand" should be "random"
3. I think the docs for .fit and .fit_predict specifically need to clarify which matrix is being permuted. I always have to look elsewhere for this info and I think putting in fit is worth doing.
4. related to the above, we should try to standardize which matrix is "source" and which is "target" as much as possible. functions that do similar things in spirit below. what i mean by similar is all of them take in two matrices, and try to align one to the other, and it matters which matrix is the one "being matched". can we audit those 3 places and make sure we are doing the same thing? and if those conventions differ, lets talk about which would be best for us?
   • QAP in scipy
   • orthogonal procrustes in scipy
   • align in graspologic

[bdpedigo]

@asaadeldin11 wanted to bring this up again - what do you think of a function API closer to what the scipy implementation is like right now? Is there any advantage to having a class currently?

my thoughts on having classes has evolved to be more about "will this object ever take unseen data and operate on it." In the case of graph matching, I think the answer is almost always no (e.g. apply the permutation learned between A and B on C). And if someone wanted to do that, they'd always have the permutation indices...