- 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.
