std.linalg

[FreeSlave]

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?