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.

[SimonDanisch]

I'd also like to have it in base for the reasons already mentioned.
I think there is no doubt about it being a widely used operation.
When I implemented FixedSizeArrays, it felt fairly odd to have so many functions defined on arrays in Base, but not normalize.
Its pretty much the only function I export in FixedSizeArrays, besides some constructors.
When solving #11610 we can inherit from AbstractArray for FixedSizeArrays, which would make it even weirder to sneak in normalize over some other package.
I wouldn't count the argument, that its really easy to implement.
There are lots of easy to implement functions in Base, but they're still in there as they're considered to be widely used.

[PaulBellette]

+1 I use it all the time

[josephnunn]

Although it may not seem like a big deal to everyone, for people working in certain areas like graphics or machine learning not having a normalize function in base is quite frankly ridiculous given all the linear algebra functionality already available. In these problem areas normalize's usage is as prevalent as the veritable List class is in other programming tasks. And for those languages that don't have List functionality, you'll always find a buggy or unoptimized homespun class hanging around the code base causing problems.

As to the general size of base, Common Lisp showed that any sufficiently developed language will in the end absorb a large number of functions into the basic language, its unavoidable and in my opinion preferable to having a large number of ill conceived or maintained libraries that must nearly always be included or resolving independent homespun implementations whenever a dev team grows past size 1.

Ultimately its the quality of functions in base, rather than its size, that Julia should be judged on. And well-written, standardized normalize functions should be a part of the linear algebra base.

Joseph

[johnmyleswhite]

@josephnunn: I would suggest avoiding words like "ridiculous" when making arguments. It's seldom an effective rhetorical trope.

[Keno]

Unless there is an obvious package to put it in (and I don't think there is given that it is applicable to several domains), putting in in base seems fine.

[rofinn]

@josephnunn I think a pretty good middle ground to address your concerns would be to place common functions like normalize into a stdlib or base math or stats pkg. This would address your concerns of having multiple "buggy or unoptimized" implementations kicking around while not adding further bloat to base. From what I understand this would also fit with the community's desire to break base out into a stdlib(s).

[josephnunn]

@johnmyleswhite Perhaps you are right on my choice of words, but as I mentioned for those used to working in certain problem areas incredulity will be the reaction, as it was for myself.

[c42f]

Great, thanks Jiahao. I started implementing this, but got hung up on the details. As your pull request shows, there are several, surprisingly.