Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Raymond T. <toy...@gm...>]

On 3/13/12 9:45 AM, Akshay Srinivasan wrote:
> On 03/12/2012 12:18 AM, Raymond Toy wrote:
>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>>>
>>>>>>>> It would be nice to be able to detect either mode and
>>>>>>>> have the ffi do the right thing, but I think many lisps
>>>>>>>> do not support structure returns the way gcc is doing
>>>>>>>> it now.
>>>>>>> It returns a struct ? I never could get hold of the 
>>>>>>> documentation for that.
>>>>>> That's my understanding.  And when I look at the
>>>>>> disassembly for a simple Fortran function, it returns the
>>>>>> real and imaginary parts in xmm0 and xmm1 (at least on
>>>>>> OSX).
>>>>> Hmm. Too clumsy and non-portable to support all that, no ?
>>>> It would be good if cffi supported that, but I suspect not.
>>>>>>>> We also have an alternative: Add simple C wrappers
>>>>>>>> that use the f2c-mode return and call the Fortran
>>>>>>>> routine directly.
>>>>>>> CBLAS :) (not the netlib version).
>>> After some more thinking, I vote for adding wrapper subroutine
>>> around zdotu/zdotc in F77. It'll be far too much boring work to
>>> migrate to CBLAS, given that I seem to be able to handle ordering
>>> quite well within lisp itself. There aren't any other complex
>>> returning functions in BLAS, are there ?
>> Let me do a grep....Nope.  Looks like those are the only two.
>>
>> Not quite sure what you're going to do here.  You want to write two
>> C wrapper functions that call zdotu/zdotc correctly, and have the
>> wrapper use the f2c convention?
>>
>> Since we already detect if we need -ff2c, what is the utility for
>> this when matlisp builds its own libraries?  Of course, for atlas,
>> I can see that we would want this if we've determined that atlas is
>> not compatible.  That would be a nice enhancement.
>>> We probably don't need any other f2c features, since most
>>> functions I know only take character arguments instead of string
>>> ones.
>> Fortunately, matlisp is in control of that because I think it is
>> valid fortran to pass in, say, 'Transpose', instead of 'T'.
> I have to flip back on my words. I now think CBLAS is the only way
> forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta
> y) today and really couldn't figure out a way to support row-ordered
> matrices; to do this I will have to use dgemm at best to doing it
> completely in lisp at worst. This is bad because, I can't use gemv to
> support sliced matrices in gemm!
>
> I do think it is worth the trouble now, given that I will be able
> support a lot of matrix-slicey things with access to the order switch
> which is provided by CBLAS functions.
>
Point me to the version of cblas you want to use.  I'll do the work to
get the library built.  I'll leave the interface changes to you (if they
need to be changed).

Ray