Changes between Version 2 and Version 3 of DevelopmentIdeas/ModularOptimization

Timestamp:

04/14/07 14:16:23 (6 years ago)

Author:

mforbes

Comment:

Added directory structure and links to coding standards etc.

DevelopmentIdeas/ModularOptimization

@@ -1 +1 @@
 = Modular Optimization and Root Finding =
-This page contains discussions about a modularized optimization and root finding package.
+This page contains discussions about a modularized optimization and root finding package.  Please make copious changes and add lots of comments and discussions.  We should refactor once it becomes large.  Once ideas are clearly formed, they should be posted to the !SciPy-dev mailing list for comments and suggestions.
+
 [[PageOutline(5,Contents,inline)]] (Why does this macro not work to generate the table of contents?)
+
+== Module Structure ==
+For now I am putting everything in an `moptimize` module for "Modular Optimization".  Hopefully this will be able to replace the scipy.optimize module at somepoint.  Note that coding standards, etc. can be found at the following sites:
+ * [http://www.python.org/dev/peps/pep-0008/ PEP 8] -- Generic python coding standards.
+ * TestingGuidelines -- !NumPy/!SciPy testing guidelines.
+ * [http://www.scipy.org/DocstringStandard SciPy/DocstringStandard] -- !NumPy/!SciPy docstring standards.
+
+{{{
+moptimize 
+    |-- __init__.py : Initialization of package (each subdir should have one)
+    |
+    |-- tests : Testing (each subdir should have one.)
+    |
+    |-- function : Function wrappers, jacobian computations etc.
+    |
+    |-- methods : General optimization methods
+    |
+   ...
+}}}
 == Interface ==
 There should be a very simple interface with default options and methods specified to get code working.  One should then be able to refine the method to suit the particular problem.  Ultimately, it might be nice to provide tools that could try different methods and parameter values to determine the "optimum" solver for a given problem.
@@ -8 +28 @@
 {{{
 #!python
-from optimize import Zeros
+from moptimize import Zeros
 
 def f(x,n):
@@ -23 +43 @@
 {{{
 #!python
-from optimize.methods import Broyden
-from optimize import Zeros
+from moptimize.methods import Broyden
+from moptimize import Zeros
 ...
 method = Broyden(ftol=1e-10,xtol=1e-12)
@@ -32 +52 @@
 {{{
 #!python
-from optimize.method import Broyden
-from optimize.method.criteria import RelativeValueCriterion
+from moptimize.method import Broyden
+from moptimize.method.criteria import RelativeValueCriterion
 
 class MyMethod(Broyden):
@@ -43 +63 @@
 {{{
 #!python
-from optimize.method import Broyden
-from optimize.method.criteria import RelativeValueCriterion
+from moptimize.method import Broyden
+from moptimize.method.criteria import RelativeValueCriterion
 method = Broyden(criterion=RelativeValueCriterion())
 }}}
@@ -57 +77 @@
 It would be nice if the calling conventions for each method were as compatible as possible so that it is easy to swap different methods in an out.
 ==== Arguments ====
-`f` or `func`::
-  Every driver routine will need to specify a function.  Should this argument be called `f` or `func`.  In !SciPy, both are used about the same amount.  (P.S. Why does the definition list Wiki syntax work here?)
-`x0`::
+ `f` or `func`::
+  Every driver routine will need to specify a function.  Should this argument be called `f` or `func`.  In !SciPy, both are used about the same amount.
+ `x0`::
   When an initial argument is supplied, the convention seems to be to use `x0`.
-`ftol`, `xtol`, etc.::
+ `ftol`, `xtol`, etc.::
   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).