YAVMA - Yet Another Vector Math API

I’m writing a vector math api with a design that some may consider strange and myself have some doubts of it’s usefulness.

The design is similar to the vecmath api from Java 3D in which classes are used to store vector data but in my case i have Float2,Float3,… Int2,Int3,… which are all final. Attributes correspond to the name of the class (the primitive) and are all public e0,e1,e2,… matching the count given by the class suffix number. For example:
public final class Float4 { public float e0,e1,e2,e3; }.

I don’t have classes that extend other classes like VectorX extends TupleX to avoid virtual methods.

Storage classes don’t have any methods, only public attributes.

I have a final class called Vec which supports static final methods (again to avoid virtual methods) and uses the storage classes above as arguments. For example ‘Vec.clear(aFloat4)’, ‘Vec.fill(aDouble3,1.0)’ or ‘double d=Vec.len(aFloat4)’ which returns the length of aFloat4.

Since there are too many methods for every possible combination of vector operation and storage class and the code is too I’m generating the Vec.java file using another java file called VecMaker.java. The storage types are Byte, Short, Int, Float, Double and the dimensions are 2, 3, 4, 9, 16. 9 and 16 is because i’m encoding matrices in a linear array. There’s 30 storage classes and thus 30 clear methods for maximum efficiency. With all the other methods to do vector math there will be something like 1000 methods, maybe more.

I have some doubts about this.

Should i use storage classes like the ones described above or don’t use any storage classes and work with arrays of primitives or primitive data buffers directly in method arguments?

Is the decision to use final and non-virtual methods for the vector math operations a good decision for performance?

Should i have final storage classes and avoid extending classes like what happens with the vecmath api?

Will having classes with thousands of static final methods cause any performance problems?

Your bytecode must be less than 64KB, so you probably won’t be able to stuff thousands of methods on a class.

Anyway, what’s the use of yet another primitive holder class (set). Everybody and their dog have their own Vector3, Point2, Matrix4x3, etc. Now think about the user, he’d constantly have to convert his datatype to your datatype. Now you may ask why he wouldn’t switch to all your datatypes… well, first there are dependencies in his code, second, it’s just a royal pain in the ass to write pA.e1 + pB.e2, if you’re used to pA.x + pB.y

Honestly, I’d give such a vector math API zero chance.

My $0.02 :-\

I could put those methods inside the storage classes. Instead of doing something like Vec.clear(aFloat4) it would become aFloat4.clear() and generate each class, but i’m still a bit suspicious of the performance issues of working with non-final classes. So it could be something like this:

public final class Float4 {
public float e0,e1,e2,e3;
//Methods for vectors
public void clear() {…}
public void fill(float s) {…}
public void neg(Float4 v) {…}

}

And the same methods generated for all the other classes. Except no use inheritance or virtual methods.

What do you think?

I don’t see a reason for this. Vecmath is already optimal performance-wise, nearly all the methods are final and not overriding anything so no virtual overhead. Also it’s a standard API and you have better chances to interoperate between different libraries. There were numerous attempts to create better library, but every enhancement ideas had some flaws (like malicious side effects).

But thank you for trying, you never know when you create something better :slight_smile:

The 64KB limit is per-method not for whole class.

I guess there’s no trouble if i just copy paste code from inside the vecmath api if i keep the GPL. My problem with vecmath is maintenance and using inheritance. Maintenance is by far the biggest issue. Vecmath has a lot of classes style Vector and editing one class implies editing all the others. So what i’m going to do is to create a class that generates the java source. The files generated are a combo of: Byte, Int, Short, Float, Double types and 2,3,4,9,16 dimensions. There’s no inheritance and all classes are final. With a few differences with the interface, like for example most methods return this at the end to allow chaining operations, this should work in a similar way to vecmath.