Small vector and matrix proposed for phobos2 now on github

[Robert Jacques]

On Mon, 26 Apr 2010 18:02:53 -0300, Gareth Charnock <gareth.tpc at gmail.com>  
wrote:
>> - 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.

Personally, I'd expect a pure mathematician to argue that the * operator  
isn't equivalent to the • operator and might even argue for the more  
formal <,> operator. :) Remember, unlike complex numbers, * isn't defined  
between vector types, so the library needs to decide what operator it's  
mapping to it. As for principal of least surprise, lots of libraries op  
for using array-wise * and v.dot(v), including (IIRC) all of the various  
GPU shading/compute languages.

P.S. I use Opera for my web browsing.