somehow this is misleading. naturally I would think, *, is multiplying, and expect it to return an element by element multiplication result, IF two vec2 are compared. The current behaviour is ok when passing only a number as the multiplier.

I didn’t implement an element-wise multiplication because I felt it was a bit ambiguous. Many programming libraries overload vector * to mean cross product or sometimes even dot product.

I tried to be a bit conservative with the meaning of operators as they relate to vectors in Codea. I felt that unary negation, element-wise addition and subtraction, and scalar multiplication and division were appropriate as they were the common uses.

thank you for your point of view. but it would be helpful to have at least something like vec2:multiply(vec2). its anyway shorter than manually implemented solutions.
just my opinion. sorry for any inconvenience

thank you for the wisdom @Andrew_Stacey and thanks to all for the active discussion! vec:multiply would be enough @Simeon. Thanks for all the ideas and code and open ears for my issue)

Only if it doesn’t slow down the more usual use of *. I guess the dispatch to check type might steal some cycles? Better use Staceys addition if needed. Add bit operators instead

But you’d want different conversions depending on whether you were doing points or normals. For points, you’d want to promote a vec3 with 1 in the last place, for normals then 0. So m * vec4(v,1) allows you to specify the promotion explicitly without over complicating matters.