LAPACK, LAPACKE and CLAPACK

[iurisegtovich]

Quoting your README.md

"I really do not understand the difference between LAPACK, LAPACKE and CLAPACK there might be some confusion in the tutorials"

You might want to check this page for clarifications:
http://nicolas.limare.net/pro/notes/2014/10/31_cblas_clapack_lapacke/

"The reference Fortran code for BLAS and LAPACK defines de facto a Fortran API, implemented by multiple vendors with code tuned to get the best performance on a given hardware."
"CBLAS is in fact just a very thin layer (no performance penalty) over BLAS, with these benefits:"
"There also is something on Netlib called CLAPACK, but it is not a standard C interface to the Fortran LAPACK. CLAPACK is a translation of the Fortran LAPACK code into C."
"For LAPACK, the native C interface is LAPACKE, not CLAPACK"
"LAPACKE is to LAPACK what CBLAS is to BLAS"

[Foadsf]

@iurisegtovich Thanks a lot for your comment and happy to see my humble repo has been noticed. I did this almost year a ago when I was working on a home project and the moment when i started it I had no idea about the these API/SDKs. Well, later I got more expert and figured these issues out. you may see my comment on the page you have mentioned :D
You may also check this StackOverflow Q&A to see more elaborate answers.
I'm unfortunately busy with other work stuff at the moment and not able to update the repo. but any contributions are highly welcomed. you may even take it and do what ever you like with it.

[iurisegtovich]

Hi, thank you for replying. I noticed your repository while I was studying this stuff and creating a repository of my own with tests and conclusions [iurisegtovich/fortranLAB](https://github.com/iurisegtovich/fortranLAB). what were your conclusions, are you sucessfully using BLAS/LAPACK? via atlas/openBLAS/mkl? what about GSL? any other nice library that you would like to recommend?

[Foadsf]

"I noticed your repository while I was studying this stuff "

was my repo any help? I would be happy to know that :)

"creating a repository of my own with tests and conclusions (iurisegtovich/fortranLAB)"

I took a look. it seems like a great peace of work. some points I noticed:

1. my repo was an attempt to learn how to use C to solve math problems, not Fortran in particular. the only reason I got into Fortran was because historically most of the math programs have been written in Fortran. and that's why learning C-Fortran mixed programing is important IMHO.
2. I see also that you have mentioned GPU programing libraries. that's great. it is the future I believe. Specially if somebody develops libraries based on pure OpenGL, not OpenCL or CUDA, because there are no opensource implementations of them. not to mention for embedded systems and mobile platforms OpenGL is still the de facto.

" are you sucessfully using BLAS/LAPACK"

I did successfully use them in the home project I was working on at the moment. i was developing a program to solve mechanical simulations. but right now I'm busy with some other stuff.

"atlas/openBLAS"

As far as I know BLAS and LAPACK are APIs, not an implementation per say. Although the original implementations by NetLibs still exist. ATLAS and openBLAS are some of the implementations to my knowledge and if you write your code there is no difference which one do you use.

"mkl"

Sorry but I'm highly against any closed source vendor biased program/library such as mkl and CUDA. why should I write a code which only works on a specific type of HW?!

[iurisegtovich]

"I noticed your repository while I was studying this stuff "

was my repo any help? I would be happy to know that :)

I found it near the end of my studying day, and I was, at first, focused on running GSL rather than directly calling BLAS/LAPACK stuff. But it was motivating to see someone struggling with the same things I was, and I saved your URL to read your files while I try BLAS/LAPACK stuff directly later

"creating a repository of my own with tests and conclusions (iurisegtovich/fortranLAB)"

I took a look. it seems like a great peace of work. some points I noticed:

my repo was an attempt to learn how to use C to solve math problems, not Fortran in particular. the only reason I got into Fortran was because historically most of the math programs have been written in Fortran. and that's why learning C-Fortran mixed programing is important IMHO.

for me it was exactly the other way around, i mainly use fortran, but gsl has only a c native interface.
to use gsl in fortran i needed to lear interop to write my own interfaces, or at least to understand whats behind fgsl, the fortran interface for gsl develope by lrz.de

I see also that you have mentioned GPU programing libraries. that's great. it is the future I believe. Specially if somebody develops libraries based on pure OpenGL, not OpenCL or CUDA, because there are no opensource implementations of them. not to mention for embedded systems and mobile platforms OpenGL is still the de facto.

I put gpu there as intentions, I am attending some lectures on programming for gpu this month but i won't be using them for a while

"mkl"

Sorry but I'm highly against any closed source vendor biased program/library such as mkl and CUDA. why should I write a code which only works on a specific type of HW?!

mkl is actually "closed source vendor biased", but differently from CUDA, it does work on non-intel hardware, although not with intel specific optimizations. It is free-to-use recently and Anaconda' distribution of python comes with it. I plan on studying both OpenBLAS and mkl (which should be simple as they both should follow BLAS/LAPACK standards)