numpy Deprecation warning

[benabel]

uncertainties.unumpy.array throws DeprecationWarnings from both numpy 1.16.5 in python 2 and numpy 1.17.4 in python 3:

PendingDeprecationWarning: the matrix subclass is not the recommended way to represent matrices or deal with linear algebra (see https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html). Please adjust your code to use regular ndarray.
mat = unumpy.matrix(arr)

[jonasstein]

please add the exact version information for numpy and uncertainties to your initial ticket (edit).

[lebigot]

Thanks for reporting this.

Handling this requires some care: users expect unumpy.matrix objects to behave like NumPy matrices.

I'm thinking that uncertainties should deprecate unumpy.matrix in the same way as NumPy is doing.

Another thing that should be done is to see how to replace the .I matrix inversion currently handled by uncertainties.

[benabel]

So we could deprecate unumpy.matrix with warnings.

I think inversion can bé done with numpy linalg module https://numpy.org/devdocs/reference/generated/numpy.linalg.inv.html#numpy.linalg.inv

[lebigot]

Yes, indeed.

uncertainties does provide the more powerful pinv() already.

[AdityaSavara]

Hello, I found the same warning. My context is different. I have been using umatrices for a dot product. I have not found any linalg function or unumpy function to do a dot product with the uarray objects. Is there a built in function to do dot products with the uarray objects? If not, maybe a volunteer should offer to help build this in for when umatrix becomes deprecated.

This is beyond my python knowledge, but it looks like it may not be too hard for a volunteer that knows how to do it. We see that the uncertainties core has this in the matrix class:

def __rmul__(self, other):
    # ! NumPy's matrix __rmul__ uses an apparently restrictive
    # dot() function that cannot handle the multiplication of a
    # scalar and of a matrix containing objects (when the
    # arguments are given in this order).  We go around this
    # limitation:
    if numeric.isscalar(other):
        return numeric.dot(self, other)
    else:
        return numeric.dot(other, self)  # The order is important

Since it is relying upon numeric.dot from the numpy core, it seems like somebody who knows how could create unumpy.dot (or unumpy.uarray.dot) to mimic the numpy function https://docs.scipy.org/doc/numpy/reference/generated/numpy.dot.html

[lebigot]

Have you tried using numpy.dot() or the @ operator as usual? There is no "uarray" class: the uarray() factory returns a regular NumPy array, which should behave as expected (in many contexts).

[AdityaSavara]

I'm sorry for my delay in responding, I needed to wait until I got home from work due to which computer the code is on. I had tried syntax like "unumpy.dot()" since I did not realize we could use the numpy functions directly. You are right (of course you are!) that using the @ operator with uarrays does work.

It might be good to provide an @ operator example in the documentation (or to mention it). Also to provide some example explaining that 'arbitrary' directly numpy functions are likely to work with uarrays. I looked again and didn't easily find examples of that in the documentation, I see mostly examples using unumpy functions. I feel guilty suggesting more work for you, but it would be helpful for some users to see such examples.

[lebigot]

That's a fair point, about giving more examples of arrays with numbers with uncertainties behaving as expected with the standard NumPy functions.

The documentation states early that "basic operations on arrays that contain numbers with uncertainties can be performed without [the unumpy package]", but this is only in passing, so it's a good idea to illustrate this point.

To do:

• Emphasize and illustrate the fact that arrays with numbers with uncertainty can typically behave like arrays with floats.

[AdityaSavara]

@lebigot I was getting a warning from numpy during pytest that the numpy matrix class is going to become deprecated because as of python 3.5 the numpy arrays can do all of the same things as the matrix class.

anaconda3\envs\uncertainties\lib\site-packages\numpy\matrixlib\defmatrix.py:69: PendingDeprecationWarning: the matrix subclass is not the recommended way to represent matrices or deal with linear algebra (see https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html). Please adjust your code to use regular ndarray.
return matrix(data, dtype=dtype, copy=False)

The numpy warning says to look at this link: https://numpy.org/doc/stable/user/numpy-for-matlab-users.html which says to always use arrays and that matrix will become deprecated.

Well, I suppose the warning is not the only reason to fix this... since matrix will eventually become deprecated. Based on my history with numpy... I'd speculate that will happen in the next 1-2 years

This may also be related to: #120

[Baharis]

This PR has been stale for some time, but I can't find an answer and I need help with the same issue. I try to invert an array with uncertainties m, but I can not find a reliable way to do it, i.e. the one that won't break my package soon. For the time being, I have used/tested the following approaches:

• unumpy.matrix(m).I is what I used until now, but it warns PendingDeprecationWarning: the matrix subclass is not the recommended way to represent matrices or deal with linear algebra (see https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html). Please adjust your code to use regular ndarray.
• unumpy.ulinalg.pinv(m) raises the same warning, just from the level of the package (.../python3.10/site-packages/numpy/matrixlib/defmatrix.py:69)
• numpy.linalg.pinv(m) or m ** -1 do not work altogether, raises numpy.core._exceptions._UFuncInputCastingError: Cannot cast ufunc 'inv' input from dtype('O') to dtype('float64') with casting rule 'same_kind'.

All of this being said, what is the correct and deprecation-safe way to invert the array? @lebigot suggested 5 years ago:

uncertainties does provide the more powerful pinv() already.

But if this refers to unumpy.ulinalg.pinv, this has the same problem as mentioned above. Is there anything else? Or is there no correct way, and the array inversion might stop anytime soon?

I am using python 3.10, numpy 1.23.4, and uncertainties 3.1.7.