3D Math Data structures/SIMD

[Rioshin an'Harthen]

"Lukas Pinkowski" <Lukas.Pinkowski at web.de> kirjoitti viestissä 
news:fkg4qg$mm$1 at digitalmars.com...
> I'm wondering why the 2D/3D/4D-vector and -matrix data types don't find
> their way into the mainstream programming languages as builtin types?
> The only that I know of that have builtin-support are the shader languages
> (HLSL, GLSL, Cg, ...) and I suppose the VectorC/C++-compiler. Instead the
> vector- and matrix-class is coded over and over again, with different
> 3D-libraries using their own implementation/interface.
> SIMD instructions are pretty 'old' now, but the compilers support them 
> only
> through non-portable extensions, or handwritten assembly.
>
> I think the programming language of the future should have those builtin
> instead of in myriads of libraries.
>
> It would be nice if one of the Open Source D-compilers (GDC, LLVMDC) would
> implement such an extension to D in an experimental branch; don't know if
> it's easy to generate SIMD-code with the GCC backend, but LLVM is supposed
> to make it easy, right?
> Hopefully this extension could propagate after some time into the official 
> D
> spec. Even if Walter won't touch the backend again, DMD could at least
> provide a software implementation (like for 64bit integer operations).
>
> Seeing that D seems to be quite popular for game programming and numerics,
> this would be a nice addition.
>
> Well, as for the typenames, I guess something along
>
> v2f, v3f, v4f, m2f, m3f, m4f: vectors and matrices based on float
> v2d, v3d, v4d, m2d, m3d, m4d: vectors and matrices based on double
> v2r, v3r, v4r, m2r, m3r, m4r: vectors and matrices based on real
>
> Or vec2f instead of v2f, mat2f instead of m2f, a.s.o. Complex versions 
> would
> be probably needed, too?

I've found myself wanting the vector and matrix types to be built into the 
compiler too many times, as almost all the different libraries have had to 
implement them. And usually, they're incompatible with each other, so it 
would be much better if they were "standardized" by the programming language 
in question, be it C, C++, D...

However, a gross of new keywords isn't a good idea. I'd prefer to only use 
*two* new keywords: vector and matrix, as follows:

vector(uint[4]) vec;

with members accessible by vec.x, vec.y, vec.z and vec.w, and

matrix(cdouble[4]) mat;

with members accessible by mat.11, mat.12, mat.13, mat.14, mat.21 ... mat.43 
and mat.44.

If, e.g. a vector of three vectors of four doubles were required, it could 
be defined with

vector( vector( double[4] )[3] )

(with the spacing just for clarity)

Actually, come to think of it, should we separate quaternions from vectors, 
since they're actually quite different than your standard vector? This would 
likely make it easier to support mathematics between quaternions, a 
quaternion and a matrix, and a quaternion and a vector. Something like

quaternion(double) quat;

with the members accessible by quat.r, quat.i, quat.j and quat.k.