[p5.js 2.0 Bug Report]: If you create a p5.Vector without arguments, the 2d vector subtracted by it will be strange.

[inaridarkfox4231]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.0.5

Web browser and version

Chrome

Operating system

Windows

Steps to reproduce this

Steps:

1. Create a vector without arguments.
2. Create a 2D vector and subtract the vector you prepared earlier.
3. The third component will be NaN. Furthermore, If you apply rotate() to it, all components will become NaN.

Snippet:

function setup() {
  createCanvas(400,400);
  const v=createVector(100,0);
  const w=createVector();
  v.sub(w);
  console.log(v.toString());
  v.rotate(1);
  console.log(v.toString());
}

If you explicitly make it two-dimensional with two zeros, there is no problem.

This issue has been occurring since version 2.0.0. It has not occurred in version 1.x.

Specifying a value without arguments is a common practice when creating a default vector, whether in two or three dimensions, so I thought this could be inconvenient in some cases.

[inaridarkfox4231]

Subtracting a zero vector is a rare occurrence, but it does also occur when any vector applies to it by add() (even a 2D vector!), so it's a problem.
For example, when calculating the center of gravity, we adding a large number of 2D vectors to a zero vector, and performing some kind of division. And then subtracting the result from each of the 2D vectors (centering process), this problem will be occur.

function setup() {
  createCanvas(400,400);
  const v=createVector(100,0);
  const w=createVector();
  const other = createVector(1,2);
  w.add(other);

  v.sub(w);
  console.log(v.toString());
  const g = createVector(2,3);
  console.log(v.dot(g));
  console.log(v.mag());
  console.log(v.magSq());
}

Also, dot() and mag() (and other several functions, maybe) fail because the components contain NaN.

[sidwellr]

The crux of the problem here is that version 2 allows vectors to have an arbitrary number of dimensions (version 1 vectors are always three dimensional). This brings up some interesting issues:

