🚀 go-pugleaf

In article <C0K4Hx.110@news.cso.uiuc.edu>, I wrote:
|>In the Fortran edition of Numerical Recipes that I have (1989), they
|>have implemented multidimensional minimization routines that
|>can minimize any function, provided that it is called FUNC.
|> [...]
|>Now, I am bothered by this because I need to minimize many
|>different, unrelated functions in the same program.
|> [...]
|>They have done this stupid thing because of an interface routine
|>between multi- and one- dimensional minimization, called LINMIN
|>and minimizing the original function on a line between two points
|>in N-space. This is in turn done by using the ordinary one variable
|>optimization on a function they call F1DIM, which internally calls
|>the user's function, but it cannot gather its name from outside
|>because the argument list must contain only the coordinate and
|>nothing else in order to be used successfully by the lower layers.
|>And of course a function address cannot be placed into a common block.

Many people pointed to me by e-mail that a way to solve the problem
could be:
   to add a function argument to the appropriate numerical
   recipes subroutines and their calls, and then to pass the function to
   the top numerical recipes subroutine as an argument.
I thank you all, but yes, I considered this and this is not an elegant
solution.  If it were, they would have done it already.

I attempt to explain below in more detail what the problem is.
It is quite entangled and technical, so if you are not interested
skip now.

* They have implemented a one-variable minimization package.
   This is well done: it accepts the user's function as an argument.
   The function is called BRENT and goes like that:
      FUNCTION BRENT(....,F,....)
      ...
      code that looks for the minimum of F(x).
      F is the user function, passed from outside.
      ...

* So far, so good. Then they consider multidimensional minimization.
   There are a number of routines using different strategies.
   Many of them require internally to execute one-dimensional
   minimizations.  Typically, along one line connecting two points
   in N-dimensional space.  So they want to do it with the BRENT
   above.  But now, the function to minimize is not the user's function,
   which is N-dimensional.  It's an auxiliary function defined from the
   user function, projecting it onto a line.  They call this function F1DIM,
   and this is the function that will be fed to BRENT.

*  *Here the trouble arises*.  BRENT expects a F(x), NOT a F(x,.....).
   In fact, when you use BRENT to minimize a 1-dimensional function,
   there is no need to have any extra argument.  So, this F1DIM must
   be F1DIM(x) and nothing else.  But this F1DIM projects the user's
   function onto a line, so it needs to know the user's function as well
   as the two extremes of the line.  While the latter can be (and are)
   passed through an internal COMMON, there is nothing you can do
   for the function name.  So they hardcoded the infamous FUNC into it.
   At this point this constraint propagates down to the user interface
   of the N-dimensional routines, which do not have the function name
   in the argument list.

The solutions are:
1) Rewrite the one-dimensional minimization routines, to work on
   an axis embedded in N-space instead of on the x axis.  This
   complicates them considerably.  This is the solution that *they*
   suggest (on page 300 of my 1989 edition). I was hoping someone
   actually did it already ...
2) Modify BRENT so that it takes TWO functions in the argument
   list, the 1-dim one and the N-dim one.  The N-dim one is then
   internally passed as an additional argument to the 1-dim one,
   which should know what do with it.  If your user function is 1-dim,
   you can then still use BRENT and pass a dummy as the second
   function.  You function must have this function in the argument
   list but will do nothing with it.  When BRENT is called by the
   N-dimensional routines, it will receive instead F1DIM and the
   user function.  This is in practice what some of you suggested.
   As you can see, it is not very elegant in this case, but can
   certainly be done.
3) Exploit non-standard POINTER variables that some compilers
   have.  Perhaps, I can pass the function name to F1DIM inside
   a COMMON, which is not allowed by the standard.
4) Do it dirty and write a FUNC that calls my real functions
   by means of an internal switch operated by COMMON or by
   an ENTRY.     

None of them is elegant, but I guess I will pick up one ...
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it

>
>I attempt to explain below in more detail what the problem is.
>It is quite entangled and technical,

That is why some people use C and C++ for numerical work.

In article <1io311INNagr@morrow.stanford.edu> jon@oas.stanford.edu (Jon Claerbout) writes:
>>
>>I attempt to explain below in more detail what the problem is.
>>It is quite entangled and technical,
>
>That is why some people use C and C++ for numerical work.

Right!  We have placed a code recently in the public domain for global
minimization of nonlinear systems.  I've had a few requests for a
FORTRAN version.  For people that would like some FORTRAN version of
C-code, I suggest either trying to interface the two kinds of object
codes or the following procedure which is reported in the NOTES file
of our VFSR code (Very Fast Simulated Reannealing):
========================================================================
From: Lester Ingber <ingber@alumni.caltech.edu>
Date: Tue, 24 Nov 1992 12:22:49 -0500
 
No, sorry I don't have a FORTRAN version.  It's a big world, and lots
of us use C.
 
Back in 1987, I used RATFOR, which then was compiled into FORTRAN,
to use VFSR on a supercomputer.  I don't have that code, but I
mention this because RATFOR is very much like C, and if you find
someone familiar with it they likely could easily rewrite the code
into RATFOR, then compile it into FORTRAN.
 
Lester
 
} Date: Tue, 24 Nov 92 09:11:19 -0800
} 
} Do you have FORTRAN version of your code. 
} Who in the world programs numerics in C ?
 
========================================================================

Here is an update notice for obtaining the code:

******
Update
******
Late updates of vfsr.Z (dropping the version number) and the
review preprint sarev.ps.Z can be gotten via anonymous ftp from
ftp.umiacs.umd.edu in the pub/ingber directory.  The latest version
still is 6.38.

Interactive from UMIACS
     local% ftp ftp.umiacs.umd.edu
     [local% ftp 128.8.120.23]
     Name (ftp.umiacs.umd.edu:your_login_name): anonymous
     Password (ftp.umiacs.umd.edu:anonymous): [type in your_login_name]
     ftp> cd pub/ingber
     ftp> binary
     ftp> get file.ps.Z [get README.file]
     ftp> quit
     local% uncompress file.ps.Z
     local% lpr [-P..] file.ps [to your PostScript laserprinter]

Ftpmail from UMIACS
     local% mail uunet\!decwrl\!ftpmail
     [local% mail uunet_or_your_internet_link\!decwrl\!ftpmail]
     [Subject: Your_own_identifier_tag [e.g., Ingber file]]
     connect 128.8.120.23 anonymous your_login_name
     binary
     uuencode [or btoa]
     chdir /pub/ingber
     get file.ps.Z [get README.file]
     quit
     ^D [or however you send mail]

I still am depositing the latest version in uunet, which can be
accessed via anonymous ftp.
        ftp ftp.uu.net
        cd tmp
        binary
        get vfsr.Z
However, uunet regularly destroys old files in tmp, and so I cannot
guarantee these files always will be there.

If this is not convenient, let me know and I will send you the
code via email.

             Very Fast Simulated Reannealing (VFSR)--v6.35

Interactive from NETLIB
     local% ftp research.att.com
     Name (research.att.com:your_login_name): netlib
     Password: [type in your_login_name or anything]
     ftp> cd opt
     ftp> binary
     ftp> get vfsr.Z
     ftp> quit
     local% uncompress vfsr.Z
     local% sh vfsr

Electronic Mail Request from NETLIB
     local% mail netlib@research.att.com
     [mail netlib@ornl.gov]
     [mail netlib@ukc.ac.uk]
     [mail netlib@nac.no]
     [mail netlib@cs.uow.edu.au]
     send vfsr from opt
     ^D [or however you send mail]

Similarly, you may retrieve the file vfsr from STATLIB by sending
the message
     send vfsr from general
to statlib@lib.stat.cmu.edu.  For interactive retrieval,  ftp  to
lib.stat.cmu.edu, login as user statlib, cd to the directory gen-
eral, and retrieve the file vfsr.

 
Lester
-- 
|| Prof. Lester Ingber                         [10ATT]0-700-L-INGBER ||
|| Lester Ingber Research                        Fax: 0-700-4-INGBER ||
|| P.O. Box 857                           Voice Mail: 1-800-VMAIL-LI ||
|| McLean, VA  22101                EMail: ingber@alumni.caltech.edu ||

In article <63296@mimsy.umd.edu>, ingber@umiacs.umd.edu (Lester Ingber) writes:
|>In article <1io311INNagr@morrow.stanford.edu> jon@oas.stanford.edu (Jon Claerbout) writes:
|>>>
|>>>I attempt to explain below in more detail what the problem is.
|>>>It is quite entangled and technical,
|>>
|>>That is why some people use C and C++ for numerical work.

In my first post I placed a warning:

"If you program in C, don't read this post.  :-)"

