Prev: Derived type argument to subroutine
Next: cvf66c: building program
From: glen herrmannsfeldt on 18 Apr 2008 12:15
Charles Coldwell wrote:
(snip, I wrote)

>>In a method related to the one Richard mentions, quad
>>could be written to accept a single variable, either a
>>C void pointer or unlimited polymorphic,
>>and pass this variable onto the called routine.

> That would be called a "thunk" or "continuation" in other
> programming languages ....

The first use of thunk that I knew of was for ALGOL's
call by name argument passing.

http://en.wikipedia.org/wiki/Thunk

It looks close to the third definition, but I would say that
applies more to something like Sun's XDR. Thunk applies
when there is actual code to do some conversion. In this
case, it is just data being passed where both sides are
required to look at it in the same way. One might cheat
and pass integer data in real variables (such as with
EQUIVALENCE or TRANSFER). Any conversions are explicit.

Otherwise, XDR:

http://en.wikipedia.org/wiki/External_Data_Representation

is a common representation with conversions done on both sides.
(For integers I believe it is big-endian binary, for example.)
Data passed between two little-endian machines will be converted
on both ends by XDR calls. Floating point data will also be
converted to a common format even if both ends use the same
format.

-- glen

From: Pierre Asselin on 19 Apr 2008 09:45
deltaquattro <deltaquattro(a)gmail.com> wrote:
> On 17 Apr, 21:31, nos...(a)see.signature (Richard Maine) wrote:
>>
>> [real function func(x,p) where x is the argument and
>> p is a real array encapsulating a bunch of parameters]

> but in this way I have to modify the interface to func, and all the
> calls to func, in quad and in all the subroutines used by quad.

You have to modify all the calls to func that are made from quad.
You have to modify all the calls to quad.

Now if you want to integrate a function F(x), already written,
that gets its parameters from a module or a common block, you
*don't* have to rewrite F. Just wrap it:

new code:
real function F_wrap(x,ignored)
real x
real, dimension(:) ignored
F_wrap= F(x)
return
end

modified code:
program integrate
real, dimension(1):: dummy ! added
...
! call quad(F, a,b) ! before
call quad(F_wrap, a,b, dummy) ! after


> Also,
> I have to pass the parameters down all the subroutines, isn't it? I
> mean

> program integrate

> call quad(func,a,b) --> call quad(func,a,b,p)

Yes, all the calls to quad. If you don't like that you can make
the "p" argument to quad optional. If present, quad can pass it
on to its func call, otherwise quad can pass a dummy array like
the integrate program did above. It is your responsibility to pass
a "p" argument to quad when you integrate a function that expects
one, and to write an F_wrap when you want to integrate a function
that's already written and takes no extra argument.

For what it's worth, the rewrites are never a big deal to me.
They're tedious, but the compiler complains until you've caught
all the loose bits. There's no intricate thinking involved
and there are only so many calls to edit.

--
pa at panix dot com
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Derived type argument to subroutine
Next: cvf66c: building program