First, what should createVector() with no parameters create? The current behavior is to create a three dimensional 0 vector: [0,0,0], which is what version 1 did. Perhaps this is OK for compatibility, but createVector() with one or two parameters is not compatible, creating a one or two dimensional vector, not a three dimensional one, which can cause issues. So should at least one parameter be required for createVector()? Or should zero dimensional vectors be supported? (I'm not sure what that even means.)

Second, what should happen when two vectors with different dimensions are added or subtracted? Mathematically, this is not meaningful. Perhaps this should throw an error. But the current version doesn't. If a vector with m dimensions is added to or subtracted from a vector with n dimensions, the result can be strange. The resulting vector has a dimensions property of n, but if m>n the _values property is a vector of length m (larger than the dimensions), which is inconsistent and not always handled correctly by the code. For example, toString() converts the entire _values array, not just the number specified in dimensions. If subtraction was done, the extra _values values will be NaN, and this causes many vector functions to return NaN even though they shouldn't look at them. This is the issue inaridarkfox4231 describes by subtracting a three dimensional vector (created using createVector with no parameters) from a two dimensional one.

So there is definitely an issue here that needs to be fixed. A vector's dimensions property should always match the length of the _values array, and it doesn't. Exactly what to do to fix it needs some discussion among people who use p5.js more than I do.

[Ahmed-Armaan]

First, what should createVector() with no parameters create? The current behavior is to create a three dimensional 0 vector: [0,0,0], which is what version 1 did.

We can maybe have a default case to create a 3d vector if createVector() is called without any parameters and create vector of given size if a parameter is provided.

Second, what should happen when two vectors with different dimensions are added or subtracted? Mathematically, this is not meaningful.

We can either throw an error or take the smaller dimension of two and reduce the larger vector to that dimension.

If we can arrive at a decision to handle this I can start working on the issue

[sidwellr]

Another possibility for add/subtract (which I prefer) is to not change the dimensions of the base vector. So vec1.add(vec2) would not change the number of dimensions of vec1. If vec2 has more dimensions, the extras are ignored; if it has fewer, the missing ones are treated as 0.

[inaridarkfox4231]

Here's the calculation result based on the current specifications:

function setup() {
	createCanvas(windowWidth, windowHeight);
	const v0=createVector(1,1);
	const v1=createVector(2,2,2);
	const v2=createVector(3,3,3);
	console.log(v0.copy().add(v1).toString());
	console.log(v0.copy().sub(v2).toString());
}

This code experiments with the effect of 3D vectors on 2D vectors.
This issue deals with the vector generated by createVector with no arguments, but it is three-dimensional, so I created a test like this.
In other words, there are two points of contention.

• The vector generated by createVector without arguments is [0,0,0].
• How to define operations between vectors of different dimensions

Up until now, every vector has been three-dimensional. In the case of two dimensions, we have dealt with it by using vectors whose third component is 0. No one has felt inconvenienced.

So subtracting [3,3,3] from [1,1] results in the three-dimensional [-2,-2,-3]. It would be strange if you were creating a sketch where you were only dealing with two-dimensional vectors and suddenly a three-dimensional vector appeared.

But it was the user who provided it. The user provided the 3D vector. It was a declaration of intent to use 3D vectors. But if the vectors remained 2D, that could be a problem.

So, does changing the dimension solve the problem? Well, this is where the first problem mentioned earlier comes into play: the dimension of a vector generated by createVector without arguments is three.

In other words, 3D vectors are generated regardless of the user's intention, which can lead to unintended problems (or rather, this actually happened to me while I was drawing a sketch. I am the victim).

Again, up until now it has been fine all vectors were three-dimensional.
I have no idea how dimensions were introduced into vectors, so I can really say nothing about this, and I'm sure other users don't either.
However, dimension has been introduced.
So, this change needs to be made with care. For example, if a change is made so that subtracting [3,3,3] from [1,1] results in [-2,-2], this may be considered a bug and reported.

I decided to declare it as createVector(0,0) so that doesn't cause any problems (and I do that in my own code), but users who don't know that a dimension has been introduced may run into the same problem.

It's difficult.

[sidwellr]

I just noticed that createVector with no arguments creates a vector with three elements but with a dimension property of 2. This certainly needs to be fixed!

I think that subtracting [3,3,3] from [1,1] should result in [-2,-2]. I agree someone might consider it a bug. If it results in [-2,-2,-3] others might consider it a bug. (Hopefully the documentation will be updated to clarify the intended behavior.) But currently, the result is [-2, -2, NaN], which I consider a bug!

[Ahmed-Armaan]

another approach is to put error handling in the add and sub functions. Whenever the vector of conflicting dimensions are added or subtracted, it can be considered an error . I believe it will make the implementation strict and easier to work with in long term

[sidwellr]

Throwing an error when unlike vectors are added or subtracted is mathematically correct, and would be the obvious choice for a strongly-typed language. I don't personally object to it, but have one concern: p5.js is intended to be friendly for beginners. I think beginners would understand that vectors of different dimension can't be added, but they might be perplexed with how to fix the problem since there is no easy way to change the dimensionality of a vector. (Whether such a feature should be added is a separate issue.)

[inaridarkfox4231]

In the previous specification, ℝ² naturally embedded into ℝ³, allowing users to freely add and subtract 2D and 3D vectors.

In mathematics, there is a concept called a subvector space. A vector in ℝ² is naturally embedded in ℝ³ with the third component being 0. Therefore, applying a vector in ℝ³ to other vector in ℝ², will simply result in a new vector, and there will be no problems.

For example, in three-dimensional space, if you prepare a vector in the plane where z is 0 as a two-dimensional vector and try to move it by applying a three-dimensional vector, you would expect the result to be a three-dimensional vector...

The confusion comes from the fact that instances of the same class can have different classes. Creating multiple classes that cannot operate calculation on each other simply because they have a different number of arguments is just confusing.

There is no problem if they are different classes. If operations are performed between different classes, I think that the specifications should be such that an error is output.

Users lose flexibility, but I don't know what they get in return.

[sidwellr]

Tagging the Math stewards @GregStanton and @holomorfo in case they want to weigh in on the issue.

[inaridarkfox4231]

I was watching this.
[p5.js 2.0] Vector nD getter and setter, added values.
[p5.js 2.0] Vector n-dimentional and Matrix Interface

I've discovered a few interesting things that I'll add.

About operations between vectors of different dimensions

I thought it hadn't been taken into consideration at all, but that wasn't the case.
Vector methods
Here, it appears that a full range of vector operations were being checked to see what specifications should be used.
Both add() and sub() are overlooked. Why didn't they do anything? I don't know.
However, it seems that div() was a concern, and the following is written:

Updated working for scalar, vector and array, question about different dimension vectors, how should it be handled? should we only divide what is possible and leave the rest unchanged? For example, what to do in this case [1,2,3]/[8,9] should it be: [1/8,2/9,3] or in the other case [8,9]/[1,2,3] =? [8/1, 9/2] ? I've not seen this implementation or inference in any other mathematics library or in general. @limzykenneth @davepagurek

So I wanted to see if this topic was brought up in the discussion from this point onwards.

It wasn't listed anywhere.

That aside, what was the result of this calculation?

function setup() {
	createCanvas(windowWidth, windowHeight);
	background(100);
	const v=createVector(8,9);
	const w=createVector(1,2,3);
	v.div(w);
	console.log(v.toString()); // [8, 4.5]

	const v1=createVector(8,9);
	const w1=createVector(1,2,3);
	w1.div(v1);
	console.log(w1.toString()); // [0.125, 0.2222..., NaN]
}

It becomes NaN. I don't have any particular opinion about this. There is no error, so I guess it means "you shouldn't do this calculation".

But an error will occur with the 1.x specifications.

I don't know why it decided to set it to NaN instead of throwing an error. But in the context of the issue we're working on, the problem is that sub() was overlooked. It should have been found by performing any operation between vectors of any dimension, so I don't know why it was overlooked.

About creating a vector without arguments

It was discussed here. It seems that the spec was created by a contributor.
comment by davepagurek

      }
      if (dimensions === 0) {
        this.dimensions = 2;
        this._values = [0, 0, 0];

Should the dimensions here match the number of items in _values?

One thing I'm just now thinking about, should the default vector when no argument is passed be 2D instead of 3D? Seeing as most people start learning to create sketches with 2D before moving into 3D.

I think that makes sense. Even in webgl mode, you may very well still be using 2D vectors for a number of things, so its not a bad idea to have to be explicit to make 3D vectors.

Frankly, I didn't really understand what it meant.

I don't know what the right thing to do is. For now, all we know is that no proper specifications have been established.

[sidwellr]

Interesting. I didn't realize mult and div could do per-component operations (I've only done scalar multiplication and division). Looks like mult works the way I want it, which may or may not be the "best" way. At least someone asked about div, but never got an answer. I doesn't really matter a lot to me which option is chosen, but it really should be consistent for add, sub, mult, and div. (And rem! It seems strange that it only works up to 3 dimensions.)