Unfortunately, I forgot to put it again in the second one ....

Anyway, seeing no reason to start the N-th net-debate on "C vs Fortran",
I'll briefly summarize why I am doing this project in Fortran in spite
of its obvious and well-known limitations:

* The computational physicists and chemists community, to which I
  belong, overwhelmingly uses Fortran for their work.  Right or wrong,
  this is the state of affairs.  So, if I write in C and pass my code to a colleague,
  chances are that we'll get into troubles.  This is clearly an inertial
  phenomenon, induced by the massive amount of Fortran code we
  have there lying around and which is, of course, recycled for new
  projects.

* Also note, people in this business are often not much computer 
  oriented. I myself admit that ***char gives me some headaches.

* I know C but not enough to write C code with the same speed I write
  Fortran code.  Of course, I can decide to switch and climb the
  C learning curve and then I am back on track.  But I do not feel 
  that it is worth the time investment, since Fortran fulfills my needs
  almost completely.  And if I switch, I would have to work on two
  languages simultaneously, possibly for ten or more years, due to
  maintainance of existing codes.  I will never have time to convert
  many tens of thousand of lines, as well as make sure that many
  gigabytes of data stored as unformatted Fortran files will be read
  as well by the new C codes.

* If Fortran 90 weren't there, i would probably switch to C.  Since 
  it is there, and it solves the known Fortran 77 limitations, I prefer
  to wait for the optimizing compilers that are probably just one year
  apart or so, and live with Fortran 77 for one more year.

* Up to two years ago, switching to C was *NOT POSSIBLE* because 
  of the slowness of the generated code on the main production machines.
  Production machines were, for us, Crays and IBM 3090s.  C code
  was 20-30% slower than Fortran code, which was unacceptable.
  Now, with production being moved to RISC boxes, and C compiler
  writers putting #pragmas to help the optimizers to do their job,
  things are perhaps changing.

* C code can be called from Fortran without troubles on most machines.
  I knew about VSFR and have the code already, and will try it out soon.
  Thanks for putting this code in the public domain.
  The different source language is not a barrier at all: I do not see any 
  reason to ask for a Fortran version, and to say the truth it seems to
  me a rather stupid request.
  I think the two worlds can peacefully coexist.

So: peace!   :-) 
furio
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it

Actually, as an outsider needing minimization support (I am an occasional user
who needs only occasional likelihood maximization), I am quite appalled by the
state of  affairs.   I  often  end up   using grid   searches  when  the  more
sophisticated methods bomb,  often because  of  domain problems.  I have spent
countless days tweaking  the minimization  algorithms;  I'd  rather loose some
computer efficiency to gain user efficiency.

It is time for someone to design  and sell an elegant,  comprehensive function
minimizer, and which switches transparently among minimization algorithms upon
self-determined demand. Isn't this what Artifical Intelligence could be useful
for?  There could be some basic use options:

	1> Use of derivatives
	2> discrete vs. continuous variations
	3> reduce the number of function evaluations for more
		intelligence at the optimizer
	4> Automatic non-linear constraint handling

For example (as  to 3), I  find  it strange that  the  Numerical Recipees Code
tries to maximize uni-dimensionally to  epsilon accuracy even when  taking the
first few steps in the multi-variate optimization.

/ivo welch

In article <1993Jan11.092542.25036@mic.ucla.edu>, iwelch@agsm.ucla.edu
(Ivo Welch) writes:
|>It is time for someone to design  and sell an elegant,  comprehensive function
|>minimizer, and which switches transparently among minimization algorithms upon
|>self-determined demand. Isn't this what Artifical Intelligence could be useful
|>for? 

Curiously enough, researchers at the GE R&D Center developed an
AI-based optimization system called Engineous.  From a 1989 brochure:

  Engineous is a generic software shell that can be applied to the
  design of many different products.  Engineous iterates Computer-Aided
  Engineering (CAE) design programs until desired goals are met, freeing
  the engineer to perform more highly skilled functions.

While Engineous is not a commercial product, the development team may be
reached at:

Dr. Siu Shing Tong
GE Corporate R&D Center
P.O. Box 8
Schenectady, NY 12301

There have been a number of technical papers describing Engineous
in the open literature as well.

Disclaimer:  Dr. Tong doesn't know I'm doing this.

===============================================================================
Ken Meltsner                        | meltsner@crd.ge.com (518) 387-6391