Prev: Selecting the first element of a array returned by pack()
Next: size of a derived type containing pointers...
From: Gordon Sande on 30 Mar 2010 08:53 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 30 Mar 2010 09:09 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 30 Mar 2010 09:47 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 30 Mar 2010 10:13 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 30 Mar 2010 11:53
"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 |