> There is one very little thing that annoys me in almost every language, the > lack of a standard, reference, core, graphics vector (and colour vector) math > implementation. One that follows the rules of the normal mathematical axis, > y=up, x=right, z=into the screen and has transformation matrices for all > other systems they have come up with. Similar with colour, a unit-less vector > rgb<0, 1, 0.75> that can be transformed into any form and colour space.
This is a bit confusing to me for a few reasons: 1. Why does something like this need to be a stdlib feature? This sort of thing is a use case for a package. Just because something is a package doesn't make it worth less. And as long as people care about the thing it provides, people will know about it. 2. "normal mathematical axis, y=up, x=right, z=into the screen": how is that normal? If you said "typical computer science / video game / ..." definition, I'd understand what you mean. But math doesn't care about what "y" is. 3. A 3-vector for colors is imo problematic. Once you leave your average color spaces behind, you need to store more information than 3 numbers (CIECAM02, ...). While I'm not saying having working linear algebra for those basic color spaces is useless, the reason it doesn't generalize to arbitrary color spaces is reason enough such a thing shouldn't be in the stdlib. For colors there's [chroma](https://github.com/treeform/chroma) (yes, it uses regular Nim objects instead of vectors). For vector math there's plenty of libraries out there. Nim even had a vector library in the stdlib in the past btw. Sorry, if I'm missing something.
