0

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.


Note:

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

closed as primarily opinion-based by Robert Harvey, durron597, Bart van Ingen Schenau, gnat, GlenH7 Mar 28 '15 at 14:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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
0

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.