Vector performance

[F i L]

Manu wrote:
> Yes the lib would supply standard operations, probably even a 
> matrix type or 2.

Okay cool. That's basically what I wanted to know. However, I'm 
still wondering exactly how flexible these libraries will be.

> Have some code of more complex operations?

My main concern is with my "transition" objects. Example:

    struct Transition(T) {
        T value, start, target;
        alias value this;

        void update(U)(U iteration) {
            value = start + ((target - start) * iteration);
        }
    }


    struct Vector4(T) {
        T x, y, z, w;

        auto abs() { ... }
        auto dot() { ... }
        auto norm() { ... }
        // ect...

        static if (isTransition(T)) {
            void update(U)(U iteration) {
                x.update(iteration);
                y.update(iteration);
                z.update(iteration);
                w.update(iteration);
            }
        }
    }


    void main() {
        // Simple transition vector
        auto tranVec = Transition!(Vector4!float)();
        tranVec.target = {50f, 36f}
        tranVec.update(0.5f);

        // Or transition per channel
        auto vecTran = Vector4!(Transition!float)();
        vecTran.x.target = 50f;
        vecTran.y.target = 36f;
        vecTran.update();
    }

I could make a free function "auto Linear(U)(U start, U target)" 
but it's but best to keep things in object oriented containers, 
IMO. I've illustrated a simple linear transition here, but the 
goal is to make many different transition types: Bezier, EaseIn, 
Circular, Bounce, etc and continuous/physics one like: 
SmoothLookAt, Giggly, Shaky, etc.

My matrix code also looks something like:

    struct Matrix4(T)
     if (isVector(T) || isTransitionOfVector(T)) {
        T x, y, z, w;
    }

So Transitions potentially work with matrices in some areas. I'm 
still new to Quarternion math, but I'm guessing these might be 
able to apply there as well.

So my main concern is how SIMD will effect this sort of 
flexibility, or if I'm going to have to rethink my whole model 
here to accommodate SSE operations. SIMD is usually 128 bit 
right? So making a Vector4!double doesn't really work... unless 
it was something like:

    struct Vector4(T) {
        version (SIMD_128) {
            static if (T.sizeof == 32) {
                __v128 xyzw;
            }
            else if (T.sizeof == 64) {
                __v128 xy;
                __v128 zw;
            }
        }
        version (SIMD_256) {
            // ...
        }
    }

Of course, that would obviously complicate the method code quite 
a bit. IDK, your thoughts?