On Sat, Oct 19, 2024 at 2:18 PM Dan Schult <dsch...@colgate.edu> wrote:
> This is quite helpful. Thanks! > > Github search: > I'm not surprised that many github hits are like homework problems. The > big resistance to removing np.matrix early on (~2008) came from educators > who wanted a Matrix oriented experience for their students who had recent > linear algebra background. It was heavily used for at least a decade in the > education setting. That started to wane when Python created the `@` > operator. But change is slow. It's been 10 years with `@`. > > I very much support Ralf's concerns that this not push SciPy. It would be > pushing me after-all. But it is hard to know how to proceed with the > transfer from spmatrix to sparray without also knowing something about the > support for np.matrix from the numpy devs. But... there's no reason removal > of spmatrix needs to happen first. It may be quite natural for both to be > moved to a single separated package. Or they could be removed at the same > time. We'll have to see what makes sense. > > Thanks Nathan for the preview of github usage and perspective from the 2.0 > release. I'm also pleased to find that github search results for PRs can be > sorted by date. While there are 28K PRs involving np.matrix, the recent PRs > are almost all dependabot reminding folks to upgrade their dependencies. Of > the top 30, 3 were actions to **remove** np.matrix in favor of ndarray. 1 > was `scipy.interpolate` (which also mentioned removing support for > `np.matrix`, though provided a workaround instead). And the remaining 26 > are dependency updates. That takes us back to Aug 30. Jumping to the most > recent 80 PRs gave the same type of results, but I didn't bother counting. > Almost all of them are dependency updates. Most of the rest are moving away > from np.matrix. It is clear that recent activity (as measured by PRs) does > not show much activity using np.matrix. > > Perhaps most importantly, there don't seem to be any courses being run > this semester that have students creating PRs using np.matrix. > > And thanks Marten, Sebastian and Chuck for the nudge to find a way to move > forward with the deprecation process. I think the change to > `VisibleDeprecationWarning` is a good next step. Hopefully we don't have to > wait another 7 years for the following step unless we decide that keeping > that code in numpy is the best way to go. No one seems to have argued for > just leaving np.matrix in the package forever, but I think it is a > reasonable approach (similar to stating that RandomState will remain > forever). But given the decline in usage, and the negative impacts of > having multiple interfaces to array-like objects, it is probably better to > stop supporting matrix at some point. > > Summary: > It seems like eventually removing np.matrix is desirable. The choice of > removing versus separating depends somewhat on how easy that is for both > devs, and for users. It might be worth a short exploration to see if there > is a solution. We should time this so it doesn't negatively impact the > transition SciPy sparse is making. They are the main users, and leaving > np.matrix as it is costs very little. > > Action items from this discussion include: > - Exploring impact on SciPy of a change to `VisibleDreprecationWarning`, > possibly followed by a PR to make the change. > When something gets deprecated in NumPy, as a rule we remove it in SciPy immediately. We could _maybe_ postpone full removal for a bit, but I don't really see a way to keep sparse matrices around if `np.matrix` gets a visible deprecation warning. The most conservative open source project which depends on sparse matrices is probably scikit-learn, so I'd suggest getting an answer from the scikit-learn team about what the minimum timeline is that they can live with for first deprecation and then removal of sparse matrices. Cheers, Ralf > - Investigating a light-weight, simple separation package that wouldn't > affect user experience much. If that's hard, then we have identified the > pain points. If that's easy then it informs the choice of a path forward > for both matrix and spmatrix. > - Collect info about the current usage of np.matrix, and what type of > usage the large existing codebase needs. Put that info into a NEP, along > with a summary of the history and current discussion, and a description of > our exploration into possible light-weight routes to separation. > > I don't expect this to be soon -- maybe by next summer -- unless other > people get involved. I'm interested in further discussion and suggestions > too. > > FYI Chuck: It looks like Event Horizon Telescope doesn't use np.matrix at > all any more. > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: ralf.gomm...@gmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
