|
From: Akshay S. <aks...@gm...> - 2012-03-12 04:35:45
|
>> 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? No the wrapper will be in F77, which will be a subroutine working like the f2c version (or the CBLAS version). > > 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. Yes, but If we have the wrapper, we don't have to bother with -ff2c flag anymore, and also be able to use ATLAS at the same time without doing much else. Doing it only when we've determined ATLAS doesn't work the way we want, will involve, I think, changing bits of the function definitions of zdotc/zdotu in src/blas.lisp during the build. >> >> 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'. That might only be because Fortran only reads the first character of the string (?). Akshay |