Switches and fake indexing

I was looking at this section of the vm spec:
http://java.sun.com/docs/books/vmspec/html/Compiling.doc.html#4095

and realized there are two methods to resolve a switch. That is tableswitch and lookupswitch. Tableswitch is good for when the switch cases are sequencial numbers like this (0,1,2,3), which happen to be the indices of a 4D vector.

Since I have recently restarted some work on a vecmath api i was planning i was thinking about doing something like this, using switches to fake array indexing. The float4D class is like Vector4d except that atributes are private and the indexing methods.


class float4D {
  private float _0;
  private float _1;
  private float _2;
  private float _3;
  ... constructors ...
  public float get0() { return _0; }
  public float get1() { return _1; }
  public float get2() { return _2; }
  public float get3() { return _3; }
  public void set0(float f) { _0=f; }
  public void set1(float f) { _1=f; }
  public void set2(float f) { _2=f; }
  public void set3(float f) { _3=f; }
  public float get(int i) { switch (i) { 
                              case 0: return _0; 
                              case 1: return _1; 
                              case 2: return _2; 
                              case 3: return _3; 
                              case 4: return _4;  
                              default: return 0 } }
  public void set(int i,float f) { switch (i) { 
                              case 0: _0=f;  
                              case 1: _1=f; 
                              case 2: _2=f; 
                              case 3: _3=f; 
                              case 4: _4=f;  } }
  ... more stuff ...
}

What do you guys think of this class? Would it be useful to have these indexing methods? Any idea if the speed match to array indexing?

Simply using an array is most likely faster than a switch, but if I were you I’d create some test cases and profile them before trying out things like this, just to see if it’s worth bothering at all.

Not to mention the hassle of working with such a class…


float4 a = new float4();
float4 b = new float4();
float4 c = new float4();

// this
c.set(0, a.get(0) + b.get(0));
c.set(1, a.get(1) + b.get(1));
c.set(2, a.get(2) + b.get(2));

// as opposed to
c.x = a.x + b.x;
c.y = a.y + b.y;
c.z = a.z + b.z;

What would be the advantage? Really… what did you have in mind.

Switches are just tightly-packed jump-tables, you will (on average) have a few if’s every lookup, that’s more costly than no lookup (a field)

A little benchmark:
on client VM 1.5 it is factor 1250% slower (!)
on server VM 1.5 it is factor 47% slower

I supose its not a big deal if i just write four instructions instead of using a loop:


v.set0(x)
v.set1(y)
v.set2(z)
v.set3(w)

Does anyone know if its still worth to use fields instead of arrays for vectors?

This would simplify a lot of things:


class floatTuple {
  float[] components;
}

Im making a python script to generate java source for tuples similar to the java.vecmath ones. Possible primitive types are byte, short, int, long, float, double combined with dimensions 1D,2D,3D,4D,9D (for 3x3 matrices), 16D (for 4x4 matrices). This gives a total of 6x6=36 different classes. What im doing is just using python to do what java templates don’t do.

Each class supports basic tuple operations +, -, neg, abs, combine, literals, slicing, conversion, coercing, construction, import/export data from/to buffers and arrays, etc. All classes final for fastest access.

For linear algebra operations these would in a LinAlg final class factory with a method: LinAlg la = LinAlg.default() that works just like Math. Another class i would have to generate to work with 36 different tuples.


LinAlg la = LinAlg.default();
float4D v1 = new float4D(1, 0, 0, 0);
float4D v2 = new float4D(0, 1, 0, 0);
float4D v3;
float16D m;
v3 = la.cross(v1,v2)
rot = la.makeRotMatrix(alpha,v1,beta,v2,gama,v3)

This stuff is almost like machine code instructions but it is the fast and better looking i can get, while keeping classes final.