Path: g2news1.google.com!postnews.google.com!b15g2000hsa.googlegroups.com!not-for-mail
From: Arjen Markus <arjen.mar...@wldelft.nl>
Newsgroups: comp.lang.fortran
Subject: Re: Object Oriented Optimization
Date: Fri, 23 Nov 2007 04:10:07 -0800 (PST)
Organization: http://groups.google.com
Lines: 106
Message-ID: <f34ae791-c13e-4048-9bec-39422668c65a@b15g2000hsa.googlegroups.com>
References: <7acab6c3-482e-439c-a41b-cf987dbaf592@d61g2000hsa.googlegroups.com>
NNTP-Posting-Host: 145.9.225.112
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1195819808 15800 127.0.0.1 (23 Nov 2007 12:10:08 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 23 Nov 2007 12:10:08 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: b15g2000hsa.googlegroups.com; posting-host=145.9.225.112; 
	posting-account=A91wAAoAAADgBUxBX6QqsrSD26GLhVp8
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET 
	CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 
	3.0.04506.30),gzip(gfe),gzip(gfe)
Content-Disposition: inline

On 22 nov, 16:03, relaxmike <michael.bau...@gmail.com> wrote:

> One solution would have been to modify the optimization fortran 77
> source
> code, so that the "solve" subroutine takes as an argument the "fonc"
> function. This would have been solved at compile-time to call the
> specific function. A template "solve" subroutine would be this one :
>
>   subroutine f77_solver ( fonc_function )
>     implicit none
>     interface
>         double precision function fonc_function ( x , co , ifonc )
>           implicit none
>           double precision, dimension (:), intent(in) :: x
>           double precision, dimension (:), intent(out) :: co
>           integer, intent(inout) :: ifonc
>          end function fonc_function
>     end interface
>    ! Sometime later :
>    obj = fonc_function ( x , co , ifonc )
>   end subroutine f77_solver
>
> In the client code, one pass the function to the optim_solve
> subroutine :
>
> call optim_solve ( myfonc1 )
> call optim_solve ( myfonc2 )
> etc...
>
> This method must not be confused with the function pointers, as they
> are
> defined in the C language. All this fortran source is defined in a
> static way, which is pre-defined at compile-time. It is not defined at
> run-time, as in can be in C.
>
> The problem is that the "optim_solve" subroutine does not do the
> resolution by itself. Instead, it uses a complex call tree in which
> the
> "fonc" function is called several times by several subroutines at
> different levels. This solution would imply to modify the complex
> fortran 77 source code, which would have been time-consuming and which
> could have created (additional) bugs.
>

If you pass the name of the function around as a dummy argument,
adding it
to each subroutine and function that uses "fonc", I doubt this would
introduce many bugs. It would actually be the simplest solution and
compatible with FORTRAN 77 at that.

But if, indeed, you can not change the source code for this reason or
others, then an implementation with a run-time parameter that selects
the actual function to do the work is the best you can achieve, IMHO.

It is not a bad solution either, even though function pointers like
Reinhold suggests are more elegant.

One alternative, but do not take it too seriously, is to use
something like this:

! Objective function A
module optim_a

contains
double precision fonc( ... )
    ... objective function A
end function

include 'source-for-optimisation.f'

end module

! Objective function B
module optim_b

contains
double precision fonc( ... )
    ... ojective function B
end function

include 'source-for-optimisation.f'

end module

module optimise
    use optim_a, solver_a => solver
    use optim_b, solver_b => solver
end module

Then you can use solver_a to solve the problem with objective function
A
and solver_b to solve it with objective function B.

Drawbacks are of course:
- Your code must use "end subroutine" and "end function" instead of
merely "end"
- The source code must be available to any user who programs another
objective
  function.
- The program becomes larger than necessary due to all the copies of
the
  optimisation code. But that is probably a very minor issue.

Regards,

Arjen