Multiply Vector By Vector

What Happens When You Multiply Vectors Together

Vector multiplication isn't one operation. It's three or four depending on what you're actually trying to do, and mixing them up will silently give you wrong answers that look plausible. I spent a week debugging a physics simulation where the collision response was slightly off until I realized someone had used the Hadamard product where a dot product was required. The code ran. The numbers looked fine. Everything was wrong. There are three standard operations people lump under "multiply vector by vector," and a fourth that shows up in machine learning codebases. The dot product (also called the scalar product or inner product) takes two vectors of the same dimension and returns a single number. You multiply corresponding components and sum them up: a · b = ab + ab + ... + ab. The result tells you something about the angle between the vectors. If the dot product is zero, they're perpendicular. If it's positive, the angle is acute. If negative, obtuse. In my experience working with rendering pipelines, this is by far the most commonly needed operation. You use it for lighting calculations, projecting one vector onto another, and checking whether surfaces face a light source.

The cross product only works in three dimensions. It takes two 3D vectors and returns a third 3D vector that's perpendicular to both input vectors. The formula is a × b = (ab - ab, ab - ab, ab - ab). This is essential for finding surface normals from two edge vectors of a triangle, which is something you do constantly in computer graphics. I once had to reconstruct face normals for a mesh where the winding order was inconsistent across the model. The cross product gave me normals pointing inward on half the triangles, which made the renderer show everything as back-face culled. Fixing the winding order sorted it, but that took most of a Tuesday. The Hadamard product (element-wise multiplication) multiplies corresponding components without summing. For vectors a and b, the result is (ab, ab, ..., ab). This doesn't have a fancy geometric interpretation the way the dot product does. It shows up in signal processing, in masking operations, and in neural network implementations where you're applying element-wise transformations. In NumPy it's just np.multiply(a, b) or a * b if both are arrays. In MATLAB it's a .* b. The operator differs by language, which is a common source of bugs when people port code between ecosystems. Then there's the outer product, which produces a matrix, not a vector. For two column vectors a and b, the outer product a b is a matrix where element [i][j] equals a × b. This is used in things like constructing covariance matrices and in some tensor operations. Less common in day-to-day work unless you're in linear algebra heavy lifting.

When to Use Which Operation

The fundamental question is what the result needs to be. If you need a scalar that represents alignment or projection, use the dot product. If you need a perpendicular direction in 3D space, use the cross product. If you need to scale each component independently, use element-wise multiplication. If you need a matrix representation of the interaction between two vectors, use the outer product. A practical example from my work: I was building a simple particle system where each particle had a velocity vector and a drag coefficient vector. The drag force needed to oppose motion, so I calculated the component of velocity along each axis and scaled it by the drag coefficient. That's element-wise multiplication. But to determine whether a particle was moving toward or away from a target point, I computed the dot product of the velocity vector with the direction-to-target vector. Same data, two different operations, both necessary. Another thing beginners miss: the dot product is commutative (a · b = b · a), but the cross product is not (a × b = -(b × a)). The order matters. I've seen this cause subtle bugs where swapping two vectors in a cross product calculation flipped a normal direction and broke rendering on one side of an object but not the other. The code looked symmetric. It wasn't.

Common Pitfalls

Dimension mismatches are the obvious one. You can't take the dot product of a 3D vector and a 4D vector. Most languages will throw an error. Some won't — NumPy will broadcast in ways that produce results you didn't intend if you're not careful, especially with higher-dimensional arrays. Another pitfall is assuming the dot product gives you a magnitude. It gives you |a||b|cos(). Only when both vectors are unit vectors does the dot product equal cos(), and only when is zero does it equal 1. People sometimes normalize after computing a dot product as if that's a general technique. It's not. Normalizing the inputs before dotting them is the right approach if you want the cosine of the angle. A less obvious issue: the cross product of two parallel vectors is the zero vector. This seems fine until you're using it to compute a normal and your input vectors happen to be nearly parallel due to floating point imprecision. The resulting normal will have huge numerical error. In practice, I add a check: if the magnitude of the cross product result is below a threshold, fall back to a predefined normal or skip the face entirely. This came up when processing scanned 3D models where some triangle vertices were nearly collinear.

Implementation Notes

In Python with NumPy: Dot product: np.dot(a, b) or a @ b Cross product: np.cross(a, b)

Element-wise: a * b (for arrays) or np.multiply(a, b) Outer product: np.outer(a, b) In C++ with Eigen:

Dot product: a.dot(b) Cross product: a.cross(b) Element-wise: a.cwiseProduct(b)

The performance difference between these operations is negligible for small vectors. The real cost shows up when you're doing millions of them per frame in a shader or loop. In that case, SIMD-friendly libraries like Eigen or directly using intrinsics matter. I once optimized a loop that was computing dot products for every pixel against a light direction. Switching from a naive implementation to using aligned SIMD through Eigen cut the relevant section from about 40ms per frame down to roughly 6ms on the target hardware. The algorithm didn't change. The operation was the same. Just the memory access patterns did. If you're working in a language without a mature linear algebra library, the dot product is simple enough to implement in a few lines. The cross product too. Element-wise multiplication is trivial. But I'd strongly recommend against writing your own outer product implementation for anything beyond educational purposes. The memory layout and indexing get messy fast, and the risk of off-by-one errors is high. One final thing: be careful about the difference between row vectors and column vectors. Mathematically it shouldn't matter for dot and cross products, but it does matter for the outer product and for matrix multiplication conventions. Some libraries treat vectors as row vectors by default, others as column vectors. Check your library's documentation. I learned this the hard way when porting a graphics utility from a GLSL-centric codebase to a Direct3D one and the coordinate system conventions were subtly different.