• drug (5/5) Jan 26 2021 It is not easy to understand what mir library one should use to work
• 9il (3/9) Jan 29 2021 Yes, it is wrapper around a common BLAS libraries such as
• drug (12/22) Jan 29 2021 I've implemented the filter using mir-lapack. But then I found lubeck -
• 9il (8/11) Jan 29 2021 No. BLAS/LAPACK API's can't use compile-time information. User
• drug (3/17) Feb 01 2021 Yes, it's how I did it.

drug <drug2004 bk.ru> writes:

It is not easy to understand what mir library one should use to work 
with matrices. mir-glas turns out unsupported now and I try to use 
mir-blas. I need to reimplement my Kalman filter version to use more 
high dimension matrix than 4x4 plus Kronecker product. Is mir-blas 
recommended to work with matrices?

9il <ilyayaroshenko gmail.com> writes:

On Tuesday, 26 January 2021 at 14:43:08 UTC, drug wrote:
 It is not easy to understand what mir library one should use to 
 work with matrices. mir-glas turns out unsupported now and I 
 try to use mir-blas. I need to reimplement my Kalman filter 
 version to use more high dimension matrix than 4x4 plus 
 Kronecker product. Is mir-blas recommended to work with 
 matrices?

Yes, it is wrapper around a common BLAS libraries such as 
OpenBLAS or Intel MKL.

drug <drug2004 bk.ru> writes:

On 1/29/21 4:50 PM, 9il wrote:
 On Tuesday, 26 January 2021 at 14:43:08 UTC, drug wrote:
 It is not easy to understand what mir library one should use to work 
 with matrices. mir-glas turns out unsupported now and I try to use 
 mir-blas. I need to reimplement my Kalman filter version to use more 
 high dimension matrix than 4x4 plus Kronecker product. Is mir-blas 
 recommended to work with matrices?

 
 Yes, it is wrapper around a common BLAS libraries such as OpenBLAS or 
 Intel MKL.
 

I've implemented the filter using mir-lapack. But then I found lubeck - 
I didn't try it but it seemed that it provided more high level 
functionality like matrix inversion (`inv` wrapper is much handy than 
`getrf_` and `dgetri_` combination I used directly). So my first thought 
was that lubeck should be more preferable but then I found there was 
lubeck2 so I didn't know what to think further. But I pretty well 
understand the situation and the reasons behind it. Thank you for you 
efforts!

Between is there a plan to implement some sort of static slice where the 
lengths of the dimensions are known in compile time? Compiler help is 
very useful.

9il <ilyayaroshenko gmail.com> writes:

On Friday, 29 January 2021 at 15:35:49 UTC, drug wrote:
 Between is there a plan to implement some sort of static slice 
 where the lengths of the dimensions are known in compile time? 
 Compiler help is very useful.

No. BLAS/LAPACK API's can't use compile-time information. User 
matrix loops can be optimized by the compiler using constants and 
without introducing new types. If you need a stack-allocated 
matrix, then a 1D stack-allocated array can be used

import mir.slice.slice;

double[12] payload;
auto matrix = payload[].sliced(3, 4);

drug <drug2004 bk.ru> writes:

On 1/29/21 8:20 PM, 9il wrote:
 On Friday, 29 January 2021 at 15:35:49 UTC, drug wrote:
 Between is there a plan to implement some sort of static slice where 
 the lengths of the dimensions are known in compile time? Compiler help 
 is very useful.

 
 No. BLAS/LAPACK API's can't use compile-time information. User matrix 

I see

 loops can be optimized by the compiler using constants and without 
 introducing new types. If you need a stack-allocated matrix, then a 1D 
 stack-allocated array can be used >
 import mir.slice.slice;
 
 double[12] payload;
 auto matrix = payload[].sliced(3, 4);
 

Yes, it's how I did it.