std.linalg

ponce contact at gam3sfrommmmmars.fr
Fri Oct 11 10:08:22 PDT 2013


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)

> 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.

> Invertible matrix. It must not be allowed for square 
> StaticMatrix. DynamicMatrix may make checks at runtime. Same as 
> for transposition we can implement 'invert' to invert in place 
> and 'inverted' to make copy. There is issue here - what should 
> we do when determinant is 0?

Use enforce to crash. Dividing by zero is not recoverable.



More information about the Digitalmars-d mailing list