I'm helping develop a 3D Vector class, which has common operations such as:

  • v = v1.cross(v2)
  • v = v1 * v2 - infix multiply for dot product.
  • v = v1 + v2 - infix addition.
  • v = v1.slerp(v2) - spherical linear interpolation.
  • v.normalize() - make unit length.

These operations are very common for 3D Vector math classes (listed examples below).

Edit, we have classes for RGB Color, Rotations etc... so this question is specifically about 3D Vector's

My question is: Is there an API naming convention for element wise multiplication?

Apache-Commons-Math calls it ebeMultiply but this seems a bit ad-hoc and I didn't see the name used elsewhere.


While I rather not get into specifics here are some API's which are similar in scope to ours:
Unity3D, Apache Commons Math, Mahout, Armadillo, la4j

  • 2
    What's stopping you from calling it Hadamard Product like in the link you included?
    – Doval
    Mar 27 '15 at 20:24
  • @Doval, to describe in docs or comments - sure, but this seems like an odd choice for an API, v1.hadamard_product(v2), while correct, seems a bit verbose, possibly a reason its not in common use? (Though I did find one example - la4j.org/apidocs/org/la4j/…)
    – ideasman42
    Mar 27 '15 at 20:27
  • 2
    Any kind of mathematics done with words rather than symbols is going to be verbose. Nothing can be done about that; at best you'll have to pick an abbreviation, and if the mathematicians don't have one, it doesn't matter which one you pick. I'd argue you have a bigger naming problem if * means dot product. There's at least 3 kinds of vector multiplication and * is not the symbol for any of them, and out of the three you chose one that doesn't return a vector (unlike int/real multiplication, which is what * usually means in a programming language, and does return the same type).
    – Doval
    Mar 27 '15 at 20:46
  • No, there is no general, widely accepted naming convention (there is not even one for the operations you listed above). That should not stop you from picking intuitive names like the ones above,
    – Doc Brown
    Mar 27 '15 at 22:53
  • Would it make any sense to have a generic higher-order function like perElementOp() to bypass this naming issue entirely?
    – Ixrec
    Mar 27 '15 at 23:08

Here are some ideas. Note: naming contests are not very suited to the StackExchange format, but the discussion of rationale behind naming choices could be suitable if useful principles can be summarized.

The question is meaningful in that it has a specific context: a 3D vector class.

While OP had not explained the precise use case of the class or library, one could easily imagine such a class could be useful for 3D geometry and 3D (RGB/YCbCr) colorspace.

However, if the library ever needs to extended to other usage, such as RGBA (transparency), 3D Perspective (projective) geometry, rotational mechanics, etc., it is foreseeable that a 3D vector class is insufficient on its own.

For example, a typical ColorMatrix implementation is a 5x5 matrix, with each column and row associated with: Red, Green, Blue, Alpha (opacity), and finally Constant-term. The needs for 3D perspective vector operations are similar: a 3D vector is padded with a fourth term named "scale" or "divisor", and operations are performed with 4x4 matrix.

Therefore, one will need to think about future extensibility of use cases, or to preclude them, when one considers naming issues.

Another fun-issue (or non-issue) is whether one would like to distinguish between 3D vectors of different physical meanings. The simplest case being a 3D vector in space representing (x, y, z), versus a 3D color vector representing (r, g, b). While this is all too easy to handle in most programming languages, you still have to choose a design with careful deliberation.

One more language-specific issue (before discussing the naming issue) is the operator overriding capabilities of that language. In particular, if the library will eventually support multiple languages, this requires careful naming.

In additional to the libraries mentioned above, one can also consider:

Now, the naming.

  • Alternative names for multiplication, such as:
    • product, prod
    • mul
    • times
  • Words that indicate one-by-one processing as prefix/suffix:
    • each, elem, for,
  • Words that indicate data parallelism as prefix/suffix:
    • parfor, par, vec
    • Note: sometimes, a single letter prefix could be sufficient:
      • Intel SSE uses the letter "P" to indicate SIMD operations.
      • AMD NEON uses the letter "V" to indicate SIMD operations.
  • Combinations of such words:
    • elemMul, parMul, eachMul, mulEach, etc.
  • Just a note, - your point about using vector's in other context's is valid. We do have classes Color Euler, Quaternion, Matrix - so the context here is really limited to typical 3D geometry use.
    – ideasman42
    Mar 28 '15 at 7:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.