PVector feature request

willemkempers

See this thread: https://forum.processing.org/two/discussion/18585/multiplying-vectors#latest

Would be great to have 'PVector.convolute()' implemented, as @jeremydouglass suggested.

Basically, a function that multiplies the individual fields of two PVectors (x1 * x2, y1 * y2, z1 * z2) and returns a new PVector.

Thanks!

GoToLoop

Dunno... but convolute() seems like a horrible name to me. :-&
Besides I wouldn't be able to guess what it does by its name! @-)
Best thing would be to return the overloaded mult() to where it was when version 1.5.1 reigned! :)>-
And let's not forget about div() too! L-)

quark

I agree with GoToLoop regarding the method name. convolute does not represent want the method is supposed to do, mult and div are much better in that respect.

jeremydouglass

While I'm not a big fan of "convolute" either, I was just trying to point out in that thread that "anything but mult()" is an expected reaction to such a feature request for a reason. See numerous examples from other languages of not allowing mult of two vecs because many would incorrectly assume that means .cross().

If proposing .mult() works, great. If not, the request might get further suggesting something other than mult. Like overloading .scale(), for example?Just trying to read the tea leaves.

quark

Like overloading .scale()

It makes sense we are scaling the vector with another vector - I like it. =D>

GoToLoop

... because many would incorrectly assume that means cross().

Well, I doubt it'd be that many... Perhaps some math scholars which haven't yet found out that * is multiplication for computing languages? :))

Also PVector already got method cross()! L-)
Notice however that both add() & sub() already accepts another PVector too.
IMO, it's only natural both mult() & div() got the same treatment! B-)

