Should PVector Switch to Doubles?

[sampottinger]

From @StanLepunK in processing#5753,

Ciao Sam few word about PVector, I read there an idea to change PVector class for Processing 4 https://github.com/processing/processing/wiki/Processing-4#other-nuts-and-bolts . Few time ago i propose do @benfry to work it, if he want on my Vector class to design it specificly to Processing https://github.com/StanLepunK/Rope/tree/master/src/rope/vector
Maybe with your branch may be if Ben and the Processing Staff is ok, I can work on it to merge with your branch ? Let me-us know, if you're interested.

What are people's thoughts?

[knupel]

Super, my initiatial proposition is not work on PVector double, just propose a class Vector version different, with ivec vecand bvecand why not dvecfor double. And use vector like a type for the case, like in the glsl language. for now my library provide the same service than PVector for the class vecand few more... and provide the minium for the class ivecand for bvec et voilà!

[clankill3r]

To quote the other-nuts-and-bolts page:

New vector class
PVector is optimized in ways that people don’t really use, making it more confusing than necessary

I don't really get what Ben Fry means with this. For me personally it's that a lot of methods can't accept a PVector as an argument. Like line, scale, translate etc. I would really like to know why other people don't use it. Is this statement even true. And if they don't use it, then what do they use instead?

But since the name of your OP, how often have people that they prefer double in practise.
I don't really see issues about it on github or the forum. I myself have it like once in a few years that I need to use double which often is like a 5 minute fix.

Also introducing a second vector will be a pain. Now half the libraries won't support that vector. And changing it to double is also bad. Cause now half the libraries are broken cause they are not compatible with the updated vector.

I think if the vector has to be double then it should be done when processing is moving away from java to another language.

Anyway, about the library of StanLepunk.
I think having 18 classes for having a vector is not a step forward but a huge step backwards.
Also the library is way to complex and inefficient, I don't mean this offensive.

Let's take vec2 for example. First of all classes have to start with a capital, that way we know when we use static methods that they are static and not used on some variable. It's one of the most important java conventions.

Back on topic vec2 extends vec, so it inherits all those properties!

public int num;
public float x,y,z,w = Float.NaN;
public float e,f = Float.NaN; // for vec5 and vec6 
public float s,t,p,q = Float.NaN;
public float u,v = Float.NaN;

Then vec extends BigBang which contains:

public PApplet pa;
private String VERSION = "0.8.5.30";

So every vector created has not only a reference to the PApplet, but also a version.

Then when it comes to methods there are things like:

public float max() {
    float [] list = new float[num];
    if(num == 2) {
      list[0] = x;
      list[1] = y;
    } else if(num == 3) {
      list[0] = x;
      list[1] = y;
      list[2] = z;
    } else if(num == 4) {
      list[0] = x;
      list[1] = y;
      list[2] = z;
      list[3] = w;
    } else if(num == 5) {
      list[0] = x;
      list[1] = y;
      list[2] = z;
      list[3] = w;
      list[4] = e;
    } else if(num == 6) {
      list[0] = x;
      list[1] = y;
      list[2] = z;
      list[3] = w;
      list[4] = e;
      list[5] = e;
    } 
    return max(list);
  }

Which not only creates a new array everytime. It also has to set all the elements, and does a lot of branching which is not ideal for cpu's.

Also when I look at other things I see:

  public vec3 set(float x, float y, float z) {
  	this.x = this.s = x;
  	this.y = this.t = y;
  	this.z = this.p = z;
  	return this;
  }

There is so much overhead.

Apart from the Vector discussion. I thought the main reason of this fork was support for Java 11, OpenJDK, and OpenJFX. Which I believe work fine? For me personally I would really love to see this migrate in the main branch (of processing/processing) soon.

[hamoid]

Last year openFrameworks (a C++ framework in some ways similar to Processing) replaced it's own vector classes by the GLM library. This avoid reinventing the wheel, is a standard, and the syntax is similar to GLSL.

I just checked and found GLM for JVM: https://github.com/kotlin-graphics/glm

GLM provides the vector and matrix math required for 2D and 3D graphics, so in theory it might help simplify the Processing code base, and using the same syntax as in other platforms would make it easier to port code between them. At the same time it can be a huge effort.

Still I wanted to throw the idea here.

Also, the vector story in Processing is long :) It seems standards are not liked, so ToxicLibs, heMesh and maybe others implement their own. Then you always end up with glue code to convert vectors from one to another. But I've seen the same on C++ too. Too bad 2D and 3D vectors and matrices are not a core datatype.

