Instance attributes

[zanellia]

Partially addresses this: #7. For now, only instance attributes are implemented.

[giaf]

what is getrsm ?

[zanellia]

GEneral TRiangular Solve with Matrix right hand-side. I guess we can drop it and have just getrs? It's also a matter of type of the arguments and how overloading is handled by prometeo's parser. For now I found it easier to have two separate methods getrsm and getrsv (the second is not even implemented atm).

[giaf]

potrf_l

[zanellia]

I thought it might make sense to try to have API's of different level of abstraction and expose a simplified potrf, where lower is implicit, and a more verbose and versatile one where one could also pass the lower/upper and normal/transposed arguments. I still haven't found out a systematic way of defining these abstraction levels of the API, so any recommendation is more than welcome :)

[giaf]

What is potrsm? I guess you wanted to refer to potrs, same for getrs.

[zanellia]

same as above for getrsm

[zanellia]

Thanks @giaf for the review! I think it would make sense to trigger some discussion (with @tmmsartor
and @perrutquist, if they like) on how to formalize a more structured draft of the linear algebra API with different level of abstraction.

[giaf]

From the naming of the other routines (e.g. gemm_nt, trmm_rlnn) I assumed that you wanted to stick to the BLASFEO naming (a.k.a. the standard BLAS and LAPACK naming, just with the literal arguments added to the name itself) for this level of abstraction. My comments go in that direction.

I agree that there can be different levels of abstraction, but I would strongly recommend to be consistent with that, while now it's a bit of a mixed bag: some "standard BLASFEO" (gemm_nt, trmm_rlnn), some "standard BLAS with implicitly fixed arguments" (potrf only lower), some "extended BLAS" (getrsm=getrs+m).

[giaf]

Just to give a couple of point to think about, IMO the more standard is the name, the better, since people familiar with e.g. BLAS and LAPACK can just jump into it and use it straight away, or refer to the rich amount of documentation available online for these libraries.
For the BLASFEO API, I decided to hard-code the literals after the standard BLAS and LAPACK name because often only a few variants of the routines are available, and therefore it's easier for the user to just look at the header files and see which ones are there, instead of having to try them all out at run time and discover that from the error messages.

[zanellia]

replaced by #13