Skip to content

Refactor p5.Vector to prioritize smaller dimension in binary operations on mismatched-size vectors#8676

Draft
ksen0 wants to merge 20 commits intoprocessing:dev-2.0from
ksen0:vector-smaller-priority
Draft

Refactor p5.Vector to prioritize smaller dimension in binary operations on mismatched-size vectors#8676
ksen0 wants to merge 20 commits intoprocessing:dev-2.0from
ksen0:vector-smaller-priority

Conversation

@ksen0
Copy link
Copy Markdown
Member

@ksen0 ksen0 commented Mar 25, 2026

Note: this is a draft!

Because it's a major change, this needs more work and feedback. It is shared as a draft open for comment

In 2.x, vectors can be of different dimensions. Binary operations should not be done on vectors with mismatched dimensions; however, for backwards compatibility and to avoid breaking older code that might have edge cases (resulting from how 1.x handled 2D vectors), we decided to apply the logic of "always use the smaller dimension" when operating on two vectors with mismatched size. Note that solo numeric arguments (such as createVector(1,2,3).mult(2)) are still supported.

To discuss on discord, please see the "vector-discussion" channel in "Code" category. Prior community discussion which led to this is documented in these meeting notes. One important consideration here was that switching from 2D to 3D can benefit from a bit of intentional scaffolded friction: code should not completely break, but it's okay if it looks a bit wrong, because doing binary operations on mismatched vectors is not actually supported, and should not be done.

PR Checklist

  • npm run lint passes
  • [Inline reference] is included / updated
  • [Unit tests] are included / updated

}
if (this instanceof p5) {
return new p5.Vector(
this._fromRadians.bind(this),
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is done only in p5.Vector.

@p5-bot
Copy link
Copy Markdown

p5-bot bot commented Mar 25, 2026

assert.isAbove(mockUserError.mock.calls.length, 0, 'FES.userError should have been called');


assert.isAbove(mockUserError.mock.calls.length, 0, 'FES.userError should have been called, btw: '+globalThis.FESCalled);
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @davepagurek ! I don't know why this is happening but some tests that as far as I can tell should not be affected are not passing:

Image

I checked the behavior and errors are emitted correctly.

I did do an FES mocking in p5.Vector.js unit tests like this:

    globalThis.FESCalled = false;
    globalThis.p5 = {
      _friendlyError: function(msg, func) {
        globalThis.FESCalled = true;
        console.warn(msg);
      }
    };

Though I don't think it's related.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are those getting reset correctly when the tests finish?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a quick test, if you skip all those vector tests, do you see the strands tests start to pass?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davepagurek hmmm good question, no must be the code. Same errors with:

          include: [
            //'./test/unit/math/p5.Vector.js',
            './test/unit/webgl/*.js',
          ],

suite('new p5.Vector(1,2)', function () {
beforeEach(function () {
v = new mockP5.Vector(1, 2, undefined);
v = new Vector(1, 2);
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@limzykenneth another substantive test case change; fails because I've added number validation to Vector based on my understanding of our earlier discussion


test('should set values to [0,0,0] if values array is empty', function () {
test('should NOT set values to [0,0,0] if values array is empty', function () {
v.values = [];
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a substantive change reflecting intent of the update

let vect = new mockP5.Vector(1, 2, 3, 4);
assert.equal(vect.getValue(5), 1);
let vect = new Vector(1, 2, 3, 4);
globalThis.FESCalled = false;
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@limzykenneth this and another fails test stopped passing when I mocked FES, I think maybe they were not failing for the right reason originally? Anyway, here's a proposed update to reflect my understanding of the intent of the setValue/getValue tests

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not getting a fail here specifically but the fail I see locally are when the p5.Vector class is trying to use p5._friendlyError. It does not necessarily have a reference to p5 to it should not really use that, I need to complete the FES rewrite stuff I'm still working on but in this kind of case, it can use a regular console.log instead. There isn't anything special this is doing.

@ksen0 ksen0 changed the title Refactor p5.Vector binary operations to use smaller-vector priority logic Refactor p5.Vector to prioritize smaller dimension in binary operations on mismatched vectors Mar 25, 2026
@ksen0 ksen0 changed the title Refactor p5.Vector to prioritize smaller dimension in binary operations on mismatched vectors Refactor p5.Vector to prioritize smaller dimension in binary operations on mismatched-size vectors Mar 25, 2026
@ksen0 ksen0 mentioned this pull request Mar 25, 2026
@limzykenneth
Copy link
Copy Markdown
Member

I believe the CI test is failing on only the use of p5._friendlyError and not for p5.strands, so if CI all pass and @davepagurek can confirm whether the test pass overall for him locally too, it should be ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants