Printable View
I'm working on a little matrix library. But now I'm faced with a tricky interface question.
Assigning a matrix to a scalar, does it make more sense to
(A) set every element of the matrix to that value?
(B) set the diagonals to that value, and the rest to zero?
From a mathematical standpoint (B) seems logical. But thinking of actual use cases (A) might make better sense.
Or maybe do (B) for square matrices and (A) for non-square ones? I don't know, that could be confusing too!
multiply the identity matrix by the scalar.
"The term scalar multiplication refers to the product of a real number and a matrix. In scalar multiplication, each entry in the matrix is multiplied by the given scalar."
Identity matrix - Wikipedia
Wait, you mean assign a scalar to a matrix, not assign a matrix to a scalar, right?
If so, I think you should go with A since you noted it is more sensible for actual use cases. You shouldn't make the behaviour different for square matrices because it will be surprising to someone who encountered it previously for non-square matrices.
However, that you can see two reasonable alternative interpretations for what assignment of a scalar means could indicate that it is best for both interpretations to be named functions so as to avoid misinterpretation.
I guess to be semantically correct it really should be "assigning a variable a value" or "assigning a value to a variable". So yes, you are correct, assign a scalar to a matrix.Quote:
Originally Posted by laserlight
Right, the principle of least surprise. Fair enough.Quote:
Originally Posted by laserlight
Maybe something like this then:Quote:
Originally Posted by laserlight
1) Constructor takes an optional boolean; if true (the default) all elements are set, otherwise just the diagonals.
2) Assignment operator sets all elements to the value.
3) A member function will be provided to create a scalar matrix.
Seems pretty reasonable, no?
Having thought about it for a while now, I've finally decided to simply stick with the old behaviour. It's just more consistent, mathematically. I did of course add a fill() member function for cases where each element should be set to the same value.
All in all though I think it came out pretty well. It handles most of the basic operations, solves equations and the like, and can even be "attached" to existing stack variables (an array of doubles, for example).
If anyone's interested in playing with it, let me know, I'll post the code on Github.
I saw this over the weekend but got a bit distracted and forgot to reply. I was going to say that seems fine to me, although 3 seems to be the same as 1 with the boolean set to false, but maybe you meant "set a scalar matrix" rather than creating a new one.Quote:
Originally Posted by Sir Galahad
Ah, the implication being that the old behaviour is B, so even though a scalar matrix isn't a scalar, by association it sounds close enough to be "more consistent, mathematically"? I think that works too, except that then you'll have to forbid assignment of a scalar to a non-square matrix, and if you do have a constructor that takes a scalar, it would be consistent for that scalar to populate a square matrix by default, which could make it a little odd to handle for non-square matrices (e.g., do you make it a must for a non-square matrix have the boolean set, or do you default to fill instead if the matrix is non-square, even though this could lead to surprises).Quote:
Originally Posted by Sir Galahad
Quote:
Originally Posted by laserlight
Looking at other libraries now, filling does indeed seem to be a more typical interface. So maybe you're right. I'll give it another go...