You also need to check for underflow, e.g. [1e-200, 1e-200] should not have a norm of 0.0. Something like

thanks — you're right, it was only handling overflow. Pushed a fix so it rescales on underflow too.
One small thing on the suggested condition: not math.isfinite(ret) and ret != 0 doesn't actually catch the underflow case, since [1e-200, 1e-200] gives ret == 0 (which is finite) — so I went with not math.isfinite(ret) or ret == 0. Kept your max_abs guard so inf/nan still propagate and an all-zero vector stays 0. norm([1e-200, 1e-200]) now returns √2·1e-200 instead of 0, and I added float64/float32/complex underflow cases to the test.

Sorry, I meant not math.isfinite(float(ret)) or ret == 0

Yep, that's what's in the current version — not math.isfinite(float(ret)) or ret == 0. 👍

(Seems like it should be faster to do numpy.vdot(x, x).real, so that it can do a single pass over the complex array?)

Yeah, that's cleaner — switched the complex sum of squares to vdot(x, x).real so it's a single pass, both in the main path and the rescaled one. Thanks!

This will not work. ret does not have to be a scalar. You need to check if ANY of the elements are such that the scaling fallback is needed, it's not 1 element. I do not have permissions to run the CI but please test locally. You can do so with spin test or spin test numpy/linalg to run only the linear algebra testing. I get the following with your branch:

FAILED numpy/linalg/tests/test_linalg.py::TestNorm_NonSystematic::test_overflow - RuntimeWarning: overflow encountered in dot
FAILED numpy/linalg/tests/test_linalg.py::TestNormDouble::test_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_linalg.py::TestNormDouble::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_linalg.py::TestNormSingle::test_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_linalg.py::TestNormSingle::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_linalg.py::TestNormInt64::test_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_linalg.py::TestNormInt64::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/linalg/tests/test_regression.py::TestRegression::test_norm_object_array - TypeError: only 0-dimensional arrays can be converted to Python scalars
FAILED numpy/matrixlib/tests/test_matrix_linalg.py::TestNormDoubleMatrix::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/matrixlib/tests/test_matrix_linalg.py::TestNormSingleMatrix::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity
FAILED numpy/matrixlib/tests/test_matrix_linalg.py::TestNormInt64Matrix::test_matrix_empty - ValueError: zero-size array to reduction operation maximum which has no identity

You're right on all three — thanks for actually running it, and sorry for the churn (I was expecting CI/CD to catch this) .
Fix: I've restricted the rescale to non-empty real/complex float input (x.size and issubclass(x.dtype.type, inexact)). So empty arrays no longer hit abs(x).max() (the ret == 0 trigger I added was firing on them), and object dtype no longer hits float(ret) — that's your "ret isn't necessarily a scalar" point; object and empty now just fall through to the naive result. (In this fast path the input is ravel'd to 1-D and dotted, so the norm itself is a single scalar — the guard just keeps us on that scalar path only where it's valid.)
For the overflow RuntimeWarning, I wrapped the extreme-input assertions in np.errstate(...) in the test rather than putting errstate back in the hot path (keeping your earlier perf point) — the code recovers to the correct value and the warning just matches main's behaviour.
Built locally under 3.12 and ran spin test numpy/linalg: 458 passed, 0 failed, including test_overflow, test_empty, test_matrix_empty, and test_regression.py::test_norm_object_array. Pushed as a4c83d0.

Shouldn't ret always be a scalar in this branch (axis is None)?

Yes — in this axis is None fast path it's a scalar (x is ravel'd to 1-D and dotted). The guard is for the two degenerate cases that also reach here: object dtype (where norm returns a non-0-d result — what tripped float(ret) earlier) and empty input (where abs(x).max() has no identity). x.size and issubclass(..., inexact) just keeps us on the scalar path where it holds.

Whoopsie I did not notice that this was all in an axis=None block. FYI you can provide an initial value to max using the initial= argument if it's helpful in any way.

Used initial=0 in the per-axis version so empty slices avoid a no-identity max.

I would check that it is approximately 1e-200 * np.sqrt(2).

(Since assert_allclose correctly has a default absolute tolerance atol=0, its default rtol=1e-07 will work fine for very small values.)

Oh, you are already checking that above. Then I don't see the purpose of the assertion, which is redundant with the preceding allclose check.

Agreed — removed it; the assert_allclose right above already pins the value.

again, the != 0.0 check seems redundant

Dropped the != 0.0 here too — kept the norm(x32).dtype == np.float32 part, since that checks the float32 dtype survives the rescale (not redundant with the assert_allclose). Happy to drop it entirely if you'd prefer.

Can't you just use vdot unconditionally for both real and complex arrays? For real arrays it is equivalent to dot, no?

Done — confirmed vdot(x, x).real matches x.dot(x) for real dtypes (float16 still overflows to inf as float16, float32 still underflows to 0), so I dropped the branch and use vdot for both the main and rescaled paths.

this is massive, please make it concise

done.

This is also a but big IMO but whatever. If it can be reduced to 1 or 2 lines sure

Reduced to one line.

The inexact check will always be True, no? x is converted to float at the beginning of the function: https://github.com/vismaytiwari/numpy/blob/c02eb25d9831615c29c322e4ece4d45dc9f3081e/numpy/linalg/_linalg.py#L2758-L2759

Otherwise you would have trouble with integer overflow, e.g.

>>> x = np.array([10000000000000, 10000000000000])
>>> np.vdot(x,x)
np.int64(-5075528580230807552)

Integers can't reach it — they're cast to float at the top, which is what avoids that int64 wraparound. The check is for object dtype: it stays un-cast and can return a non-scalar (norm([array([0,1]), 0, 0]) → [0, 1]), where float(ret) would raise — the test_norm_object_array case.

Note that vdot does twice as much arithmetic as the previous code, because it computes the (≈ zero) imaginary part only to discard it. However, since this is a BLAS1 operation I would expect it to be memory bound, so a single pass would still be faster for a sufficiently large array.

Would be good to do a little benchmark, however, to see how the performance compares as a function of x.size.

(Unfortunately, there doesn't seem to be a good primitive in numpy to compute just vdot(x,x).real in a single pass. If x is a contiguous complex array, you could reinterpret as a real array of twice the length and then just take the real dot product with itself, but that will fail if it x is not contiguous, e.g. a strided slice of some other array.)

Benchmarked it (numpy 2.4.6, Accelerate BLAS; contiguous complex128, since the code ravels x first). vdot(x, x).real vs the old x.real.dot(x.real) + x.imag.dot(x.imag):

So vdot is ~2× faster across the board — memory-bound as you expected, the extra imaginary flops don't show. And for real arrays vdot(x, x) == x.dot(x) (ratio ~1.0), so no overhead there.

One thing worth flagging: since we ravel(order='K') first, x is always contiguous at this point, so the reinterpret trick you mentioned does apply here — viewing the contiguous complex array as a length-2N real array and taking a real dot is another ~2–9× faster than vdot (e.g. 1e6: ~22 µs vs 213 µs), since it never computes the discarded imaginary part.

So two options: keep the simpler vdot (already ~2× over the previous code), or use the view-as-real reinterpret for the extra speed (a few more lines, guarded on applicability). Happy to go either way — any preference?

I'm not sure what the maintainers prefer here? Maybe postpone further performance optimization to another PR?