Oh, that's not good. The problem seems to be x = asarray(x), which isn't going to work for some of the norms.

The +/-Inf norms aren't going to work for signed integers either, e.g., abs(-128) == -128 for int8.

Some examples

In [17]: x = np.array([-128], dtype=np.int8)

In [18]: norm(x, ord=inf)
Out[18]: -128

In [19]: norm(x, ord=-inf)
Out[19]: -128

In [20]: norm(x, ord=1)
Out[20]: -128

In [21]: norm(x, ord=2)
Out[21]: 0.0

Is it not a bug that np.absolute returns a negative number? Or if that's what people expect then wouldn't they also expect norm to return a negative number?

A related issue #5018 with the appropriate reference to http://xkcd.com/1172/. If numpy wants to break spacebar heating, what if all functions in np.linalg immediately convert their inputs to the most appropriate BLAS types (single or double precision real or complex numbers)?

@argriffing I'm thinking of converting everything to floats or objects for linalg.norm.

It seems like you have to convert to a float before doing any operations on it, if you want it to work as expected.

In the first one, 30 * 30 = 132, 12 * 12 = 144, 91 * 91 = 89 for 8 bit unsigned integers, so linalg.norm returns the square root of 365. For the second, the dtype is still uint8 up to the square root. 365 = 109 mod 256, and you get the square root of that instead.

I think the 2nd example isn't actually a bug, but the behavior is very unintuitive if you don't see what's going on. Although the 1st example (the linalg.norm) call makes sense once you think about it, I'd prefer the float casting solution, having the expected behavior of the standard library match expectations is worth the possible slowdowns.

@argriffing I'm thinking of converting everything to floats or objects for linalg.norm.

Great! (I assume you would also allow complex numbers)

Converting to floats sounds good. That should help the L⁰ case, as well.

In [1]: import numpy 

In [2]: import numpy as np

In [3]: np.linalg.norm(np.arange(6), 0)
Out[3]: 5

In [4]: np.linalg.norm(np.arange(6), 1)
Out[4]: 15

In [5]: np.linalg.norm(np.arange(6.0), 1)
Out[5]: 15.0

In [6]: np.linalg.norm(np.arange(6.0), 0)
Out[6]: 5

OK, this change should be made. Still time for 1.11 if someone wants to step up...

Sure, I'll give it a try. Should be straightforward. All we want to do is cast to float if it is not floating point. Should we raise a warning that we did so too? If so, what kind of warning? Should I PR master and then do a backport PR?

I don't think a warning is needed, we should just return floats. I'll add a mention in the release notes when it goes in.

Interesting fact, it states it will return float or ndarray, but there are examples that break this constraint.

Interesting. IIRC, the current behavior is actually a regression.

I added a PR ( #7088 ) for the simple fix to see if that goes ok. Then we probably should go back and clean up the examples. For now, I have allowed other types of floats that are not 64-bit. This way we aren't forcing people to cast up or down. However, if it isn't a kind of float we are always casting to 64-bit floats.

It should be pointed out that the OP has also demonstrated that np.dot is broken too.

@jakirkham How so? There are no overflow guarantees for dot...

Oh ok, if there are no guarantees, I guess it is fine.