Prev: Derived type argument to subroutine
Next: cvf66c: building program
From: deltaquattro on 18 Apr 2008 08:08
On 17 Apr, 21:31, nos...(a)see.signature (Richard Maine) wrote:
> Richard Maine <nos...(a)see.signature> wrote:
[..]
>
> Oh, but I forgot to mention on somewhat related method that I've used in
> comparable situations. Pass a single adjustable-size array for such
> auxillary data. I've normally used an array of reals, as much of the
> auxillary data of interest is real, and much of the rest can be easily
> converted to real. It isn't quite as "clean" as the void pointer or
> polymorphic approaches in that you have to pack all the relevant data
> into a suitable array, which then likely needs to be unpacked in the
> called routine. On the other hand, it is perfectly standard f90 (and
> almost standard f77, as long as you special-case the zero-sized case by
> padding it to size 1 because zero-sized arrays aren't allowed in f77).
>
> --
> Richard Maine                    | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle           |  -- Mark Twain

But this requires me to modify the interfaces in quad and in all the
subroutines it calls, doesn't it? Because I now have to pass

func(x,p)

where p is the array of reals (parameters) instead than func. thanks

Best Regards

deltaquattro
From: deltaquattro on 18 Apr 2008 10:01
On 17 Apr, 21:31, nos...(a)see.signature (Richard Maine) wrote:
> Richard Maine <nos...(a)see.signature> wrote:
[..]
>
> Oh, but I forgot to mention on somewhat related method that I've used in
> comparable situations. Pass a single adjustable-size array for such
> auxillary data. I've normally used an array of reals, as much of the
> auxillary data of interest is real, and much of the rest can be easily
> converted to real. It isn't quite as "clean" as the void pointer or
> polymorphic approaches in that you have to pack all the relevant data
> into a suitable array, which then likely needs to be unpacked in the
> called routine. On the other hand, it is perfectly standard f90 (and
> almost standard f77, as long as you special-case the zero-sized case by
> padding it to size 1 because zero-sized arrays aren't allowed in f77).
>
> --
> Richard Maine                    | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle           |  -- Mark Twain

Hi, Richard,

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. 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)

and so on. Thanks,

Best Regards,

deltaquattro



From: Charles Coldwell on 18 Apr 2008 10:03
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes:

> Ron Shepard wrote:
>> deltaquattro <deltaquattro(a)gmail.com> wrote:
>
>>>However, the function to be integrated depends on many parameters, not
>>>only on x. How can I pass it to quad? Is it better to modify the
>>>interface in quad (and all the subroutines called by quad), or to
>>>create a module containing func and all the modules needed by it? Have
>>>you ever met a similar problem? Thanks
>
>> This is the standard interface problem. Do not modify your quad()
>> subroutine. If you do that, then you might as well not even use the
>> dummy subroutine, you could just hardwire the call to your specific
>> code, eliminating all advantages of having a modular reusable quad()
>> routine for numerical integration.
>
> (Snip on the use of COMMON or MODULE to pass static data
> between routines.)
>
> Note, though, that neither COMMON or MODULE allows for reentrant
> calls. If, for example, one wanted to integrate a function inside
> a recursive routine one would have to be very careful.
>
> Even more, some have done double integrals through calling routines
> like quad from inside the called function. The Fortran 66 solution
> to such problems was more than one copy of quad, each with a different
> name. (quad1, quad2, etc.) and more variables in COMMON.
>
> Quoting Richard Maine from a thread on Fortran templates:
>
> "I agree that something like templates can be useful in
> some situations. But note that, depending on details,
> the particular scenario described above can usually be
> handled better in other ways. Typically, all you need
> is an equivalent of a C void pointer, along with the data
> size. Then you can do it all in a single procedure, with
> no need for templates. I've done this exact thing for a
> long time, as I also have Fortran code that passes data
> via sockets. So have other people. This one is done a lot."
>
> 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 ....

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
GPG Key ID: 852E052F
GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F
From: Richard Maine on 18 Apr 2008 11:26
deltaquattro <deltaquattro(a)gmail.com> wrote:

> On 17 Apr, 21:31, nos...(a)see.signature (Richard Maine) wrote:

> > Oh, but I forgot to mention on somewhat related method that I've used in
> > comparable situations. Pass a single adjustable-size array for such
> > auxillary data.

> But this requires me to modify the interfaces in quad and in all the
> subroutines it calls, doesn't it? Because I now have to pass
>
> func(x,p)
>
> where p is the array of reals (parameters) instead than func. thanks

Yes, it does require a modification like that. However, it only requires
the single modification, which then works for a broad category of
functions. You don't have to remodify quad for every particular
function. It is basically just a way of formulating an interface to
"function of x plus some auxilary data" in a way that a single interface
can handle a lot of those kinds of cases. As it turns out, in my case, I
was't modifying old code. I was writing new code, which needed a
simillar flexibility. I wrote the code to have this kind of interface in
the first place.

The approaches with C void pointer and with polymorphism also require a
comparable modification, so this method is very much in the same
category from that perspective. That's why I called it "somewhat
related." See my prior post for (very brief) commentary about
distinctions among them.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 18 Apr 2008 11:41
Charles Coldwell <coldwell(a)gmail.com> wrote:

> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes:

> > 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 ....

Thanks for the terminology pointer. I've heard of thunks, but hadn't
quite figured out what they were about. This gives me at least a hint
(and I'll assume that it might be an approximation to the definition, so
I'll avoid taking it to strictly). So I've been using thinks without
knowing it? Ok.

Reminds me of the epiphiany I had on listening to John Cuthbertson's
talk on a proposal for object oriented features in Fortran about a
decade ago. Prior to that, I had heard lots about object orientation,
and several of its basic concepts, but the examples just didn't "click"
with me. They struck me as contrived and unrelated to anything I did in
Fortran. But John's talk put it in a context that I could relate to.

Suddenly, I realized that I had long been programming using some of
those concepts. I just hadn't abstracted them sufficiently to recognize
them as distinct identifiable concepts. They were just part of the way
that I organized and modularized some of my code. "So that's what
inheritance is about!" It also hadn't occurred to me that a compiler
could actually help instead of getting in the way. And once I saw the
formalism, it helped me see ways to improve my coding in that area, even
before the features were aded to the language. Sort of like fairly
abstract mathematics can sometimes (indeed often) help guide you in the
solution of more concrete problems.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Derived type argument to subroutine
Next: cvf66c: building program