Ask for suggestions for a function name

I’m planning to add a new function in the G’MIC math evaluator that takes a vector-valued argument v and returns its normalized version \frac{v}{\|v\|}.
How would you name such a function ?
I don’t want to use normalize as it is already the name of a G’MIC command that does something else (linear normalization of an image).
For an idea, I’ve asked ChatGPT and it suggested to use the name unitize.

So that would be something as:

X = unitize([1,2,3]);

Do you agree with this suggestion? Or do you have another name to propose?
It doesn’t really have to be a verb, as it doesn’t act “in-place”, but returns a new unit vector.
Maybe

X = unit([1,2,3]);

would be better?

What do you think?

vn should be the name. Short for vector normalize.

For the moment, I’m leaning towards the name unitnorm() which is short enough and yet very clear.

2 Likes

Or unite?

+ unitnorm

Edit:
Because:

  1. norm brings to my mind the notion of mapping lengths to vectors; in the interest of terseness, I need not explicitly write vector — such is implied.
  2. unit conveys to me that special length mapping to unity, so the useful outcome of the operation is the orientation of the vector within the space that it is embedded.

(2.) left me dancing with the idea of orient(), a riff on the pipeline command pair norm, which conveys pixel vector ‘length’, and orientation, which conveys their spatial positioning. Mathematical Expressions already has norm() (aka: norm2()); orient() would complete (and echo) the pipeline counterparts. That may be too poetical; unitnorm() is the more practical name, methinks.

1 Like

maybe too cryptic… vectnorm better?

1 Like

I thought about vnorm this morning.
I’m not a math person but to me, unitnorm doesn’t seem to speak about vectors…

1 Like

orient() is my suggestion because it matches the name of my command. unit(), unitize() and unitnorm() can be confusing. I would rather call it unitvector().

1 Like

Many thanks for your feedbacks!

After thinking about it for a moment, what I have in mind right now is to actually make the name coherent with the current family of normP() functions, so that would mean adding an entire family of unitnormP() functions that works equivalently:

  • Y = unitnorm2(X) and Y = unitnorm(X) , both equivalent. One can also use Y = unitnorm(x0,x1,...,xN) , just as it is possible to do it with norm().
  • And variations : unitnorm0(), unitnorm1(), unitnorminf() for the L-0, L-1 and L-inf norms.

Also looking at all this made me realize that there was no version of normP() that can takes a parameter P that is not a constant value. So I’ll also add normp(p,X) and unitnormp(p,X) to allow calling these functions with variable parameters p.

2 Likes

Thinking about it once more, maybe the approach of simplifying the normP() family instead could be better, so :

  • norm(X,p) returns the L-p norm of vector X (does not allow anymore a variable list of arguments to specify the vector elements).
  • unitnorm(X,p) return the unit vector that is X normalized by its L-p norm.

Looks simpler, no?

With those two functions, norminf(X) becomes norm(X,inf), etc.

Pros: Two functions to rule them all.
Issue: Will break compatibility with 3.2.3 version…

Thoughts?

Maybe create some kind of alias so that it retains compatibility with 3.2.3 until old scripts are updated, and then switch over to the new names? Something like that.

Actually, compatibility could be enforced easily by using norm([a,b,c,d]) rather than norm(a,b,c,d) in the rare places where it occurs.

I’ve finally decide to keep versions of normP() where P is a constant.
To keep a perfect compatibility you just have then to use norm2() instead of norm() in your source code and it will be OK (already made the changes in gmic-community).

1 Like

Although I prefer the simpler two functions to rule them all, I like the consistency of the new naming scheme.

OK, so things have changed again.
While doing the modifications in the various .gmic files, I realized that norm(a,b,c,...) was actually used a lot, and was quite a readable expression.
On the contrary, computing the L-p norm of a vector (with a variable p), was not a so common need.
And I don’t want to break anything, just for that.

So, my final decision about norm() is:

  • Things will not change compared to version 3.2.3 : norm(1,2,3), norm([1,2,3]), norm2(1,2,3), norm1(1,2,3) will be valid and do the same as in 3.2.3.
  • New function normp(V,p) is introduced when we really need to compute a L-p norm of a vector with a variable p.

Sorry for the noise.

1 Like

I’ve updated the pre-release binaries with the new changes, at : Index of /files/prerelease

=\hat{v}

That’s my suggestion: vhat()

1 Like

Is normp() compatible with const non-int p?

Example:
https://www.researchgate.net/profile/Habtamu-Alemu-2/publication/330121320/figure/fig1/AS:711151683907584@1546563182168/Illustrations-of-Lp-norm-for-p-1-2-and-1-2.png

Yes, normp(V,1.5) works (as well as norm1.5(V)! ).

1 Like