From: Gordon Sande on
On 2010-03-30 07:45:25 -0300, Ingo Thies <ingo.thies(a)gmx.de> said:

> Gordon Sande wrote:
>
>>> However, the more efficient DQAG in SLATEC has too complicated
>>> dependencies for a convenient duplication.
>>
>> How so? Any routine called by either copy of DQAC will have completed before it
>> can be called again by either copy.
>
> Hmm, but wouldn't the recursivity of DQAG transfer to all the routines
> called within it, so that I would have to duplicate all of them?
>
>> It is very common for a utility routine
>> to be called from two different places. The dynamic call tree will be a tree
>> but the static call dependencies (loosely but incorrectly the "static
>> call tree")
>> need only be a directed acyclic graph. It would be a lattice except for the
>> requirement on the lowest level being a single item so instead it is a DAG.
>
> Hmm, I am not completely sure that I am understanding this completely.
> Just a hint would be nice: Given the case that I want do do 2D
> quadrature with a single 1D routine without modifying the routine
> itself. What would be the best way for it?

If a utility is called and it does its thing atomicly then it does not matter
whether it was called from a recursive routine or not. The utility will not
be recursive. I must admit I am at a lose to see how that could be confusing.
You seem to think that a recursive caller implies that everything it touchs
is also recursive. If there is implicit, or daisy chained, recursion then
the few routine on the call cycle may need to be recursive but you seem to
be concerned with simple explicit recursion.

You can't do you 2d quadrature as you seem to want with your self
imposed retrictions.

Take DQAC, copy the source and name it DQACx. Again but name it DQACy. In DQACx
change the call to DQAC to read DQACy. No need to copy any of the
utilities called
by DQAC under either if its new aliases.

You complained that you had to duplicate with renaming the entire
dependency tree
of DQAC. You just need to duplicate and rename the top routine.

> Ingo


From: Ingo Thies on
Gordon Sande wrote:

> If a utility is called and it does its thing atomicly then it does not
> matter
> whether it was called from a recursive routine or not. The utility will not
> be recursive. I must admit I am at a lose to see how that could be
> confusing.

Well, DQAG is actually a wrapper for another routine that again is a
wrapper for the actuall quadrature routine. The function to be
integrated, f, is transferred down to this lowest level. Therefore I
would expect that I need to duplicate all routines to which f is passed
since they are again called inside f. All other routines, e.g. error
check, and everything that does not call or refer to f should indeed be OK.

I think it is better to stick to the simple Gauss-Legendre quadrature
from Numerical Recipes (at least for one of the integration levels)
since there is only a single routine that refers to f, and the code is
quite simple (but requires to be initialized to get the coefficients).

> You seem to think that a recursive caller implies that everything it touchs
> is also recursive. If there is implicit, or daisy chained, recursion then

At least everything that refers to or calls the function that itself
calls DQAG.

BTW why it is so complicated for the compiler to deal with recursive
calls? Technically, it should be a minor problem to extend gfortran to
handle such things.

Ingo
From: JB on
On 2010-03-30, Ingo Thies <ingo.thies(a)gmx.de> wrote:
> I think it is better to stick to the simple Gauss-Legendre quadrature
> from Numerical Recipes

Argh..

> BTW why it is so complicated for the compiler to deal with recursive
> calls?

It's not, at least on most current platforms (with some limits such as
stack usage). However, the Fortran standard places a number of
restrictions on standard conforming programs; one of these is that
unless a procedure is marked as recursive, recursion (either direct or
indirect) is not allowed. Hence a standard-conforming compiler is
allowed to compile the code in such a way that it will no longer work
as the naive programmer assumed if a non-recursive procedure is called
recursively. For example, by using static storage for local variables.

> Technically, it should be a minor problem to extend gfortran to
> handle such things.

There is actually an option for this (rtfm for details). However,
IMHO, one part of good programming style is writing standard
conforming programs in the first place rather than trawling through
the compiler manual to search for options that would allow whatever
non-standard construct one has happened to use.


--
JB
From: Gordon Sande on
On 2010-03-30 10:09:18 -0300, Ingo Thies <ingo.thies(a)gmx.de> said:

> Gordon Sande wrote:
>
>> If a utility is called and it does its thing atomicly then it does not matter
>> whether it was called from a recursive routine or not. The utility will not
>> be recursive. I must admit I am at a lose to see how that could be confusing.
>
> Well, DQAG is actually a wrapper for another routine that again is a
> wrapper for the actuall quadrature routine. The function to be
> integrated, f, is transferred down to this lowest level. Therefore I
> would expect that I need to duplicate all routines to which f is passed
> since they are again called inside f. All other routines, e.g. error
> check, and everything that does not call or refer to f should indeed be
> OK.
>
> I think it is better to stick to the simple Gauss-Legendre quadrature
> from Numerical Recipes (at least for one of the integration levels)
> since there is only a single routine that refers to f, and the code is
> quite simple (but requires to be initialized to get the coefficients).

Numerical Recipes does no enjoy the highest reputation amounst those
who operate
at "professional" levels even if it is a good enjoyable read as an
introduction.
Your choice!

>> You seem to think that a recursive caller implies that everything it touchs
>> is also recursive. If there is implicit, or daisy chained, recursion then
>
> At least everything that refers to or calls the function that itself
> calls DQAG.

So DQAC is structured a couple levels deep to provide usable calling sequences
as is sensible and common in good libraries. The concept is the same even if
the techniicalities are slightly more elaborate. No need to duplicate all the
utilities called atomicly which was you initial complaint.

> BTW why it is so complicated for the compiler to deal with recursive
> calls? Technically, it should be a minor problem to extend gfortran to
> handle such things.

See RECURSIVE in the Fortran manual. It is just a bother on cooperative
hardware
if done from the beginnning and just a fair irritant otherwise if planned for.
It was not planned for in 1960 and now many Fortran optimizations have gotten
in the habit of not expecting it. So a new keyword warns the compiler now. It
is often the case that the object code is almost recursive except for a few
slipups. One is too many so the keyword matters as it tells the compiler to
actively get it right. The less fortunate in hardware have to work harder.

The issue is that there is a fair amount of uncooperative hardware around or
in the collective memory including its possible return for specialized
purposes.

> Ingo


From: James Van Buskirk on
"Ingo Thies" <ingo.thies(a)gmx.de> wrote in message
news:81e326Fs4aU1(a)mid.individual.net...

> Hmm, I am not completely sure that I am understanding this completely.
> Just a hint would be nice: Given the case that I want do do 2D quadrature
> with a single 1D routine without modifying the routine itself. What would
> be the best way for it?

The first thing would be to make the routine a recursive internal
procedure of a recursive procedure. In f08 (and ifort, but I can't
recall whether this works in gfortran) the rest follows.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end