U.S. patent application number 11/986253 was filed with the patent office on 2008-03-20 for parser for signomial and geometric programs.
This patent application is currently assigned to Sabio Labs, Inc.. Invention is credited to Stephen Boyd, Dave Colleran, Cesar Crusius, Mar Hershenson, Sunderarjan Mohan, Xiling Shen, Lieven Vandenberghe.
Application Number | 20080072215 11/986253 |
Document ID | / |
Family ID | 38691076 |
Filed Date | 2008-03-20 |
United States Patent
Application |
20080072215 |
Kind Code |
A1 |
Boyd; Stephen ; et
al. |
March 20, 2008 |
Parser for signomial and geometric programs
Abstract
A method and apparatus for parsing signomial and geometric
programs, referred to herein as "the Parser". Signomial and
Geometric programming is a unique class of mathematical problems
that is useful in the study of optimization problems. The Parser is
a program designed to recognize and parse both signomial and
geometric programs such that they may be accepted and solved by
signomial and geometric program solvers. The Parser accepts an
optimization problem from a user in the form of algebraic
expressions. The Parser can then identify the problem as a
signomial program and can further determine if it reduces to a
geometric program. If either a signomial or geometric program
exists, the Parser converts the algebraic expressions to a compact
numeric format that can be accepted by a computer-aided solver. In
the case of a geometric program, the solver may find a global
solution to the optimization problem. However, in the case of
signomial program, the solver may only find a local solution. The
solution found by the solver is routed back to the Parser which
reports it in a user-readable format.
Inventors: |
Boyd; Stephen; (Stanford,
CA) ; Shen; Xiling; (Stanford, CA) ;
Hershenson; Mar; (Palo Alto, CA) ; Vandenberghe;
Lieven; (Santa Monica, CA) ; Crusius; Cesar;
(Palo Alto, CA) ; Colleran; Dave; (San Mateo,
CA) ; Mohan; Sunderarjan; (Mountain View,
CA) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN
1279 OAKMEAD PARKWAY
SUNNYVALE
CA
94085-4040
US
|
Assignee: |
Sabio Labs, Inc.
|
Family ID: |
38691076 |
Appl. No.: |
11/986253 |
Filed: |
November 19, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09752541 |
Dec 29, 2000 |
7299459 |
|
|
11986253 |
Nov 19, 2007 |
|
|
|
60177021 |
Jan 19, 2000 |
|
|
|
Current U.S.
Class: |
717/137 |
Current CPC
Class: |
G06F 8/427 20130101;
G06F 17/11 20130101 |
Class at
Publication: |
717/137 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A computer implemented method, comprising: performing the
following method by reading program code and processing the program
code with a processing unit: accepting a machine readable
description of an optimization problem, said machine readable
description of said optimization including a machine readable
description of an algebraic expression, said algebraic expression
being one of: a signomial inequality; a posynomial inequality; a
monomial equality; parsing said optimization problem with a
computer to create a second machine readable description of said
optimization problem, said second machine readable description of
said optimization problem having a format that is acceptable to a
computer implemented optimization problem solver, said format
representing said algebraic expression as a set of numeric values,
said set of numeric values including a first value that is a
coefficient of said algebraic expression, said set of numeric
values including a second-value that is an exponent of said
algebraic expression.
2. The method of claim 1 where said parsing further comprises
identifying said algebraic expression within said optimization
problem.
3. The method of claim 2 further comprising identifying a second
algebraic expression within said optimization problem after said
algebraic expression is said identified.
3. The method of claim 1 where said parsing further comprises
storing into memory a variable declaration of said optimization
problem.
4. The method of claim 1 wherein said parsing further comprises
substituting a second identified algebraic expression of said
optimization problem into said algebraic expression, said algebraic
expression having a variable that said second algebraic expression
defines.
5. The method of claim 1 wherein said optimization problem has a
minimized objective.
6. The method of claim 1 wherein said optimization problem has a
maximized objective.
7. The method of claim 1 wherein said optimization problem is a
geometric program.
8. The method of claim 1 wherein said optimization problem is a
signomial program.
9. A computer implemented method, comprising: performing the
following method by reading program code and processing the program
code with a processing unit: accepting a machine readable
description of an optimization problem, said machine readable
description of said optimization including a machine readable
description of an algebraic expression, said algebraic expression
having multiple terms, a term of said algebraic expression having
the following form: cx.sub.1.sup.a1x.sub.2.sup.a2 . . .
x.sub.n.sup.an parsing said optimization problem with a computer to
create a second machine readable description of said optimization
problem, said second machine readable description of said
optimization problem having a format that is acceptable to a
computer implemented optimization problem solver, said format
including a first value that is a coefficient of said algebraic
expression and a second value that is an exponent of said algebraic
expression.
10. The method of claim 7 where said parsing further comprises
identifying said algebraic expression within said optimization
problem.
11. The method of claim 8 further comprising identifying a second
algebraic expression within said optimization problem after said
algebraic expression is said identified.
12. The method of claim 7 where said parsing further comprises
storing into memory a variable declaration of said optimization
problem.
13. The method of claim 7 wherein said parsing further comprises
substituting a second identified algebraic expression of said
optimization problem into said algebraic expression, said algebraic
expression having a variable that said second algebraic expression
defines.
14. The method of claim 7 wherein said optimization problem has a
minimized objective.
15. The method of claim 7 wherein said optimization problem has a
maximized objective.
16. The method of claim 9 wherein said optimization problem is a
geometric program.
17. The method of claim 9 wherein said optimization problem is a
signomial program.
Description
FIELD OF THE INVENTION
[0001] The invention relates to the field of mathematical
optimization, particularly the recognition and parsing of signomial
and geometric programs such that they may be accepted and solved by
signomial and geometric program solvers.
BACKGROUND AND PRIOR ART
[0002] Geometric programming is a unique class of mathematical
problems that is useful in the study of optimization problems. The
theory of Geometric Programming was initially developed over three
decades ago and culminated in a publication by R. J. Duffin, E. L.
Peterson and C. M. Zener (Geometric Programming, John Wiley &
Sons, 1967). This publication describes a Geometric Program (GP) as
an optimization problem having an objective function and a set of
constraints which all must meet certain mathematical criteria.
Perhaps the most important property of GPs is that they can be
solved, with great efficiently, and globally, using recently
developed interior-point methods.
[0003] Since the impact of GPs can be seen in fields of engineering
design, manufacturing, economics, statistics, and chemical
equilibrium, it is apparent that the ability to solve GPs can have
many benefits. A very simple GP can be solved by hand, but more
complex GPs effectively must be solved with the aid of computer
programs. For example, a very complex GP that may be used to
describe a circuit design problem may have hundreds of optimization
variables and thousands of constraints. The mathematical operations
needed to solve a GP of this magnitude would be too cumbersome to
perform by hand; therefore, optimization programs are needed to
solve most GPs.
[0004] Several optimization programs have been written that can
solve GPs. For example, two popular GP solvers are MOSEK.TM.
(product of EKA Consulting Aps, Vissenbjerg, Denmark) and COPL_GP
(developed by members of the Computational Optimization Laboratory,
Department of Management Science, University of Iowa). However,
these programs require that GPs be parsed and represented in a
particular compact numeric format that can be read and, if
possible, globally solved by a solver program. Parsing a GP into
this particular format typically requires extensive labor by one or
more people. Moreover, if this compact numeric format were
generated by hand, any changes to the functions, variables or
coefficients contained in the GP would require extensive labor to
modify the problem. Thus, it would be advantageous to have a parser
program that can automatically convert a geometric program to this
compact numeric format.
[0005] Software tools exist that will parse and solve a wide
variety of optimization problems. Two well known examples of such
tools are the software packages AMPL.TM. (product of the Bell
Laboratories Division of Lucent Technologies Inc., Murray Hill,
N.J.) and GAMS.TM. (product of the GAMS Development Corporation,
Washington, D.C.) which incorporate a variety of backend solvers.
These packages allow a user to input one of a variety of
optimization problems, in a standard algebraic format, and then
will parse the problem into a format that is readable by a solver.
However, these programs are very general in function and lack the
sophistication required to identify and/or parse a GP. Some parsers
have been developed to specifically parse specific classes of
optimization problems. For example, a program called SDPSOL
(developed by Dr. Stephen Boyd and members of his group at the
Information Systems Laboratory, Department of Electrical
Engineering, Stanford University) is a parser/solver program
specifically designed for semidefinite programming. Similarly,
there is a need for a parser program that can identify and parse a
GP because current optimization software tools lack the ability to
accomplish these tasks.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The invention may best be understood by referring to the
following description and accompanying drawings that are used to
illustrate embodiments of the invention. In the drawings:
[0007] FIG. 1 is a flow diagram showing the operations performed by
certain exemplary embodiments of the invention.
[0008] FIG. 2A is a first half of a flow diagram showing a more
detailed look at the operations performed in block 130 of FIG. 1
according to one embodiment of the invention
[0009] FIG. 2B is a second half of a flow diagram showing a more
detailed look at the operations performed in block 130 of FIG. 1
according to one embodiment of the invention.
[0010] FIG. 3 is a flow diagram showing a more detailed look at the
operations performed in block 130 of FIG. 1 for an alternate
embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0011] In the following description, numerous specific details are
set forth to provide a thorough understanding of the invention.
However, it is understood that the invention may be practiced
without these specific details. In other instances, well-known
mathematical concepts, structures and techniques have not been
shown in detail in order not to obscure the invention.
Background on Geometric Programming
[0012] In order to better understand the scope of the invention, it
is important to introduce some mathematical terminology associated
with geometric programming. For example, monomials, posynomials,
and signomials are three types of mathematical functions found in
geometric programs. These functions are defined below, beginning
with a monomial.
[0013] Let x.sub.1, . . . , 2 denote n real positive variables. A
function f: R.sup.n R of the form
f(x)=cx.sub.1.sup.a.sup.1x.sub.2.sup.a.sup.2 . . .
x.sub.n.sup.a.sup.n, where c>0 and a.sub.i.epsilon.R, is called
a monomial function. Note that exponents can be any real numbers,
including fractional or negative. We can refer to a monomial
function more informally as just a monomial (of the variables
x.sub.1, . . . , x.sub.n). We refer to the constant c as the
coefficient of the monomial. As an example,
2.3x.sub.1.sup.2x.sub.2.sup.-0.15 is a monomial of the variables
x.sub.1 and x.sub.2, with coefficient 2.3 and x.sub.2-exponent
-0.15.
[0014] Any positive constant is a monomial, as is any variable.
Monomials are closed under multiplication and division: if f and g
are both monomials then so are f.times.g and f/g. (This includes
scaling by any positive constant.) A monomial raised to any power
is also a monomial:
f(x).sup..gamma.=(cx.sub.1.sup.a.sup.1x.sub.2.sup.a.sup.2 . . .
x.sub.n.sup.a.sup.n).sup..gamma.=c.sup..gamma.x.sub.1.sup..gamma.a.sup.1x-
.sub.2.sup..gamma.a.sup.2 . . . x.sub.n.sup..gamma.a.sup.n. In
addition, a sum of zero or more monomials, i.e., a function of the
form f .function. ( x ) = k = 1 K .times. c k .times. x 1 a 1
.times. k .times. x 2 a 2 .times. k .times. .times. .times. .times.
x n a n .times. k , ##EQU1## where c.sub.j.gtoreq.0, is called a
posynomial function or, more simply, a posynomial (with K
terms).
[0015] Any monomial is also a posynomial. Posynomials are closed
under addition, multiplication, and nonnegative scaling.
Posynomials can be divided by monomials (with the result also a
posynomial): If f is a posynomial and g is a monomial, then f/g is
a posynomial. If .gamma. is a nonnegative integer and f is a
posynomial, then f' always makes sense and is a posynomial (since
it is the product of .gamma. posynomials).
[0016] A generalization of a posynomial will also be encountered,
in which the coefficients are allowed to be negative. A signomial
is a function with the same form as a posynomial, as defined above,
where the coefficients c.sub.j are allowed to be negative.
Signomials include as special cases posynomials (and therefore also
monomials) and (positive or negative) constants. Signomials are
closed under addition, subtraction, and multiplication. A signomial
can be divided by a signomial that is nonzero and has only one term
(i.e., a monomial, or the negative of a monomial). A signomial
raised to any nonnegative integer power is also a signomial.
[0017] Any signomial can be expressed as the difference of two
posynomials, by collecting together the terms with positive
coefficients, and also the terms with negative coefficients. We
will use the notation f.sub.+ to denote the posynomial part of the
signomial f, and f.sub.- to denote the negative posynomial part of
f, so f=f.sub.+-f.sub.- where f.sub.+ and f.sub.- are both
posynomials.
[0018] The following are some examples of monomials, posynomials
and signomials. Suppose x, y, and z are (positive) variables. The
functions 2x, 0.23, 2z {square root over
(x/y,)}3x.sup.2y.sup.-0.12z are monomials (hence, also posynomials
and signomials). The functions 0, 0.23+x/y, 2(1+xy).sup.3, 2x+3y+2z
are posynomials (hence, also signomials) but not monomials. The
functions -2.2, -x/y, 2(1-xy).sup.3, 2x+3y-2z are signomials but
not posynomials. Finally, the functions (x+y).sup.-1,
2(1+xy).sup.3.1, 1+log z are not signomials.
[0019] Monomials, posynomials, and signomials are all functions
that can be found in a geometric program ("GP"). A standard form GP
is an optimization problem of the form show in Equation Set 1.
minimize f 0 .function. ( x ) subject .times. .times. to f i
.function. ( x ) .times. .times. 1 , i = 1 , .times. , m , h i
.function. ( x ) = 1 , i = 1 , .times. , p Equation .times. .times.
Set .times. .times. 1 ##EQU2## In Equation Set 1 f.sub.i are
posynomial functions, h.sub.i are monomials, and x.sub.i are the
optimization variables. (There is an implicit constraint that the
variables are positive, i.e., x.sub.i>0). In a GP in standard
form the objective f.sub.0 must be posynomial and it must be
minimized; in addition, the equality constraints can only have the
form of a monomial equal to one, and the inequality constraints can
only have the form of a posynomial less than or equal to one. A
solution to a GP is found when a minimum or maximum value of the
objective is calculated from values of the optimization variables
meeting the conditions set by the constraints. What makes the use
of GPs powerful is that they can be solved globally, with great
efficiency.
[0020] A generalization of a geometric program is a signomial
program ("SGP"), which has the form shown in Equation Set 2.
minimize f .function. ( x ) subject .times. .times. to a i
.function. ( x ) .times. b i .function. ( x ) , i = 1 , .times. , m
, c i .function. ( x ) = d i .function. ( x ) , i = 1 , .times. , p
Equation .times. .times. Set .times. .times. 2 ##EQU3## In Equation
Set 2 a.sub.i, b.sub.i and d.sub.i are all signomial functions and
x.sub.i are the optimization variables. (As in GP, there is an
implicit constraint that the variables are positive, i.e.,
x.sub.i>0.) It is also required that the objective f be a
posynomial.
[0021] Note the differences between the standard form GP (Equation
Set 1) and the SGP (Equation Set 2): [0022] In an SGP, the
constraint functions can be arbitrary signomials; in a GP they must
be posynomials and monomials, respectively. [0023] In an SGP, the
righthand side of the inequalities and equalities can also be
signomials; in a GP, the righthand side of the inequalities and
equalities is one. From a computational point of view, there is a
significant difference between a GP and an SGP. While the globally
optimal solution of a GP can always be found efficiently (e.g., an
absolute maximum, only a locally optimal solution of an SGP can be
computed efficiently. Although it is possible to compute the
globally optimal solution of an SGP, this can require prohibitive
computation, even for relatively small problems.
[0024] Furthermore, it can be seen that a standard form GP with
posynomial objective function f.sub.0, posynomial constraint
functions f.sub.1 . . . , f.sub.m, and monomial equality functions
g.sub.1, . . . , g.sub.p, is already in SGP form, with
b.sub.i=c.sub.i=1 (which are signomials). Thus any standard form GP
is also an SGP.
[0025] For several purposes of the invention it is convenient to
transform a SGP into a special form in which the left and
right-hand sides of each constraint are posynomials. This can be
done by first expressing the inequality a.sub.i.ltoreq.b.sub.i in
Equation Set 2 as a.sub.i-b.sub.i.ltoreq.0, and then splitting it
into its posynomial and negative posynomial parts, and expressing
it as (a.sub.i-b.sub.i).sub.+.ltoreq.(a.sub.i-b.sub.i).sub.-. The
same can be done to each equality constraint, and examples of
splitting a signomial into its posynomial and negative posynomial
are shown in Examples 1 and 2. (2x+3y-2z).sub.+=2x+3y,
(2x+3y-2z).sub.-=2z Example 1
(2(1-xy).sup.3).sub.+=2+6x.sup.2y.sup.2,
(2(1-xy).sup.3).sub.-=6xy+2x.sup.3y.sup.3 Example 2
[0026] Ultimately, the SGP in Equation Set 2 can be rewritten as
shown in Equation Set 3 below. minimize f .function. ( x ) subject
.times. .times. to ( a i .function. ( x ) - b i .function. ( x ) )
+ i = l , .times. , m , ( a i .function. ( x ) - b i .function. ( x
) ) - ( c i .function. ( x ) - d i .function. ( x ) ) += i = l ,
.times. , p ( c i .function. ( x ) - d i .function. ( x ) ) -
Equation .times. .times. Set .times. .times. 3 ##EQU4## In this
form of the SGP the objective and each of the left and right-hand
sides of each constraint is a posynomial function. For this reason
we refer to the program in Equation Set 3 as the posynomial form of
the SGP.
One Embodiment of the Invention
[0027] FIG. 1 illustrates the operations that are performed by
certain exemplary embodiments of the invention, hereinafter "the
Parser," in order to parse an optimization problem such as a
signomial or geometric program. These operations are contained in
box 100. First a user 110 must input a source file 115 that
describes an optimization problem (e.g., an SGP), as shown in block
120. This process of inputting source file 115 can occur via a user
interface which may include a computer operating system, a web
browser, or other user-computer interfaces. Each line of source
file 115 will include one of the following: 1) an optimization
variable declaration, 2) an internal variable assignment or 3) an
algebraic expression. In addition, the algebraic expressions
contained in the source file will collectively comprise: 1) an
objective function, 2) one or more equality constraints and 3) one
or more inequality constraints.
[0028] A very simple example of an optimization program, in this
case a SGP, is shown in Equation Set 4: minimize x 1 .times. x 3 +
x 1 .times. x 2 / x 3 subject .times. .times. to x 1 .times. x 3 -
0.3 + 1 .times. .times. x 3 - x 1 .times. x 2 / x 3 .times. x 2 1.2
, x 2 .times. 30 , x 1 - 4.1 / x 2 .times. x 3 = 0 , Equation
.times. .times. Set .times. .times. 4 ##EQU5## This problem can be
specified in the Parser language as shown in Equation Set 5:
variable .times. .times. x .times. .times. 1 , x .times. .times. 2
, x .times. .times. 3 ; .times. .times. minimize .times. .times. x
.times. .times. 1 * x .times. .times. 3 + x .times. .times. 1 * x
.times. .times. 2 / x .times. .times. 3 ; .times. .times. x .times.
.times. 1 * 2 ^ - 0.3 + 1 < x .times. .times. 3 - x .times.
.times. 2 ^ .times. 1.2 ; .times. .times. x .times. .times. 2 <
30 ; .times. .times. x .times. .times. 1 - 4.1 .times. .times. sqrt
.function. ( x .times. .times. 2 / x .times. .times. 3 ) = 0 ;
Equation .times. .times. Set .times. .times. 5 ##EQU6##
[0029] There is a very close similarity between this the Parser
source file (i.e., Equation Set 5) and the mathematical description
shown in Equation Set 4. In the first line, x1, x2 and x3 are
declared to be optimization variables, and in the second line the
objective is defined by an algebraic expression that includes a set
of mathematical terms. For the purposes of the invention an
algebraic expression is defined as a set of one or more variables
and, in most problems, constants joined together by mathematical
operators and functions including by not limited to addition,
subtraction, multiplication and division. In addition, a
mathematical term is defined as a subset of an algebraic expression
that can independently form a mathematical function. Lines three
and four of Equation Set 5 specify inequality constraints, and the
last line specifies an equality constraint. Constraints are also
defined by algebraic expressions which each include a set of
mathematical terms.
[0030] At block 130 the Parser will determine if the algebraic
expressions contained in the source file 115 form a GP. This
provides the advantage of knowing that a global (e.g., an absolute
minimum) solution to the optimization problem will be found as
opposed to a local (e.g., a relative minimum) solution. Block 130
is illustrated in more detail in FIGS. 2A and 2B and will soon be
discussed.
[0031] If block 130 is successful then at block 150 the Parser will
continue to parse the GP by converting it from its algebraic format
(e.g., Equation Set 5) to a compact numeric format ("CNF"), thus
creating CNF file 175. Otherwise, if block 130 is unsuccessful then
an error message will be reported to user 110, indicating the type
of error and at which line of source file 115 the error occurred.
Types of errors include but are not limited to syntax and
mathematical infeasibility. It will be understood that errors may
be immediately reported to user 110, or the Parser can wait until
all the lines of source file 115 are read and report the total
number of errors found and their locations in source file 115. If
an error message is reported then user 110 may make corrections and
re-execute the Parser program.
[0032] Alternatively, the Parser may report the error stating that
the optimization problem cannot be reduced to a GP in standard
form, but that it still meets the mathematical criteria of a SGP.
In this case user 110 will have the option to successfully
re-execute the Parser program in order to create CNF file 175 and
have an external SGP solver attempt to find a local solution.
However, it would be advantageous for user 110 to modify source
file 115 such that the optimization problem may be reduced and
parsed as a GP instead of SGP. This modification will provide a GP
solver the opportunity to find a global solution to the
optimization problem.
[0033] The conversion that occurs at block 150 is accomplished when
the Parser successfully coverts a GP or SGP from its algebraic
format to a CNF. The CNF is a format that is specific to the type
of solver program that it is being using in conjunction with the
Parser. The CNF is comprised of a set of matrices that represent
the variables, coefficients, and exponents of the algebraic
equations that form a GP or SPG. These matrices are created when
the Parser converts each individual algebraic equation, as
expressed in the GP or SGP, into a set of numeric values that
represent the equations' optimization variables by their types,
coefficients, and exponents. These numeric values are further
arranged into a group of matrices that are stored in CNF file 175.
These matrices are stored in such a manner that a solver program
will be capable of reading CNF file 175 and recognizing a specific
SGP or GP that it will attempt to solve.
[0034] Once CNF file 175 is created, the Parser will route it to
solver 160. Solver 160 is capable of globally solving GPs and can
process CNF file 175. For example, solvers MOSEK.TM. and COPL_GP
are will know in the art and will accept CNF file 175 and are
capable of solving both SGPs and GPs using interior point methods.
All GP solvers require that a GP be inputted in a unique format;
hence CNF file 175 produced by the Parser. Currently, without the
aid of the Parser, this unique format file must be generated by
hand. It can be appreciated that the Parser can automatically
generate CNF file 175 as described earlier.
[0035] FIGS. 2A and 2B show a more detailed look at the operations
included in block 130 of FIG. 1 according to one embodiment of the
invention. From block 120 the Parser begins processing source file
115 to find the algebraic expressions, as shown is block 200. If a
line contains a variable declaration, then the Parser stores the
variables into memory, or if a line contains an internal variable
assignment, then the Parser stores the internal variable and its
assigned expression into memory. From block 200 the Parser will
read a new algebraic expression at block 205. At block 210 the
Parser recognizes, in the algebraic expression, any internal
variables representing a previously assigned expression and, if
necessary, makes one or more substitutions. The Parser will then
advance to block 220 where it attempts to convert all the
mathematical terms in the algebraic expression to signomial
functions, thus creating a signomial expression. This conversion,
if successful, allows for the performing of block 250 with great
efficiency as described later.
[0036] If block 220 is successful, as determined by block 230, then
the Parser will advance to block 240. Otherwise, if block 220 is
unsuccessful then an error message will be reported to user 110,
indicating the type of error and at which line of source file 115
the error occurred. Types of errors include but are not limited to
syntax and mathematical infeasibility. It is understood that errors
may be immediately reported to user 110, or the Parser can wait
until all the lines of source file 115 are read and report the
total number of errors found and their locations in the 115. If an
error message is reported then user 110 may make corrections and
re-execute the Parser program.
[0037] At block 240 the Parser will attempt to simplify the
signomial expression created in block 220. For example,
simplification can occur when a combination of two identical
signomial functions of opposite signs are mathematically cancelled.
The Parser will then advanced to block 250 where it will attempt to
reduce the signomial expression to one of the following: 1) a
posynomial objective, 2) a posynomial inequality, or 3) a monomial
equality. Specifically, a posynomial inequality shall be a
posynomial function being less than or equal to one, and a monomial
equality shall be monomial function being equal to one. The fact
that block 220 generated a signomial expression allows the Parser
to apply a test that will determine if the reduction of the
constraints in block 250 is successful.
[0038] Not all signomial constraints can be reduced to either a
posynomial or monomial, but after block 220 it is straightforward
to make this determination at block 250. At block 250 the Parser
will first rewrite the signomial expression in its posynomial form.
This process is shown in Equation Set 3 and can be applied to
either an inequality or an equality, for example,
(a.sub.i(x)-b.sub.i(x)).sub.+(a.sub.i(x).sub.-b.sub.i(x)).sub.-i=1,
. . . , m, or
(c.sub.i(x)-d.sub.i(x)).sub.+=(c.sub.i(x).sub.-d.sub.i(x)).sub.-
-i=1, . . . , p. The Parser will then determine if the right-hand
side of the posynomial form constraint, i.e.,
(a.sub.i(x)-b.sub.i(x)).sub.-, i=1, . . . , m or
(c.sub.i(x)-d.sub.i(x)).sub.-, i=1, . . . , m is a monomial. In
addition, in the case of the equality the Parser will also
determine if the left-hand side is a monomial. Ultimately, if block
250 is successful a constraint can be expressed as either
(a.sub.i(x)-b.sub.i(x)).sub.+/(a.sub.i(x)-b.sub.i(x)).sub.-1 i=1, .
. . , m, or
(c.sub.i(x)-d.sub.i(x)).sub.+/(c.sub.i(x)-d.sub.i(x)).sub.-=1 i=1,
. . . , p. This notation reflects the notation shown in Equation
Set 1, which represents a standard form GP. Therefore, with some
abuse of notation, any SGP which can be transformed into a standard
form GP in this way can be referred to as a geometric program.
[0039] As a simple example, consider the SGP: minimize
x.sub.ix.sub.3+x.sub.ix.sub.2/x.sub.3 subject to
x.sub.1x.sub.2.sup.-0.3+1 x.sub.3-x.sub.2.sup.1.2,
x.sub.2.ltoreq.30, x.sub.1-4.1 {square root over
(x.sub.2/x.sub.3)}=0, which evidently is not a standard form GP.
Therefore, the SGP is put in posynomial SGP form: minimize
x.sub.ix.sub.3+x.sub.ix.sub.2/x.sub.3 subject to
x.sub.1x.sub.2.sup.-0.3+1+x.sub.2.sup.1.2.ltoreq.x.sub.3, x.sub.2
30, x.sub.1=4.1 {square root over (x.sub.2/x.sub.3)}. Since each
right-hand side is a monomial, we can transform the problem to a
standard form GP by dividing by the right-hand sides: minimize
x.sub.ix.sub.3+x.sub.ix.sub.2/x.sub.3 subject to
x.sub.1x.sub.2.sup.-0.3x.sub.3.sup.-1+x.sub.3.sup.-1+x.sub.2.sup.1.2x.sub-
.3.sup.-1+x.sub.2.sup.1.2x.sub.3.sup.-1 1, (1/30)x.sub.2 1,
(1/4.1)x.sub.1x.sub.2.sup.-0.5x.sub.3.sup.0.5=1.
[0040] To continue the example, let us consider a closely related
problem, with the sign of the constant 1 appearing in the first
inequality constraint changed: minimize
x.sub.ix.sub.3+x.sub.ix.sub.2/x.sub.3 subject to
x.sub.1x.sub.2.sup.-0.3-1 x.sub.3-x.sub.2.sup.1.2, x.sub.2 30,
x.sub.1-4.1 {square root over (x.sub.2/x.sub.3)}=0. This problem
cannot be transformed to a standard form GP, since the right-hand
side of the first inequality constraint, in posynomial SGP form,
now has two monomial terms. The practical consequence is that the
ability to solve the problem globally is lost; only a local minimum
can be found.
[0041] It is also understood that the Parser can parse signomial
and geometric programs having objectives that are either minimized
or maximized. In most cases and in the examples provided herein,
objectives are minimized. However, a user may request that the
Parser maximize the objective, and, therefore, the objective may be
maximized by the Parser by finding the minimum of it's inverse. For
example, the minimum of objective X can be expressed by the Parser
as the maximum of the objective 1/X; and similarly, the maximum of
objective Y can be expressed by the parser as the minimum of
objective 1/Y.
[0042] Ultimately, if block 250 is successful, as determined by
block 260, and all lines of source file 115 have been read, as
determined by block 270, then the Parser will advance to block 150
of FIG. 1. If the last line has not been read, as determined by
block 270, the Parser will repeat the flows of FIGS. 2A and 2B
until all the lines of source file 115 have been read and no errors
have been encountered. Once the Parser has reached block 150 it is
clear that optimization problem inputted in block 120 is in fact a
GP. Subsequently, at block 150, the Parser further converts the GP
to a CNF, thus converting source file 115 to CNF file 155. CNF file
155 can be inputted to solver 160, as discussed earlier, and solver
160 will attempt to find a global solution to the GP.
[0043] If solver 160 calculates a solution to the GP represented by
CNF file 155, then it creates solution file 165, containing a
numeric solution to the objective and corresponding numeric
solutions to the optimization variables. Otherwise, an error will
be reported in solution file 165. Solution file 165 is routed back
to the Parser where it is translated into a user-readable format
(block 170) and expressed in output file 175. An example of output
file 175 is shown in Example 3 which displays the global minimum
solution to the objective function and the corresponding values of
the optimization variables (x.sub.1, x.sub.2 and x.sub.3), as
declared in source file 115.
Example 3
[0044] problem=GP
[0045] status=optimal
[0046] obj_value=1606.14
[0047] x1=29.999680001707
[0048] x2=37.433796562618
[0049] x3=0.69919504957707
Alternate Embodiment of the Invention
[0050] One embodiment of the invention exists which implements the
identical blocks shown in FIG. 1 with the exception of block 130.
FIG. 3 shows a more detailed look at the operations included in
block 130 for an alternate embodiment. From block 120 the Parser
begins processing source file 115 to locate algebraic expressions,
as shown is block 300. If a line contains a variable declaration,
then the Parser stores the variables into memory, or if a line
contains an internal variable assignment, then GBLAB stores the
internal variable and its assigned expression into memory. From
block 300 the Parser will read a new algebraic expression at block
310. At block 320 the Parser recognizes, in the algebraic
expression, any internal variables representing a previously
assigned expression and, if necessary, makes one or more
substitutions. The Parser will then advance to block 330 where it
attempts to combine the mathematical terms such that the algebraic
expression reduces to one of the following: 1) a posynomial
objective, 2) a posynomial inequality, or 3) a monomial equality.
Specifically, a posynomial inequality shall be a posynomial
function being less than or equal to one, and a monomial equality
shall be monomial function being equal to one.
[0051] Combining the mathematical terms at block 330 shall first
involve the Parser identifying each mathematical term as a
signomial, posynomial or monomial. Then the Parser will determine
if the operators and functions that relate the mathematical terms
allow the algebraic expression to be reduced as described above.
This process is more intensive than that of the preferred
embodiment because the mathematical terms are not all treated as
signomials. Rather, the mathematical terms are treated as separate
classes of terms (e.g., posynomials and monomials); therefore, the
set of mathematical rules that apply to combining the terms and
reducing the algebraic expression is more expansive. Moreover, when
compared to the embodiment described with reference to FIGS. 2A-B,
the cancellation of mathematical terms will not be as obvious to
the Parser since the terms are not all treated as signomials.
[0052] Ultimately, if block 330 is successful, as determined by
block 340, and all lines of source file 115 have been read, as
determined by block 350, then the Parser will advance to block 150
of FIG. 1. If the last line has not been processed, as determined
by block 350, the Parser will repeat the blocks of FIG. 3 until all
the lines of source file 115 have been processed and no errors have
been encountered. Once block 150 is reached, the Parser will
proceed through the final blocks of FIG. 1 in a manner identical to
that of the embodiment of FIG. 2A-B. Once the Parser has reached
block 150 it is clear that optimization problem inputted in block
120 is in fact a GP.
[0053] Otherwise, if block 330 is unsuccessful then an error
message will be reported to user 110, indicating the type of error
and at which line of source file 115 the error occurred. Types of
errors include but are not limited to syntax and mathematical
infeasibility. It will be understood that errors may be immediately
reported to user 110, or the Parser can wait until all the lines of
source file 115 are read and report the total number of errors
found and their locations in the 115. If an error message is
reported then user 110 may make corrections and re-execute the
Parser program.
[0054] Alternatively, the Parser may report the error stating that
the optimization problem cannot be reduced to a GP in standard
form, but that it still meets the mathematical criteria of a SGP.
In this case user 110 will have the option to successfully
re-execute the Parser program in order to create CNF file 175 and
have an external SGP solver attempt to find a local solution.
However, it would be advantageous for user 110 to modify source
file 115 such that the optimization problem may be reduced and
parsed as a GP instead of SGP. This modification will provide a GP
solver the opportunity to find a global solution to the
optimization problem.
[0055] While the invention has been described in terms of several
embodiments, those skilled in the art will recognize that the
invention is not limited to the embodiments described. The method
and apparatus of the invention can be practiced with modification
and alteration within the spirit and scope of the appended claims.
The description is thus to be regarded as illustrative instead of
limiting on the invention.
* * * * *