[SciPy-dev] fblas tests

[pearu at scipy.org]

Hi Eric,

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
    obsolete).
    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
    documented somewhere.

 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
features earlier.


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(trans,a,x,y,[m,n,alpha,lda,incx,beta,incy])

gemv current signature:
  y = gemv(alpha,a,x,[beta,y,offx,incx,offy,incy,trans,overwrite_y])

Notes:
 1) in old gemv, arguments m,n,lda are redudant. Why would you want to 
    restore them?

 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.

Regards,
	Pearu