Context Navigation

Changes between Version 3 and Version 4 of DevelopmentIdeas/ModularOptimization

v3	v4
84	84	These seem to be the convention for specifying tolerances. The only problem I have with this is that I would like the option of specifying both absolute and relative tolerances. Perhaps something like `xtol` and `xtol_rel` could be used (absolute tolerances are usually easier to deal with in general).
85	85
	86	== Internal Structure ==
	87	As per some arguments expressed on the [http://article.gmane.org/gmane.comp.python.scientific.devel/5866/match=column+vector mailing list], the internal modules will expect vectors as row vectors. Thus, for a root-finder, the current step x and result f(x) will be row vectors, and the Jacobian will be structured such that f(x+dx) = f(x) + dxJ + ... where represents matrix multiplication.
	88
	89
86	90	== Performance Issues ==
87	91	The modular approach, with great flexibility in choosing and tuning the optimizer works well for extremely costly functions where the overhead of computing the function is the dominant cost and the goal of the optimizer is to minimize the number of function calls. It may not be so suitable for functions that are fast: the overhead of python may become significant and the user might be better off using a routine that is coded directly in C or Fortran (for example, if the optimization occurs in the core of a loop). Hard-coded optimizers, such as already exist in !SciPy should be able to be used with a very similar syntax, however, they will not benefit from the modularity. This is something to keep in mind.