3D Math Data structures/SIMD

[Janice Caron]

On 12/22/07, Rioshin an'Harthen <rharth75 at hotmail.com> wrote:
> it
> would be much better if they were "standardized" by the programming language
> in question, be it C, C++, D...

With this I completely agree. However, there's more than one way to
standardise. Having a module in Phobos called std.matrix would be
standardisation, and I think that would be perfectly good enough.


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

D seems to adopt the general principle that if it can be done with the
language as-is, then there is no need to implement as a new feature.
Walter is particularly cautious about introducing new reserved words,
as clearly that would break existing code which used those words as
identifiers.


> vector(uint[4]) vec;

Doesn't seem much different to my earlier suggestion of

     Vector!(4,uint) vec;

although I guess

    Vector!(uint[4]) vec;

might work just as well. So long as template code can deduce the
element type and size, it probably wouldn't make much difference.


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

It's not obvious to me why the elements should be x, y, z and w. How
does this generalize? What's the rule? Is it "Start at 'x', proceed up
the English alphabet till you get to 'z', then after that work
backwards from 'w' down to 'a'? I don't get it. Seems like an odd and
arbitrary rule, and also totally English-centric. (Well, we wouldn't
want to use the Cyrillic alphabet would we? That's foreign!)

Plus, what would the elements be named for a 100-element vector?


> matrix(cdouble[4]) mat;
> with members accessible by mat.11, mat.12, mat.13, mat.14, mat.21 ... mat.43
> and mat.44.

I'd think that elements should be zero-based, not one-based. Plus,
your syntax makes no provision for matrices with more than nine
elements in either dimension. It's just not general enough.


> Actually, come to think of it, should we separate quaternions from vectors,
> since they're actually quite different than your standard vector?

Of course! We should always separate apples from oranges, as they're
quite different things. I don't think that's even an issue.