On Friday, 11 October 2013 at 17:08:26 UTC, ponce wrote:
Good idea since there is so much implementations of
"fixed-width vectors/matrices" since the beginning of times.
There has been such efforts in the past to makes it more
standardized.
There will be
On Friday, 11 October 2013 at 16:10:21 UTC, FreeSlave wrote:
Both templates should support all floating point types and
moreover user-defined (for example wrappers for GMP library
and others).
And integers for eg. video processing. Thankfully it's not that
much harder.
For efficiency in both cases matrices should use
one-dimensional array for inner representation. But actually
I'm not sure if matrices should support other container types
besides standard D arrays. The good thing about
one-dimensional arrays is that they can be easily exposed to
foreign functions, for example, to C libraries and OpenGL. So
we should take care about memory layout - at least row-major
and column-major. I think it can be templated too.
About 3D graphics: I don't think choosing one or the other is
that big a deal. I tend to prefer row major order but eg. gl3n
uses the reverse.
It's up to you. If you templated against order, you will be
able to implement you "asTransposed" idea.
Sometimes user takes data from some other source and wants to
avoid copying in Matrix construction, but she also wants to
get matrix functionality. So we should provide "arrayAsMatrix"
adapter, that can adopt one-dimensional and two-dimensional
arrays making them feel like matrices. It definitely should
not make copy of dynamic array, but I'm not sure about static.
Possible with pointer cast? (strict aliasing rule aside)
Well, pointer cast would work for one-dimensional arrays, but not
for dynamic two-dimensional matrices. Anyway it's just
implementation specific, not design.
About operation overloading. It's quite clear about 'add' and
'subtruct' operations, but what's about product? Here I think
all 'op'-functions should be 'element by element' operations.
The product to me is a special case.
Element-wise matrix multiplication is seldom used, it's a lot
more common to want normal matrix multiplication. I and others
use "*" for that purpose.
https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L1734
https://github.com/p0nce/gfm/blob/master/gfm/math/matrix.d#L150
https://github.com/gecko0307/dlib/blob/master/dlib/math/matrix.d#L171
So we can use all other operations too without ambiguity. For
actual matrix multiplication it can provide 'multiply' or
'product' function. It's similar to Maxima approach, besides
Maxima uses dot notation for these needs.
But it's dissimilar to shader languages and existing D
libraries.
That's actual a common issue to use operator overloading for
multiplication or not. Some people does not like it, others
prefer this way. That's why I want to discuss it. "*" is more
practical, but user always expects "/" as opposite. Matrix has no
division operation (except of dividing by scalar), only
multiplication by invertible matrix.
Invertible matrix. It must not be allowed for square
StaticMatrix.
I meant non-square of course. Sorry for this mistake. I don't
know how to edit my posts here.
The another issue is getting of minors. It can use some operator
overload magic and look like
matrix(start, middle1, middle2, end)(start, middle1, middle2, end)
where the first () stands for rows and the second () stands for
columns. Gap is between middle1 and middle2. There is efficiency
issue - should it make copy or work like some kind of
two-dimensional range?
