3D Math Data structures/SIMD

[Lukas Pinkowski]

Janice Caron wrote:

> On 12/21/07, Lukas Pinkowski <Lukas.Pinkowski at web.de> wrote:
>> 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?
> 
> That's an awful lot of reserved words - especially when you take into
> account the distinction between complex float, complex double, and ...
> er ... the other one. :-) 

Well, let's make a std.vectormath with:

module std.vectormath;

alias __v2f vec2f;
alias __v3f vec3f; 

...

Double underscores are reserved anyway, so where exactly is the problem?
People have accepted having hundreds of keywords and reserved identifiers
in D.
Also I forgot the integer and bool versions like v2i, v2ui, a.s.o.

> Also, I couldn't help but notice that all 
> your matrices seem to be square, and in general, they're not.

In general matrices aren't limited to 4x4, right? But those are used in 3D
math dominantly; in case you want higher dimensions, you can build them on
top of the built in ones.

> What's wrong with Vector!(3,float), Matrix!(4,4,real),
> Matrix!(3,4,cdouble), etc.?

They are not builtin types. You know, we have those nice SIMD instructions
in our processors, but using them requires inline assembler, or
non-portable/non-standard language extensions (see the GCC SIMD extension).

> And as for API, well, the operator overloads should just do the
> obvious thing (although I admit we lack dot-product and cross-product
> operators, but if you used u*v for dot product and u.cross(v) for
> cross product, I don't see anyone complaining).

If we wouldn't go for identifiers, cross product could use #, but I don't
know what to use for dot product. Multiplication should be component-wise
multiplication, exactly like addition is component-wise addition (like in
the shading languages).

> In other words, it /should/ be a library feature.

Well, that's the C++ way of thinking. 
I'm pretty sure, if C++ existed back then, when floating point
(co-)processors became widespread, people would argue, floating point
support should be a library feature.