Small vector and matrix proposed for phobos2 now on github

[Gareth Charnock]

> - Element wise *, etc are important operators that you need to cleanly 
> support. Design-wise, since we can't do Matlab style operators, I prefer 
> */+- to be element wise, and then use dot/cross/solve for matrix ops. 
> This seems to avoid the confusion of as having some ops be matrix style 
> and some ops be array style. Since D is unicode, you could also add the 
> real inner product operator as an alias. Also, don't forget the outer 
> product, aka broadcasting, i.e. v.dot(v.T).
> - static foreach seems to add some overhead, although I don't know why. 
> What you should really do is write some benchmarks and test static 
> foreach, array ops and hand-unrolling for several vector sizes.

I'm afraid you've just set me off a rant. I apologise, but you just told 
me that your web browser was Google.

I think we may be heading for a culture clash. I approach vectors and 
matrices from a math/physics background. Here vector's primary and only 
purpose is to model a directed arrow in some space (3D space, function 
space (lots and lots of things can be shoehorned into the idea of a 
space) but always in some space.). Consequently, the only things that 
matter about a vector are physical quantities. What are physical 
quantities? Anything that is invariant under a coordinate transform. For 
example, if you have a unit stick sitting due north and and you measure 
it with a ruler sitting due north and one due east you conclude this:

(1,0)

But if you measure with two rulers due NW and NE you conclude:

(0.707,0.707)

These are a same physical vector. You can see this by using the rotation 
  matrix between the coordinate systems:

(0.707 -0.707)(1)=(0.707)
(0.707  0.707)(0) (0.707)

So the vector coordinates (a coincidence of the placement of the rulers) 
are not physical but the vector is. I don't think I have never seen a 
physical equation requiring a element by element multiplication but I 
have seen lots of dot products. There is a reason for this. The dot 
product of a vector with another vector gives you a scalar. A scalar is 
not just a number (vector components are numbers but not scalars), a 
scalar is a number that does not change under a coordinate transform. 
The height of a hill does not change when you draw a map in different 
ways so it that is a scalar. The element by element product does not 
yield anything other than N numbers which are an accident of the 
coordinate system.

Matrices are either a system of linear equations or a representation of 
a tensor. Again, the most natural way to combine them is the matrix 
product (although there are other natural ways: direct product, 
kronchecker product and index contraction). The best way to think about 
a matrix is not to think about the matrix components, but as an 
indivisible whole. Element by element multiplication seems equally arbarant.

These things have been so deeply ingrained that I didn't even consider 
an element by element product in the design and I had to do a double 
take before I got what was being asked for. When the dot product was 
asked for as a "dot" I thought it would replace

I'd consider any use of element by element multiplication has probably a 
sign of a hack, and possibly a sign that what you are trying to use a 
vector for is actually an array of numbers. Hacks are fine but I don't 
think they're worth an operator. I'd want a big, explicit 
elementWiseProduct() to tell me something was going on.

Good user interfaces are modelled on the principle of least surprise. I 
think there are two different models of least surprise here. I want 
transcribe my matrix-vector equations directly into D and:

u=Ap+Bq   p,q,u vectors, A matrix, B matrix

Looks better as:
u=A*p+B*q;

Than:
u=matrix_vector_product(A,p) + matrix_vector_product(B,q)

But I think programmers are more used to using vector and array 
interchangeably. Possibly this is a reason why a vector struct is needed 
rather than defining free operators over just any old array. You want 
the operators to have their vector-meanings for vectors while retaining 
their field-meanings when dealing with fields like float, double, real etc.

Here's another one from the C++ standard library. std::complex is a pair 
of numbers. Why isn't operator* a element wise multiplication with an 
separate complex_product(.,.)? Because if you use std::complex you 
probably want to model complex numbers.

tl;dr
Google is not really your web browser, even though I know what you mean. 
An array is not really a vector, especially when  3D (or any other D) 
space .


....

PS: Okay so I just had a looked at the matrix and vector classes in 
Ogre3D and irrlicht. Looks like they both define v*v as element wise 
multiplication but m*m is matrix multiplication. That just seems even 
more inconsistent.