Rename GraphLasso to GraphicalLasso to avoid ambiguity.

[alexlenail]

Graphical Lasso is a method for sparse inverse covariance estimation.

• Paper
• Sklearn method

Graph Lasso is a method for sparse regression where the features lie on a graph.

• ICML Paper
• Not in sklearn.

These are different methods. Sklearn implements Graphical Lasso but not Graph Lasso, however I believe it wrongly calls Graphical Lasso GraphLasso, which causes some ambiguity. After a very quick search, it seems like the abiguity starts with this library (might be incorrect about this).

[agramfort]

I would just add a note in docstring to avoid painful deprecation cycle

[amueller]

ugh... but we don't want to promote a wrong name, as people pick up our naming schemes.

[jnothman]

no strong opinion. in practice is there much ambiguity? i.e. would they often be used in the same problems. Start with a clarification in the docs in any case as that will have unanimous support, then we can consider if deprecation is worthwhile.

[jnothman]

Thinking about it a bit more, I would be +1 for the name change. I don't think this is among the top-used estimators, and having it more clearly named might help users research/understand if it is appropriate to their needs.

[agramfort]

ok fair enough....

[GaelVaroquaux]

I am -1 on this. We'll never get the namings wrong, and I don't think that it really helps our users to change names for purity reasons. As mentioned above, there is probably not big ambiguity.

I'll plead guilty to this error, by the way. I am willing to take blame for it forever if it may help users :).

This is a weak -1: I don't think that the project will collapse or that the users will lead a revolution if we change this. It's just that such changes are cost on both sides (users and developers), so they should be done only if they really bring strong value.

[jnothman]

Okay. We should document the eternal blame :p

…

On 25 Oct 2017 10:46 pm, "Gael Varoquaux" ***@***.***> wrote: I am -1 on this. We'll never get the namings wrong, and I don't think that it really helps our users to change names for purity reasons. As mentioned above, there is probably not big ambiguity. I'll plead guilty to this error, by the way. I am willing to take blame for it forever if it may help users :). This is a weak -1: I don't think that the project will collapse or that the users will lead a revolution if we change this. It's just that such changes are cost on both sides (users and developers), so they should be done only if they really bring strong value. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9993 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz64k1-0CsswZ0eNWbGLBX7MsqUbAEks5svx-hgaJpZM4QEtYX> .

[alexlenail]

Before we finalize this decision, I'd like to explain why I made the issue just a little more:

• When I google "Graph Lasso Python" looking for a python implementation of Graph Lasso (not Graphical Lasso) all I can find has to do with Graphical Lasso because of this naming decision.
• It may be that this misnaming is percolating out from this library, as @amueller suggests is possible.
• I was interested in possible contributing an implementation of graph-lasso to this library, but renaming would be a necessary first step. (Though since there isn't too much interest in adding related, more popular methods (Group Lasso and Sparse Group Lasso #9967) I'm not sure this idea would get off the ground...)

[GaelVaroquaux]

@zfrenchee : I understand the logic, and I think that it has a lot of sense.

I would think that an actual graph lasso would probably be out of the scope of the library, so I guess that the last point is not crucial.

I would also worry about the poor naming (blame me) percolating out of the library. I think that it would be very using to submit a PR mentioning the confusion in the docstrings and the docs.

Given how confusing this is, we could go for introducing a GraphicalLasso object and having a very very very long deprecation time on the GraphLasso. That might be a way of bring benefice to all actors: people using GraphLasso just get a warning that points them to GraphicalLasso, but their code doesn't break (or the old tutorials that they are looking at still work). New people directly jump to GraphicalLasso.

Two action points above: a) docs, b) very soft deprecation. What are people's thoughts on both?

[alexlenail]

@GaelVaroquaux I think your plan is a very good one. For now, adding a new GraphicalLasso object (which does the same as the current GraphLasso object), updating the docs to point to GraphicalLasso first instead of GraphLasso, and putting a message in the docs / docstrings of GraphLasso makes sense to me, as well as maybe throwing a warning when people use GraphLasso saying "this will eventually be deprecated".

My personal belief is that this mistake should be corrected in the long term, but the timeline could be... years, if we wanted. We could revisit the idea of deprecating GraphLasso much later.

What do others think?

[agramfort]

it's low priority for me. But if someone has the bandwidth why not. I however think we have more burning issues.

[amueller]

I'm happy with a long deprecation cycle and docs for now.

[artiemq]

If nobody works on it I'd like to handle this issue.

[jnothman]

I don't think it's being worked on. you are welcome to