Frobenius Norm defined for vectors?

[TNonet]

This might be less of an implementation question, and more of a "philosophy" question, but shouldn't the Frobenius Norm work on Vectors? Source: Wolfram

Currently, the Frobenius Norm in numpy does not accept vectors:

import numpy as np
a = np.random.rand(10, 1)
b = np.squeeze(a)
print(np.linalg.norm(a, 'fro'))
print(np.linalg.norm(b, 'fro'))

Which results in:

1.7594677278427366
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
//anaconda3/lib/python3.7/site-packages/numpy/linalg/linalg.py in norm(x, ord, axis, keepdims)
   2515             try:
-> 2516                 ord + 1
   2517             except TypeError:

TypeError: can only concatenate str (not "int") to str

During handling of the above exception, another exception occurred:

ValueError                                Traceback (most recent call last)
<ipython-input-18-2ace847024a5> in <module>
      3 b = np.squeeze(a)
      4 print(np.linalg.norm(a, 'fro'))
----> 5 print(np.linalg.norm(b, 'fro'))

<__array_function__ internals> in norm(*args, **kwargs)

//anaconda3/lib/python3.7/site-packages/numpy/linalg/linalg.py in norm(x, ord, axis, keepdims)
   2516                 ord + 1
   2517             except TypeError:
-> 2518                 raise ValueError("Invalid norm order for vectors.")
   2519             absx = abs(x)
   2520             absx **= ord

ValueError: Invalid norm order for vectors.

[rossbar]

This looks like a bug in the handling of the 'fro' kwarg:

>>> print(np.linalg.norm(b))
1.7547099704258247

Note that the Frobenius norm is the default when the ord kwarg is None.

[seberg]

xref gh-14719 and gh-14215: We thought about deprecating the general case, but then never went ahead because while there was not a huge resistance, there was some. And some other packages define it as that. So the issue is to decide where exactly to go here...

[seberg]

As Ross pointed out to me, the issue/PR I linked are only tangentially related and this is quite clearly a bug in the "fro" handling.

[rossbar]

A PR to address the bug in the kwarg handling (and accompanying tests) is welcome! Nice catch @TNonet

[TNonet]

Since this is my first issue, Are there any resources for making proper tests and a pull request?

(Also, if I was to clone the numpy repo and run setup.py, how would I make sure which numpy version I use when I import numpy?)

I would argue if ord is 'fro', then lines 2512-14 below.

numpy/numpy/linalg/linalg.py

Lines 2510 to 2524 in dae4f67

	if axis is None:
	ndim = x.ndim
	if ((ord is None) or
	(ord in ('f', 'fro') and ndim == 2) or
	(ord == 2 and ndim == 1)):
	x = x.ravel(order='K')
	if isComplexType(x.dtype.type):
	sqnorm = dot(x.real, x.real) + dot(x.imag, x.imag)
	else:
	sqnorm = dot(x, x)
	ret = sqrt(sqnorm)
	if keepdims:
	ret = ret.reshape(ndim*[1])
	return ret

Would need to be changed to:

if ((ord is None) or 
    (ord in ('f', 'fro')) or 
    (ord == 2 and ndim == 1)): 

Assuming everyone agrees that an nth order array has a Forbenious Norm that is naturally summing up squares of each element.

[rossbar]

The problem is actually a bit further down in the code - if you follow the traceback from the error you received originally, you should be able to find the offending bit.

As mentioned in the discussions in #14719 and #14215, the behavior for >2 dimensions is a separate issue - it would be best if you could limit this PR to the bug in kwarg handling.

Re: resources for testing/contributing: take a look at NumPy's contribution guidelines. You can also take a look at linalg tests in numpy/linalg/tests/test_linalg.py to get an idea of how tests are formulated and where additional tests might be appropriate. Hope that helps!