Yea, I understand convolute() (or something else) would be an alternative request if overloading mult() is re-denied. But let's all hope that "ugly" word won't be necessary. [-O<

jeremydouglass

Perhaps some math scholars which doesn't yet found out that * is multiplication for computing languages?

This isn't really a math vs CS thing. Try looking at the top 100 hits for Googling "multiply two vectors". The tutorials, the videos, the images. They all have one thing in common-- they refer to the dot and cross product, not to component multiplication. It isn't about humoring math scholars, it is about not confusing someone who wants to "multiply two vectors" and means what almost anyone else on earth means when they say that in any other other field, discipline, or context.

GoToLoop

The proposal is about getting back the overloaded functionality for mult() & div().
When trying to use them, the overloaded options gonna show up in auto-complete.
But I think folks can look up their reference entries if in doubt.

And again, consider that both cross() & dot() already exists.
B/c of that, jumping to the conclusion that the overloaded mult() & div() would be cross() or dot() is less likely than rationalizing instead they're equivalent to add() & sub() corresponding overloaded methods. :-B

jeremydouglass

If the question is "could a person who knows what mult() did back in v1.5.1 be confused?" then of course no.

If the question is "could a person who has already looked it up and knows that .cross() is a separate method be confused by .mult(PVector)" then... maybe not? But then, of course they know what it does because they already looked all the class methods up.

But if the question is "could a person who sees code that says vecA.mult(vecB) be confused ... well, probably! As I said, Google "multiply vectors" or look at other programming communities such as Unity.

Or, to quote Humpty Dumpty:

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that's all.”

GoToLoop

But if the question is "could a person who sees code that says vecA.mult(vecB); be confused..."

Would they be confused w/ vecA.add(vecB); too? :-/

When I started on Processing, I hadn't seen any discrepancies between vecA.add(vecB); & vecA.mult(vecB);; nor any between vecA.sub(vecB); & vecA.div(vecB);. >-)

It only seemed natural for moi they all had similar overloaded functionalities. :bz

Only now I've heard about that multiplication among individual vector properties would be some kinda heresy and spread confusion!? @-)

quark

If you think about it then the methods

vecA.add(vecB) and vecA.sub(vecB) are effectively translating vecA

and the methods

vecA.add(vecB) and vecA.sub(vecB) are effectively scaling vecA

(assuming we treat x, y and z attributes as treated individually same as add and sub)

which is why I like overloading the scale() method.

The problem I have with the word convolute is that bears no relationship to what the method is doing.

kfrajer

Vector multiplication is not the same as dot or cross product. For instance, the dot products of two vectors produce a scalar. The cross product of two vectors produce another vector, which is perpendicular to the plane made by the first two vectors. Multiplying two vectors... this is just a lazy way to do a proper transformation. In a proper transformation of a higher space - less say 3D space for example - you need a 3x3 matrix. A vector with proper dimensions multiply by this transformation matrix would produce another vector with the characteristics implied in this post. Just to add, the add and subtraction functions for vectors make sense when working with vectors (as with matrices) only when they have the same dimensions.

A proper way to do proper multiplication (the right way) is to use linear algebra software as for example: MATLAB, Mathematic, IDL, R.

Kf

kfrajer

Scaling a vector it is simply multiplying a vector by a scalar. Trying to override this definition of scale is not appropriate. It is an ill concept, similar to calling the multiplication of two vectors as convolution.

Kf

jeremydouglass

@kfrajer re: "Vector multiplication is not the same as dot or cross product."

As with Humpty Dumpty, just saying that doesn't make it so. My point is that this is a question of public discourse. For example, maybe you should start out by editing the [Multiplication of vectors Wikipedia page], which disagrees:

In mathematics, Vector multiplication refers to one of several techniques for the multiplication of two (or more) vectors with themselves. It may concern any of the following articles:

• Dot product
• Cross product

quark

Scaling does NOT have to be the same for x, y and z?

Multiplying a vector v by another vector s so that

v.x = v.x * s.x
v.y = v.y * s.y
v.z = v.z * s.z

then if s.x == s.y == s.z then you are effectively 'multiplying a vector by a scalar' but if they differ it is still scaling but is non-uniform.

Processing already has the scale() method which allows non uniform scaling when drawing so overloading the scale method of PVector makes perfect sense to me because it is descriptive of what the method does.

GoToLoop

In mathematics, Vector multiplication ...

That's it, in mathematics. Programming, although similar, is not equivalent to math!
For the point-of-view of the user trying to familiarize w/ PVector's API, makes more sense for all the 4 basic operations have the same functionality.

Processing already has the scale().

For drawing stuff w/ different sizes, even flipped or mirrored.
There's no method called scale() in the PVector class yet.

It's not that bad to create another name to do that functionality.
But I think it's more natural API-wise for both mult() & div() to mirror add() & sub(), like it was before!

quark

I think the most appropriate option is a choice between

1) reintroduce mult and div back to the PVector class
2) introduce a scale method

Take your pick, there are pros and cons for both.

I must admit I like the idea of a scale function because
a) the most common use of PVector is with 3D graphics so it ties in with the existing use of scale
b) the scale could be used to mirror or flip a vector in the same way the existing scale version works for graphics.

but GoToLoop's reasons for reintroducing the mult and div are equally valid and perhaps more generic than a scale method.

I would be happy with either :)

willemkempers

As someone whose first introduction to programming was via Processing and now uses it on a daily basis, I like GoToLoop's suggestion better. It seems a lot more clear to me what's going on. I can imagine that the current state where add and sub allow for pvectors but mult and div don't actually creates more confusion than it takes away (especially true for beginners).

Quark's scale makes a lot of sense, as the current scale() does exactly the same, but I like adding to the existing mult() and div() functions better than reintroducing a new method.

To be honest I don't mind either - as long as it becomes possible to do x * x, y * y, z * z.

jeremydouglass

@GoToLoop, I do take your point about having to add scale -- and about parallelism between add/sub/multi/div being elegant and intuitive from the point of view of someone learning the API. That is true, and a good argument for internal consistency.

To all -- since a number of us would all be okay with either approach, perhaps we submit this feature request to GitHub issues proposing that either .mult() first or .scale() second choice be used to implement this feature, and see what happens?

GoToLoop

Yea! Go ahead! :-bd

quark

Go for the mult() as it simply brings back a method they removed.

willemkempers

Yes go for it!