[Matrix-SIG] Fortran-to-python-interface-generator: looking for opinions

[Andrew P. Mullhaupt]

> > Oh, OK. Sorry for the misunderstanding. I thought this might be a
> situation
> > in which the Fortran code would result in automatic allocation by the
> > interface. The more things you can stop things from allocating memory so
> you
> > can do it yourself the better your life is.
> >
> No, you didn't misunderstand. If you declare a temporary array, the
> interface does the allocation/deallocation of the array rather than force
> the user to supply it.

If that is in fact the case it's hideous. Of course, it's only hideous for
someone who declares an array as intent(temporary), which does not occur in
any Fortran standard, so it won't affect me.

> If you are calling something in a loop and it doesn't do a lot of work and
a
> bunch of other ifs, it might be important not to do this.

That is exactly the kind of thing that makes extending a good interpreter
important. A lot of times, you don't want to give up the flexibility of the
interpreter, but the interpreter, usually for reasons of design choice,
cannot provide the necessary performance. So you have to call out. When you
call out, it's easiest to wrap up only that part which cannot be provided by
the interpreter - typically an inner loop or other simple performance
critical stretch of code, and only wrap that.

There is a lot of "let's wrap the whole library function" which is a
somewhat different situation, but then you end up with things that do not
really integrate well with the rest of the interpreter that you call.

A perfect example is what to do with Lapack. In truth the thing to do is to
wrap up some parts of the BLAS and then translate the higher level
algorithms into Python. People with Fortran 90 have realized this which is
why Lapack90 is not a translation of Lapack. A good deal of the BLAS can be
junked too, since you no longer need to call _axpy when you can write

    y = beta * y + alpha * matmul(a, x)

in Fortran90, which does the same thing. Note here that this is also a
Fortran90 implementation of _gemv as well.

Note that there is still a performance issue depending on the vendor's
implementation of matmul, but most of them are essentially calling _gemm or
_gemv as the case may be. That _is_ suboptimal, but you can fix that by
writing your own array function mymatmul, etc.

> However, I disagree with the notion that the more things I can do myself
the
> better my life is. (:->.

Let's put it another way. The more often I can stop other people from
calling malloc or using space on the stack the better my life is. Both can
be needlessly harmful ways of using memory, used mainly because most
programmers are unaware of alternatives.

> It is worth noting that nothing says you cannot build two Python
interfaces
> to the same Fortran routine. Just put them in different modules, say
module
> fastbutclumsytouse and module normal.

Actually, it's more like once the fast one is out there "normal" gets left
behind. The reason is that the fast one will be no harder to use, and will
make sense to use more often. It's kind of like why Python is gradually
being preferred to other, more functional interpreters as more people
discover it.

Later,
Andrew Mullhaupt