Hello,
This previous question http://software.intel.com/en-us/forums/topic/297849 didn't get any answer. Could someone please tell me why the Sparse BLAS has no const modifiers, whereas the CBLAS is the way it should be (with const modifiers !). It is really "painful" to have to const_cast the parameters at each call to the Sparse BLAS interface.
Thank you.
链接已复制
Much of the BLAS, LAPACK and other parts of MKL are based on Fortran sources. A clue to this is the passing of arguments by address instead of value when MKL routines are called from C/C++. In Fortran 77 and earlier, there was no distinction between input and output arguments of subprograms as far as the language syntax rules were concerned. It was up to the programmer to preserve the contents of input arrays and document such usage.
LAPACKE, on the other hand, provides native C interfaces, and helps with matrix arguments by enabling them to be passed in row-major order.
Do you think there is a change that it will be changed someday, so that CBLAS and Sparse BLAS interfaces match ? (I don't see how you can bring regression by changing const qualifiers, except if you are doing shady things under the hood but I doubt that).
qweasd q. wrote:
Do you think there is a change that it will be changed someday, so that CBLAS and Sparse BLAS interfaces match ? (I don't see how you can bring regression by changing const qualifiers, except if you are doing shady things under the hood but I doubt that).
yes, we have such Feature Request submitted and we will modify these interfaces in the one of the future releases.j
Sergey Kostrov wrote:
>>...Do you think there is a change that it will be changed someday, so that CBLAS and Sparse BLAS interfaces match?
I think it is possible and you need to make a Feature Request with as better as posiible explanation and example(s).
Here is one of the simplest example one could think of:
[cpp]#include "mkl.h"
int main () {
MKL_INT* _I;
MKL_INT* _J;
double* _C;
double one = 1;
double zero = 0;
const MKL_INT n = 50, k = 50;
double x
Gennady Fedorov (Intel) wrote:
here is the #issue for your reference - DPD200346477
Great, thanks.