search

gonum / blas

A BLAS implementation for Go [DEPRECATED]
172 stars 16 forks source link

cgo/daxpy crashes when n == 0 #138

Closed btracey closed 9 years ago

btracey commented 9 years ago

If n == 0, daxpy should just return, not crash with a non-zero increment. I assume this is a problem in more than just Daxpy. I have a test for this (created to fix #137).

kortschak commented 9 years ago

I don't think this is true. The abs(inc) must be >= 1 irrespective of the value of n.

kortschak commented 9 years ago

I can't see the test.

A survey of the fortran shows that they also return when n < 0 or incX == 0 for dasum (we panic in those cases). The issue is whether we follow the behaviour of netlib 100% or not - we currently don't. Arguably, our behaviour is better; inc == 0 is not valid for any case (unless we make the exception for n == 0). If we make the special case for n == 0, then an incorrectly built call does not fail until an, e.g. blas64, value is passed with n != 0. I would prefer the failure to happen the first time an invalid inc is used. It is also more consistent with the level three cases where incX == 0 is explicitly rejected.

This means that the zero values for the blas64 etc types are not valid - I'm OK with that.

btracey commented 9 years ago

SGTM