[SciPy-dev] fblas tests
pearu at scipy.org
pearu at scipy.org
Sun Apr 14 05:24:14 CDT 2002
On Sat, 13 Apr 2002, eric wrote:
> I was looking over the behavior of the new fblas wrappers and think we should
> make some changes back to how the previous version worked (for reasons explained
> below). The old test suite is pretty extensive and covers many of the various
> calling approaches that can occur. We should definitely try to get all of its
> tests to pass, as they exercise the interface fairly well.
I hope you don't want the old interface back just because to get the old
tests working quickly again. In this particular case, the interface tests
should be changed, not the interfaces, I think.
And the main reason is that the new interfaces are definitely better
(and not just because I wrote them;-).
The new interfaces are better because
a) ... they avoid side-effects (making the intent(inout) feature
In C or Fortran, intent(inout) type of side-effects are widely used
and often the only way to get job done. But this is not the case
for Python. I think that we should adopt the interfaces to Python
style as much as possible as they are mostly used by Python users,
not C or Fortran programmers.
b) ... unless power users request side-effects explicitely (the
overwrite_* = 1 feature) for performance reasons.
Note that the new interfaces do not sacrifice performance or memory
consumption if they are used properly, in fact, they are more optimal
compared to the old interfaces. Of cource, the proper usage must be
c) ... it is safe and simple for casual users to use them and getting
some speed-up compared to not using them at all (scopy is a rather
extreme counter-example that shows interface behaving poorly with
default values but that does not prove that all other interfaces are
poor because these default values are optimal for these other cases.
The old interface could not do all that because f2py did not had required
In CVS log you also mention reverting gemv to the previous interface
style. What do you mean? The task of gemv is
y <- alpha*op(a)*x + beta*y
gemv old signature:
gemv current signature:
y = gemv(alpha,a,x,[beta,y,offx,incx,offy,incy,trans,overwrite_y])
1) in old gemv, arguments m,n,lda are redudant. Why would you want to
2) trans in old gemv expects a character from string 'ntc' while
trans in new gemv expects an int from a list [0,1,2].
I see little difference in using either of them, in the latter case
the interface code is a bit simpler.
3) In new gemv, alpha is required. I agree that it should be made
optional with the default value 1.
4) New gemv has additional offx and offy arguments so that using gemv
from Python covers all possible senarious that one would have when
using gemv directly from C or Fortran.
5) When changing the style here, you should do it also in all
other wrappers of blas1,blas2,blas3,lapack routines. I can ensure you,
it is not a simple replace-str1-with-str2 job.
To sum up, I would suggest the following signature for gemv:
y = gemv(a,x,[alpha,beta,y,offx,incx,offy,incy,trans,overwrite_y])
that in the simplest case, y = gemv(a,x), corresponds to
matrix multiplication of a matrix `a' with a vector `x'.
And gradually using other optional arguments the task of gemv is extended
to more specific cases.
What do you think?
If you have questions about the signatures and the new constructs in them,
I am happy to explain.
More information about the Scipy-dev