[knupel]

@clankill3r thanks for your strong feedback :) that's very nice for my personnal code improvement.
for the first I know the convention about the uppercase for the classes name, and I do it to be similar of the GLSL convention and I I assume this weird choice but very logic for me, because I want considere the vec like a type, not like a class. I'm not real expert coder, more artist coder for me when you know the rules sometime it's can be necessary to break it. In this case I considere it's a time to break the rule.

For the second...this library is work in progress, I'm sure there is a lot of default must be, can be corrected, improved... At the first time of my library I don't use the class vec ivec bvecbut directly vec2 vec3 vec4 vec5 and vec6 but after using like that, I see the utility to use a mother class to swap from vec2 to vec3 to return vec2 and to do that have a mother class is not bad... I understand that's create a useless variable and it's a problem. but is I understand when Java when variable is not instantiate that's not a problem for the memory ?

For the third, I'm very open to find a way to improve my library all help is very very very welcome @clankill3r

@hamoid thx for the link https://github.com/kotlin-graphics/glm when I've a time I going to look it, that's can be a very very good way for my library and for Processing too :) thanks.

PS : So for my english, it's like my code very very artistic !

[benfry]

To quote the other-nuts-and-bolts page:

New vector class
PVector is optimized in ways that people don’t really use, making it more confusing than necessary

I don't really get what Ben Fry means with this.

I don't get the weirdly negative tone in these comments and the rest of the thread. Why am I referenced personally? I'm building this thing in my free time and this animosity is bizarre.

It means that a lot of the design decisions, and the way that the methods work in PVector are ways to keep things fast (i.e. the various static methods that don't allocate memory, etc), but that most people don't use them that way, so the result is that their use makes their code a little weirder than necessary, if they didn't care about performance.

For me personally it's that a lot of methods can't accept a PVector as an argument. Like line, scale, translate etc.

Passing a PVector instead of x and y is slower. In the past it was 2-3x slower. I haven't bothered profiling it recently. In practice, it can be even slower than that because you're creating a bunch of PVector objects inside draw(), which makes the garbage collector do a bunch of work.

So… do we ~double the number of methods in PGraphics to support something that we wouldn't encourage? That doesn't seem like a good idea.

I would really like to know why other people don't use it. Is this statement even true. And if they don't use it, then what do they use instead?

As with all design decisions we've made, it's always about providing a balance between 1) what's intuitive, 2) what people will use, and 3) what has good performance. There are always tradeoffs, but those are the criteria, and we do what we feel is best for the community.

Also, the vector story in Processing is long :)

Is it? A vector class was (originally) terrible for performance, but it's helpful as a container. So we eventually added a class for it. Others made their own, but weren't used universally, so it didn't make sense to use them as a replacement. Toxiclibs had a nice one, but it was designed for advanced users, not our core audience. No need to be melodramatic.

But addressing the original question for this issue… Why would we switch to double? What's fixed? There are currently 524 open issues for the project. To my knowledge, it doesn't fix a single one of them. It also doubles the amount of memory required to hold the objects. Sure, double is technically better than float for accuracy, but understanding practice and context here are important.

If you want double in a vector object, why not make a library? If anyone wants it badly in PGraphics, it's straightforward to extend PGraphics to do that. If you do that, and others want to do the same, then it's likely to be picked up as part of the core.

[knupel]

@benfry thanks for your light !
I understand well the Processing process now, and better the PVector history.
Personnally at the begin I use a lot PVector and i never have a problem with memory or slow down problem with it, except when I create maybe one or more thousand of it... I just create my vector class because tape the name PVector is too long versus just vec and manage the difference between vec2 or vec3 is sometime usefull and have a vec4 class is helpful too.

And again thank to you and @REAS to lead the awesome project.

[clankill3r]

@StanLepunK To reduce the noise in this topic I gave some feedback on your library in your repository. knupel/Rope#4 I can provide some more later.

@benfry

To quote the other-nuts-and-bolts page:

New vector class
PVector is optimized in ways that people don’t really use, making it more confusing than necessary

I don't really get what Ben Fry means with this.

I don't get the weirdly negative tone in these comments and the rest of the thread. Why am I referenced personally? I'm building this thing in my free time and this animosity is bizarre.

It was not meant negative. And it was referenced personally since you wrote that page.
I just didn't know if it was about the lack of double support or vec2 and vec4 or the methods present.