PVector methods versus mathematical operators?

Looking at the PVector reference entry, it states –

“Since vectors represent groupings of values, we cannot simply use traditional addition/multiplication/etc. Instead, we’ll need to do some “vector” math, which is made easy by the methods inside the PVector class.”

But arithmetic operators appear to work fine:

# methods
a = PVector(1, 1)
b = PVector(1, 1)
print(a)  # (2, 2)
print(a.div(2))  # (1, 1)

# arithmetic operators
a = PVector(1, 1)
b = PVector(1, 1)
a += b
print(a)  # (2, 2)
print(a/2)  # (1, 1)

What are the advantages (if any) of using the methods? Is this some Python vs Java Mode thing?


Hi @tablereturn,

I’m not as familiar with the Python implementation of Processing, but if this is the right spot in the source code, then the Python operator definition calls either the static or the instance method.

For advantages vs. disadvantages, if you search for debates about whether languages should allow operator overloading or not, you’ll find a variety of responses. I’m not sure exactly what the documentation is referencing… Maybe to how, for example, the * operator could refer ambiugously to

  • component-wise multiplication betweeen two vectors
  • multiplication between a vector and a scalar
  • the cross product
  • the dot product?

The ambiguity between the first two is not as great in languages where the variable data type is clearer (i.e., PVector#mult(PVector, float) vs. PVector#mult(PVector, PVector)).



Processing flavors many times rely on Processing’s Java Mode reference as base.

Python Mode’s dev subclassed the original Processing’s PVector in order to add overloaded operators:

We can still access the original PVector w/o overloaded operators via __pvector__ though:


Of course languages should allow operator overloading :wink:

Great answer! Thanks, @behreajj

1 Like

This should have been fixed by a PR from me on the documentation, but for some reason it is not ‘live’ at he site :frowning: