Py5Vector Prototype Discussion

[hx2A]

This is a discussion thread for the prototype of the new Py5Vector class.

First, read this blog post to understand the background and the general idea for how the prototype works.

The code associated with the blog post is on gist. When the code starts changing, you'll want to go directly to the repo instead.

Comments and feedback welcome!

[tabreturn]

Great work, @hx2A. What you've provided covers everything I need. Of course, it's always handy to have NumPy at hand (which is sorely missing in processing.py). "Swizzling" is something new to me -- not sure where I'll use it, but it's sure to prove handy somewhere.

[hx2A]

"Swizzling" is something new to me -- not sure where I'll use it, but it's sure to prove handy somewhere.

It is new to me also. I learned about it because I was doing some opengl coding at the same time I was building the vector class. It occurred to me that it would be a neat feature to include, and relatively easy to implement with the __getattr__ method. Introducing swizzling to coders might be helpful because then they won't be confused by it when reading opengl code (like I was).

[villares]

Cheers @hx2A!

I suppose the missing blog post at the start of this discussion became the basis for the documentation at https://py5.ixora.io/reference/py5vector.html ?

Something I have noticed porting old examples is that as operations between 2D and 3D vectors are not allowed, initializing a Py5Vector like v = Py5Vector() breaks some converted code, as it creates a 3D vector in the middle of otherwise 2D vectors.

Would it slow things down too much if when a "2D and 3D" operation arises and one of the vector is the "null vector", it gets promoted to 3D or demoted to 2D?

Or perhaps should we disallow calling Py5Vector() without arguments? Forcing people to write Py5Vector(0, 0), or Py5Vector(0, 0, 0) or to call Py5Vector2D, Py5Vector3D, or even Py5Vector4D? or perhaps follow the pattern of Py5Vector.random(dim)?

[hx2A]

Would it slow things down too much if when a "2D and 3D" operation arises and one of the vector is the "null vector", it gets promoted to 3D or demoted to 2D?

This is an interesting design idea, and for some reason it kind of reminds me of Schrödinger's cat. The Py5Vector instance doesn't "decide" if it is a 2D, 3D, or 4D vector until you do an operation with it that forces it to become one of those things. For some parts of the code this is possible but it gets complicated if the user writes code like v1.xyz = 1, 2, 3, which would rule out it being a 2D vector but it could still be 3D or 4D. There would be a lot to keep track of. I don't think this would work very well in practice.

In Processing, the PVector class is always a 3D vector. When you create a PVector with 2 values, it sets the 3rd dimension to 0. This approach has advantages and disadvantages.

In py5, when you create a new Py5Vector instance with no parameters, it will by default be 3D. If you want it to be 2D, you can do that with:

v1 = Py5Vector(dim=2)
v2 = Py5Vector2D()
v3 = Py5Vector(0, 0)

One idea I thought of just now is to create a class method that lets you set the default dimension. It would work like this:

Py5Vector.set_default_dim(2)

v4 = Py5Vector()  # a 2D vector

Or perhaps should we disallow calling Py5Vector() without arguments?

I would rather not do this but I could be persuaded if you think this is the best way to steer users in a way that directs them to use py5 in a way that is less error prone.

[villares]

There would be a lot to keep track of. I don't think this would work very well in practice.

I can imagine it would be too much trouble. I thought it could be a hack just for 0, 0 or 0, 0, 0 vectors... everything else would give an error as usual.

I would rather not do this but I could be persuaded if you think this is the best way to steer users in a way that directs them to use py5 in a way that is less error prone.

Maybe this porting context I'm working in is less relevant than the user context of creating new sketches,.. I have to think about this.

If we subscribe to the "fail fast" idea maybe communicating to the user earlier they have to be aware of / choose the dimensionality of a new zero-filled-vector, it might be a good thing. But I'm not sure. There is also a Zen of Python thing about avoiding guesses in cases of ambiguity that could apply... we are guessing 3D as the default, and sane defaults are a good thing too. Hard stuff to decide.

The smallest change I can imagine is adding this to the error message:

RuntimeError: Cannot perform addition operation on a 2D Py5Vector a 3D Py5Vector. The dimensions must be the same.
Check in your code that Py5Vector() will return a 3D Py5Vector: Py5Vector3D(0., 0., 0.).

[hx2A]

The smallest change I can imagine is adding this to the error message:

How about this: perhaps the Py5Vector can "remember" that it was created with no parameters and that the default dimension of 3 was used. If it later gives a dimension error, it can augment the error message with extra information to inform the user that perhaps they want to explicitly provide a dimension.

[villares]

brilliant!