3D Math Data structures/SIMD

Bill Baxter dnewsgroup at billbaxter.com
Sat Dec 22 01:14:22 PST 2007


Rioshin an'Harthen wrote:
> "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.

Yeh, and what about octonians too!  And we better distinguish 
homogeneous vectors and matrices from regular vectors and matrices.  And 
really, points and vectors are different things, so they should have 
distinct types (unless you're using the homogenous varieties, since 
those can express both).  And really it's all expressed so much more 
elegantly using geometric algebra so we better have multivectors and 
wedge products in the language too.

The problem is there are a lot of interesting and useful mathematical 
constructs out there.  Where do you stop.

It seems to me like primitive types in the language should reflect what 
the silicon is actually capable of [*].  Anything else can be a library. 
  There is no quaternion multiplication instruction on any hardware I'm 
aware of, so that's a construct that doesn't belong in the language in 
my opinion.  I do see there being some value in basic primitives that 
can use these SSE type instructions efficiently, and then those can be 
used to build the uber-efficient quaternions and matrices etc as library 
types.

--bb

[*] not sure how I feel about complex numbers on this score.  I think a 
standard library implementation would have been sufficient.
Only thing I could find about C++0x and complex numbers was this:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1612.pdf
on this page
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2142.html
which skimming basically looks like it says the problems with 
std::complex can be fixed without making complex a built-in type.

--bb



More information about the Digitalmars-d mailing list