Proposal: Add a todense method to matrixes.

The method would be an identity map for numpy matrixes.

It is needed to match the interface offered by scipy. The particular situation which tripped me up was the following:

>>> # Preamble
>>> import scipy.sparse as S
>>> diagonals = [[1, 2, 3, 4], [1, 2, 3], [1, 2]]
>>> tmp = S.diags(diagonals, [0, -1, 2])

>>> tmp_lil = tmp.tolil()
>>> tmp_lil_0 = tmp_lil[0,:]
>>> tmp_lil_0[ tmp_lil_0.nonzero() ] # calling .todense() is necessary

    <1x2 sparse matrix of type '<type 'numpy.float64'>'
            with 2 stored elements in LInked List format>


>>> tmp_csc = tmp.tocsc()
>>> tmp_csc_0 = tmp_csc[0,:]
>>> tmp_csc_0[ tmp_csc_0.nonzero() ] # calling .todense() raises an exception

 matrix([[ 1.,  1.]])

I find the case to add the method compelling and do not see any obvious downsides. If it is acceptable to add it, then should it return the same object or should it return a copy?

With this information, I should be able to work on a pull request (#6066)

[WarrenWeckesser]

Thanks @musically-ut, but I don’t think this enhancement request is going to be implemented.

… but I guess by the same token probably no-one cares enough about np.matrix to argue against this either 😃.

Well, it is 6 years later; I’ll argue against it! Knowing that np.matrix is destined for deprecation, it doesn’t make sense to incur the maintenance burden (answer design questions, add unit tests and run them with every PR, update documentation, etc) just to have it all go away when matrix is finally deprecated.

Given the lack of activity in this issue for the last 6 years, I think we can close this now.

[musically-ut]

Actually, the fix to scipy is going to break backwards compatibility.

Hence, I am reopening this issue to see if it is worth resolving the issue at the numpy level by adding some functionality and preserving backwards compatibility.