# cuBLAS gemv incx != 0 restriction

What’s the reason behind the restriction `incx != 0` in `cublas*gemv` functions?

It’s obvious that output vectors must have `inc* != 0` (e.g. `incy` in `cublas*axpy` functions). But for input vectors `incx == 0` can be used for passing vectors with constant values without array allocation.

And, for instance, we can use `cublas*gemv` to calculate sum of matrix rows/columns.

And it’s not obvious what lead to such restrictions, because code like `x + i * incx` is gonna work anyway. May be these restrictions can be lifted without changes in the kernel code?

You might wish to express your desires by filing a bug.

Where are you seeing this restriction?

Under cublasXdgmm, Example 2: if the user wants to perform α × A , then there are two choices, either cublasgeam with *beta=0 and transa == CUBLAS_OP_N or cublasdgmm with incx=0 and x[0]=alpha.

Please provide an example of what you’d like to do, but can’t.

My bad. I mixed up the functions. `dgmm` can’t be used to calculate sum of matrix rows/columns. I was talking about `gemv` (I’ve also fixed the first post). `incx==0` in `cublas*gemv` leads to `CUBLAS_STATUS_INVALID_VALUE`.

We follow the netlib definition of gemv, which also explicitly states that inc{x,y} cannot be 0:

INCX is INTEGER
On entry, INCX specifies the increment for the elements of
X. INCX must not be zero.

INCY is INTEGER
On entry, INCY specifies the increment for the elements of
Y. INCY must not be zero.

1 Like

Got it.

I was curious, because I thought like ‘How this function can be implemented in a way, where `incx==0` will lead to errors?’.

Now I see that it’s more like ‘this restriction is derived from standard BLAS implementation’. Thanks!