[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea for an IDL numerical toolbox
I'm glad to see I got you fired up.
Stein Vidar Hagfors Haugan wrote:
> One of the most difficult tasks is probably to figure out
> which parameters are input vs output, and thus what kind of
> initialization should be applied. That's why I'm including all
> comments from the fortran subroutine header in the C wrapper
While ftnchek can help in figuring out the type and size of arguments,
ftnchek -makedcls=4 test.f
you correctly point out that deciding which arguments are input vs.
output is tricky. It seems to me there would have to be some simple
(1) There is always an IDL wrapper for the routine being called (the IDL
wrapper calls a C wrapper, which calls the FORTRAN routine).
(2) The IDL wrapper routine checks each of the arguments passed to it
for existence, type, and size:
- If an argument is undefined, it must be output. So the argument is
created, according to the requirements of the particular FORTRAN
- If an argument is defined, it must be input. So the argument is
checked for the correct type and size. If it does not have the correct
type and size, the wrapper program generates an error message.
The description of the NAG Gateway Generator talks about a GUI front end
which allows the user to customize the input and output argument
definitions - we could do one in IDL!
FORTRAN allows subroutines and functions, much like IDL. Functions are
similar to IDL in that they return a variable of a particular type.
Here's a very simple example:
FUNCTION SQUARE( X )
REAL SQUARE, X
SQUARE = X * X
Just like in IDL, the name of the function is treated as a variable.
FORTRAN subroutines and functions can accept variables and function
names as arguments.
> Yep. Using RSI's makefiles as a template by replacing "their"
> file names with yours is a good start, though. To circumvent
> RSI's needlessly strict copyrights on these files (it only
> hurts themselves) one could distribute patches only..?
Well we could always create our own makefiles, and just distribute
compiled libraries. That way users don't have to wait while LAPACK
compiles on their box (they might not have a FORTRAN compiler anyway).
> Volunteers? Who, me? No! ...aaaaaaaargh....I'm losing control
> over my fingers....... Ok - watch this space for an updated
> version of "dlmform" - Version 1 follows below.
I'll give your perl script a go.
Liam E. Gumley
Space Science and Engineering Center, UW-Madison