12 ms·
>Some languages have fancy syntax that omits the need for braces. But for those that don't, this is clearly an array of 3 arrays of 3 ints. >It's only intuitiv
by dannymi 4y ago
>Some languages have fancy syntax that omits the need for braces. But for those that don't, this is clearly an array of 3 arrays of 3 ints.
>It's only intuitive to think of this as an array of rows given how it's laid out visually.
That's often the least important thing when designing a fast library.
It's much better to optimize for common operations in your problem to be fast and thus choose the storage layout of a individual matrix instance accordingly (row-major, column-major, triangular, diagonal, block diagonal, band) so your data cache doesn't get tripped up regularily.
The actual API for creating new matrices can still be standardized and always the same. You can have the standardized API accept four column vectors for construction just as well. Just document it as such.
If you want, you can also represent the different kinds of vectors as different types, so you don't get identification problems that shouldn't exist. Also, lists of vectors are just that and there's no reason to represent both "list" and "vector" as "array". There are reasons to make the API for "vector" richer--especially since that's why the term "vector" was defined in the first place.
But for tiny 4x4 matrices, who cares about caching. But 4x4 are a minority use of matrices. Try 4096x4096.
As for OpenGL, they chose to keep the internal storage of matrices the same as it was on IRIS GL. That's a good decision for OpenGL and orthogonal to the question of how column vectors of that matrix can be accessed via an API and to the question of how row vectors of that matrix can be accessed via an API and to the question of how matrices can be created via an API.
From a mathematics standpoint, a matrix represents a linear map (a map is a function that takes a vector in space V to a vector in space W). It makes sense to be able to use matrix and linear map interchangeably as a user (i.e. use them just like you would call functions).
- bruce343434 4y ago> Try 4096x4096 Where should I, if we keep the context of OpenGL? Apart from that, I consider this an implementation issue. My post was mostly about keeping a consistent "front end" semantics. However the compiler or library transforms the data does not pertain to it. To be fair, I mentioned memory layout. If I had left that out, would we agree with eachother?
- dannymi 4y ago(Column|Row) Vectors and matrices are abstractions, and having abstractions that are always the same API in all of programming (not just OpenGL) would be nice. Of course making them again and again different and dumb is easier. So we got a lot of programs with weird arrays with no information on what matrix is what style. And thus readers get confused because half the information is missing in the source code! That makes things needlessly obtuse. But let's say one would try to make the API for column vectors (resp row vectors resp matrices) always the same (OpenGL or not), then it's important to look at bigger matrices. Otherwise you wouldn't care about storage layout at all and that's gonna come back to bite you in the ass (several orders of magnitude slower than possible). >But when you define a matrix in most programming languages you can only really write it like this: mat = [ [1,2,3], [4,5,6], [7,8,9] ] I wouldn't repurpose arrays like that.