Skip to content
All library documents

Choosing a Representation for Portfolio Optimization Constraints

Article Quant Q&A · Author: SRKX

Summary

The document considers how to store and represent constraints in an asset-allocation program. It raises options such as classifying constraints into categories, defining a small domain-specific language and parser, or using a structured representation such as XML. The underlying design question is how to make constraints flexible enough for different allocation rules while keeping them usable by an optimizer.

The answers point to established mathematical modeling formats, including AMPL and MPS, as well as open-source tools such as GLPK. They also suggest constraint-programming languages such as Prolog, where rules can be added or removed declaratively and the problem rerun. These approaches offer alternatives to inventing a custom grammar, but the document does not compare them systematically or identify one best choice. Suitability depends on the optimization problem, supported solvers, integration needs, and how much flexibility the application requires.

Key ideas

  • Asset-allocation software needs a model for storing and expressing optimization constraints.
  • Mathematical modeling languages and formats can provide established representations for optimization problems.
  • Constraint-programming languages offer a declarative approach in which rules can be modified and rerun.
  • The document presents options but does not evaluate them against specific requirements or recommend one universally.

Tags

Full text
# How to represent constraints for optimization problems in a data model?


# How to represent constraints for optimization problems in a data model?












I am at the moment writing a program focusing on asset allocation and I am thinking about how I should represent my constraints in the data model.

The first approach that came to mind was to define some categories to classify the constraints so that they could be stored in a table according to their "category" (for example, unary constraints x>=y, binary constraints y I then came up with another idea which is to define my own "constraint language" with its own grammar and to store it as a `string` in the database (like `Sum("Equities")<Percent(20,Portfolio)`). This would imply writing a parser. I could also opt to use an XML representation of the constraints to use one of the many XML parsers. I wanted to know if anyone had another potential solution and if you knew about some papers discussing this subject?

I then came up with another idea which is to define my own "constraint language" with its own grammar and to store it as a `string` in the database (like `Sum("Equities")<Percent(20,Portfolio)`). This would imply writing a parser. I could also opt to use an XML representation of the constraints to use one of the many XML parsers.

I wanted to know if anyone had another potential solution and if you knew about some papers discussing this subject?

## Answer by philippe (score 4, accepted)

https://quant.stackexchange.com/a/1404

A lot of people use mathematical modelling languages/formats like the proprietary AMPL (see http://en.wikipedia.org/wiki/AMPL) or MPS (see http://en.wikipedia.org/wiki/MPS_%28format%29) to define optimization problems. There are also open source alternatives for a subset of problems (like for example the GNU Linear Programming Kit with its language).

Hans Mittelmann has collected a lot of useful information including test cases under http://plato.asu.edu/guide.html. However, using an optimizer that understands for example AMPL may be not the best approach.

## Answer by G__ (score 4)

https://quant.stackexchange.com/a/1405

This seems like it would be well-suited for implementation in a Prolog. That family of languages is built around a constraint programming model. Specifically, take a look at ECLiPSe. It's mature (originally developed in the 90's by Cisco I believe) and has external hooks to e.g. Java & C++ if you don't want to implement your whole system in prolog.

Prologs are well suited for scheduling and distribution problems: distribute this sum of time/money/points in some way that satisfies this other list of constraints.

It's worth pointing out that the constraints are declarative, so you can just add new constraints or remove old constraints and rerun the program to get new results without having to re-build or re-compile any of the core code.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.