Functions for normalizing vectors

[c42f]

I find myself commonly writing the trivial utility function normalize(x) = x/norm(x) for geometric computing. Julia has the useful utility cross() in linalg - maybe normalize() and normalize!() belong there too? I see that ImmutableArrays.jl has defined unit() for this though that name clashes with a different use in SIUnits.

For greater than 1D arrays, normalize(x, dim) acting along a dimension would be a useful generalization for me personally. A p-norm version might also be useful.

@SimonDanisch - this is very relevant to 3D graphics - maybe you have some thoughts?

[andreasnoack]

I agree that it is a useful function, but it is also very easy to define in a program, so I think I prefer not to include it. I'm aware that we might be deviating from this principle for other functions in linalg.

[tknopp]

+1 for adding this to base. The actual implementation should however not look like normalize(x) = x/norm(x) but avoid the extra temporary.

[c42f]

I was imagining the actual implementation would be normalize(x) = normalize!(copy(x)), with normalize! a suitable zero-allocation version. My usual preferred name for the non-inplace version is normalized(), but I thought normalize() and normalize!() might be more idiomatic?

Out of curiosity, how is an extra temporary involved in x/norm(x)? If you don't want normalization to be in place you're bound to have at least one copy.

@andreasnoack - understood, though I'd argue that normalizing a vector is pretty fundamental to all sorts of numerical linear algebra. In addition, a maximally efficient version of the generalized version normalize(x, dim) is not trivial to implement. (I'd guess that ordering based on memory layout and simd instruction usage would be relevant. That's not something your average user is going to bother with, but it could eventually make sense to include.)

[tknopp]

Ah sorry you are right. In this case its just the one necessary copy being made.

[carnaval]

For the 3D case I don't think anybody would use julia arrays for a single vec3 (or projective vec4). It might come up however to have to project on the sphere a whole bunch of them represented as a big array (say if you want to avoid renormalizing normals on the GPU, even though it's pretty cheap these days) but in general the small vectors in the array will have stride + offset.

[timholy]

normalize(x, dim) is just x./sqrt(sumabs2(x, dim)), and it already uses a cache-efficient simdable algorithm. Overall I'm 👎 on including this in base, in no small measure because deciding the proper behavior for when x has zero norm could be the subject of a long-running discussion (wasting much more time than if people just implement whatever behavior they want for themselves).

[tknopp]

Why would this lead to long discussions? Either throw an exception (like we do for sqrt(-1)) or in the lazy implementation simple do nothing. I think we have more exotic functions in base than normalize.

[c42f]

@carnaval - I commonly use julia arrays for a single vec3 - they are a reasonable tool when you want the shortest/simplest code possible and efficiency isn't a concern.

[johnmyleswhite]

Agree with @timholy: there's no reason this needs to be in Base.

[nalimilan]

One reason is convenience: you can use that function without having to define it somewhere first. The other is consistency: if each project ends up implementing a slightly different version, you'll never know how it exactly behaves, e.g. when the norm is zero.

After all, we already have scale.

[c42f]

Tim - that's great, I didn't know about sumabs2.

[ScottPJones]

@nalimilan So maybe a bunch of these "convenience" functions belong in a registered package, that would solve both your convenience and consistency issues, IMO, and not keep adding more and more to base.

[tknopp]

I am a big fan of having a shrinked base. But this does not mean that new functions are disallowed. Linear algebra lives in base and one should try to group function together that belong to a functionality.
But I am not so much arguing for this specific function (normalize) but more so about @nalimilan comment. If a function is repeated a lot in user code with slightly different versions its time to
a) have a package
b) put it in base
If its not a single function its good to have a functional group and do a) But if all the other functions are already in base it should also be valid to do b).

(The function squeeze is by the way a similar candidate that I would assume is repeated by various people and despite its issues could live in base simple because it is used by several people)

[dhoegh]

I have also used and defined it in some projects, +1 for having it in base.