Re: Re: recursion and fsolve

[Paul THOMAS]

Dear All,

I have been testing gfortran, the fortran compiler for gcc3.5.  Unfortunately, gfortran and g95 forked about a year and a half ago and it is the former that is associated with gcc.

 I have mainly been examining the fortran95 aspects but have also taken a look-see at what it does with fortran77.  I have only found one broken bit that affects octave - multiple entry points are not supported.  I rewrote the two subroutines in ranlib that contain ENTRY and compiled every last bit of fortran in octave.  The object modules are OK; those that I have tested work fine.  Unfortunately, the distribution between the libraries is such that an octave build fails with gcc-3.5.0 because of multiple definitions all over the place.  --accept-multiple-definition allows the build to run to the end but octave then falls over in kpathsea, for some reason.  I suspect that the snapshot of g++ I downloaded has regressed some place.  I do not see any interest in investigating further for the present.

However, dynamically loaded functions can be written with gfortran functions and subroutines and they work fine.  I haven't tried a recursive function yet but will give it a try and will report back with the results.

Paul T

> Message du 05/08/04 00:59
> De : "David Bateman"
> A : "John W. Eaton"
> Copie à : "David Bateman" , address@hidden, "Fred Metcalf"
> Objet : Re: recursion and fsolve
> According to John W. Eaton (on 08/04/04):
> > On 4-Aug-2004, David Bateman wrote:
> >
> > | F90 allows recursion. Perhaps we should try to use g95 as the basic
> > | fortran compiler. We could then add a test to configure.in for
> > | whether the fortran compiler accepts recursion and and enable somthing
> > | like the code I suggested...
> >
> > You would also have to look at the Minpack code that is the core of
> > fsolve (hybrd1 and hybrj1) and determine whether it is actually
> > written in a way that would allow a recursive call to work.
> >
> > There are other cases as well, such as daspk, lsode, etc., which I
> > suspect are NOT written with recursion in mind.
>
> What will cause recursion to have problems is if common blocks or save
> statements are used. Even that isn't a guarentee that the code won't work
> as if the variables in the common or save statements are in fact constants
> that are initialized either directly or by a data statement then there
> should be no problem, There are only a couple of potential problems
>
> daspk -> save statement possible problems with ddaspk.f: "SAVE LID, LENID,
> NONNEG", though not clear why these need saving. With a quick look
> it seems they are re-iniitalize on the next entry. Other SAVE
> statements in daspk are initialize as constants with a DATA statement
>
> odepack -> contains common block that are definitely used to pass data between
> subroutines. This will cause problems with recursion. However a
> handy function SRCOM is defined that allows the contents of the
> common block to be saved and restored. So recursion would be possible
> if this call is used prior to a new call to the solver.
>
> odessa -> similar arguments apply as to odepack
>
> So it seems to me that the recursion issues aren't insurmountable.
>
> D.
>
> --
> David Bateman address@hidden
> Motorola CRM +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>
>
>
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web: http://www.octave.org
> How to fund new projects: http://www.octave.org/funding.html
> Subscription information: http://www.octave.org/archive.html
> -------------------------------------------------------------
>
>