topic In this case code looks ok to in Intel® oneAPI Math Kernel Library

Computing Variance of Multiple Rows

Alfredo_L_ — Thu, 19 Jan 2017 14:51:08 GMT

I'm having trouble figuring out how to compute the variance of multiple rows in a Matrix.

Suppose I have an M row by N column matrix X for which I need to compute N different variances, one for each row in a row-major (C-style) matrix.

For a concrete example, suppose my matrix contains time series data containing "periods" observations per day for "days" days. I want to calculate the variance for each day's "periods" observations and have an array "vars" containing "days" variances (one for each day). Below is the code I've attempted to use but it only produces one variance (and the rest, zeroes).

/// \brief computes one variance per day given a matrix of daily time series
/// \param obsv The matrix containing the time series
/// \param days Number of days in the matrix obsv
/// \param periods Number of periods per day
/// \param vars Output array for daily variances
void daily_variances(double *obsv, int days, int periods, double *vars) {
    VSLSSTaskPtr task;
    double *w = nullptr; //weights for VSL routine
    MKL_INT dim, n, xstorage;
    dim = days;
    n = periods;
    xstorage = VSL_SS_MATRIX_STORAGE_ROWS; //we're using C-style row-major matrices
    double *means = static_cast<double *>(mkl_malloc((size_t) days, 64));
    double *raw2m = static_cast<double *>(mkl_malloc((size_t) days, 64));
    std::fill_n(means, days, 0.0);
    std::fill_n(raw2m, days, 0.0);

    int status = vsldSSNewTask(&task, &dim, &n, &xstorage, obsv, w, nullptr);
    if (status != VSL_STATUS_OK)
        throw std::logic_error("MKL issue");
    status = vsldSSEditMoments(task, means, raw2m, nullptr, nullptr, vars, nullptr, nullptr);
    if (status != VSL_STATUS_OK)
        throw std::logic_error("MKL issue");
    status = vsldSSCompute(task, VSL_SS_2C_MOM, VSL_SS_METHOD_1PASS);
    if (status != VSL_STATUS_OK)
        throw std::logic_error("MKL issue");
    mkl_free(means);
    mkl_free(raw2m);
    vslSSDeleteTask(&task);
}

Hello Alfredo,

Ilya_B_Intel — Thu, 19 Jan 2017 15:30:29 GMT

Hello Alfredo,

Clarify question.

Does layout of your data match the following C array?

double obsv[days][periods];

Quote:ILYA B. (Intel) wrote:

Alfredo_L_ — Thu, 19 Jan 2017 15:35:24 GMT

ILYA B. (Intel) wrote:

Hello Alfredo,

Clarify question.

Does layout of your data match the following C array?

double obsv[days][periods];

Correct. My matrix is in row-major format and not Fortran-style column-major format. So for instance, to access the n-th period of day "d" I would do obsv.

In this case code looks ok to

Ilya_B_Intel — Thu, 19 Jan 2017 15:51:09 GMT

In this case code looks ok to me. Do you see similar problems with means or 2nd order raw moments?

Quote:ILYA B. (Intel) wrote:

Alfredo_L_ — Fri, 20 Jan 2017 02:37:57 GMT

ILYA B. (Intel) wrote:

In this case code looks ok to me. Do you see similar problems with means or 2nd order raw moments?

So, I was passing the wrong value for "days" as verified by the debugger...

*however*

Now that I fixed that, I get the correct result ONLY if using "new" to allocate the mean and raw 2nd moment arrays. If I use mkl_malloc I get a segmentation fault. Any ideas?

Do you mean using the code

Gennady_F_Intel — Fri, 20 Jan 2017 04:45:28 GMT

Do you mean using the code like below... You see seg fault when frees buffer for means?

    double *means = static_cast<double *>(mkl_malloc((size_t) days, 64));
    double *raw2m = static_cast<double *>(mkl_malloc((size_t) days, 64));
    .......
    mkl_free(means);
    mkl_free(raw2m);

Ah, yes.

Ilya_B_Intel — Fri, 20 Jan 2017 07:11:38 GMT

Ah, yes.

mkl_malloc allocates data with size in bytes, thus, correct code will be:

mkl_malloc(sizeof(double)*days, 64)

Quote:ILYA B. (Intel) wrote:

Alfredo_L_ — Sat, 21 Jan 2017 18:11:05 GMT

ILYA B. (Intel) wrote:

Ah, yes.

mkl_malloc allocates data with size in bytes, thus, correct code will be:
mkl_malloc(sizeof(double)*days, 64)

Whoops... I can't believe I forgot that. That was indeed the issue.