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

Andrew P. Mullhaupt amullhau@zen-pharaohs.com
Sat, 28 Aug 1999 11:57:42 -0400


From: Pearu Peterson <pearu@ioc.ee>
>
> Travis and others interested in the subject,
>
> I am in a process of rewriting the fortran (in future, also C) to python
> interface generator (f2py.py) and I am looking for opinions on the
> following question:
> How the Python user should see the interfaced fortran routine?
> I will be more specific in below:
>
> ** Consider the interface of fortran (77,90) subroutine `sub`:
> subroutine sub(a,b,c,t)
>   integer intent(in) :: a
>   integer intent(out) :: b
>   integer intent(inout) :: c
>   integer intent(temporary) :: t
> end subroutine sub
> where argument `a` is considered as an input parameter, `b` is a result of
> `sub`, `c` is both input and output parameter, and `t` is a temporary
> (work space) variable (this is quite common in fortran 77 routines when
> work space is required for the routine)

intent(temporary) doesn't appear to be standard f90, f95, or proposed f2k.

I think you actually get better results by _not_ declaring the intent of
such a variable and using the compiler's options for what to do about
automatic variables. This is probably why intent(temporary) isn't standard
and may never be.

> Also, the user must supply the work-space
> variable `t`, though for the end python user it should be irrelevant.

There are _huge_ performance issues surrounding the allocation of
temporaries.

> 2) test.sub(a,b,c) --- this is a kind of reduced form of 1): no work-space
> variable in argument list (the work space is allocated automatically in
> the Py/C API interface).

Bad idea. The programmer wants the choice of allocation method.

> Disadvantage of hiding workspace variables is that they are
> allocated/disallocated in each call to function which is not good for
> performance.

Hideous for performance. Do not do this. A lot of S experience has proven
this. S copies values, no matter how large before passing them to an
external routine, and this puts a high minimum on the amount of work a
routine has to do to overcome before it makes sense to call out. One of the
reasons people have been bailing out of S-plus and Matlab in favor of
Numerical Python is that although Numerical Python has worse indexing and
graphics, it is far friendlier to calling out.

In this case, the workaround would be to wrap the F77 code in another
language to handle the temporary, but then they wouldn't be using the
Fortran-to-Python interface generator.

Plus, there is the "save" attribute.

> 3) b,c=test.sub(a,b) --- here all output of `sub` is returned by the
> functions `sub` as a tuple. The advantage of this approach is that here it
> is much clearer which arguments are input and which output. As an
> disadvantage, the fortran documentation does not hold.

You really have to let the Fortran documentation go. In cases of Fortran 77
(which is now twice obsoleted by F90 and F95) a good deal of the Fortran
documentation relates to complicated subprogram interfaces which no longer
make sense in modern languages. When people write F90 and F95 wrappers to
F77 libraries they document the interface to the wrapper.

> In conclusion, interfaced fortran routines need python specific
> documentation anyway.

Yes.

> Any thoughts, suggestions are very welcome as I need to decide in which
> direction I should proceed.

Keep in mind that Fortran 77 is no longer a standard language. F90 isn't
either. F95 obsoleted them both. Although compiler vendors are still writing
stuff that can compile F77, some features of F77 actually were obsoleted and
more have been deprecated in F95, and the upcoming F2000 standard may change
some more.

The way to proceed is to move toward adding F95 compatibility. The
interfaces are infinitely cleaner, and many of the painful issues you will
have with F77 will go away.

>. All given ways are possible in terms of
> optional flags, but which way should be default?

Since the newer Fortran variants reduce the appearance of temporaries in
interfaces, the default should not take into account storage for
temporaries. People who want automatic allocation of temporaries (rarely
appropriate) should have to ask for it by setting a flag.

Later,
Andrew Mullhaupt