[Returnanalytics-commits] r2272 - pkg/PortfolioAnalytics/inst/doc
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Mon Sep 3 00:24:14 CEST 2012
Author: braverock
Date: 2012-09-03 00:24:14 +0200 (Mon, 03 Sep 2012)
New Revision: 2272
Added:
pkg/PortfolioAnalytics/inst/doc/DesignThoughts.Rnw
Removed:
pkg/PortfolioAnalytics/inst/doc/DesignThoughts.tex
Log:
- add section on penalties
- turn into an Sweave doc, as it seems likely that we'll want to include code chunks at some point
Copied: pkg/PortfolioAnalytics/inst/doc/DesignThoughts.Rnw (from rev 2266, pkg/PortfolioAnalytics/inst/doc/DesignThoughts.tex)
===================================================================
--- pkg/PortfolioAnalytics/inst/doc/DesignThoughts.Rnw (rev 0)
+++ pkg/PortfolioAnalytics/inst/doc/DesignThoughts.Rnw 2012-09-02 22:24:14 UTC (rev 2272)
@@ -0,0 +1,179 @@
+%!TEX root = ../39.tex
+
+\documentclass[12pt,letterpaper,english]{article}
+\pagestyle{plain} \setlength{\textheight}{21cm}
+\setlength{\textwidth}{15cm} \setlength{\footskip}{1.0cm}
+
+%\usepackage{harvard}
+\usepackage{makeidx} % allows index generation
+\usepackage{graphicx} % standard LaTeX graphics tool
+ % when including figure files
+\usepackage{multicol} % used for the two-column index
+\usepackage[bottom]{footmisc}% places footnotes at page bottom
+\usepackage{ctable}
+\usepackage{graphicx}
+\usepackage{verbatim}
+\usepackage{hyperref}
+% see the list of further useful packages
+% in the Springer Reference Guide, Sects. 2.3, 3.1-3.3
+
+\usepackage[longnamesfirst]{natbib}
+\usepackage{rotating}
+
+%\usepackage{noweb}
+%\usepackage[ae,hyper]{Rd}
+\usepackage{Rd}
+\usepackage{Sweave}
+\usepackage{graphicx}
+
+\usepackage{booktabs}
+\usepackage{enumerate}
+\usepackage{url}
+%\usepackage[bottomafter,first]{draftcopy}
+
+\newcommand{\rem}[1]{}
+
+
+%\numberwithin{equation}{section}
+\renewcommand{\baselinestretch}{1.3}
+
+
+\newcommand{\afterbox}{\bigskip
+ \normalsize
+ \lineskip=.45ex
+ \baselineskip 3.5ex
+ \noindent
+ \textheight 19.5cm}
+
+\newcommand{\argmin}{{\operatorname{argmin}}}
+\newcommand{\argmax}{{\operatorname{argmax}}}
+\newcommand{\med}{{\operatorname{med}}}
+\newcommand{\ave}{{\operatorname{ave}}}
+\newcommand{\Tr}{{\operatorname{Tr}}}
+%\newcommand{\plim}{{\operatorname{plim}}}
+
+\renewcommand{\cite}{\citeasnoun}
+
+\def \vec{{\mbox{vec }}}
+\def \unvec{{\mbox{unvec}}}
+\def \diag{{\mbox{diag }}}
+
+
+\synctex=1
+
+\setlength{\parindent}{0mm} \setlength{\parskip}{1.5mm}
+
+\newcommand{\comm}[1]{\begin{quote}{\large \bf (#1)}\end{quote}}
+
+\begin{document}
+\vspace{-2cm}
+%\baselineskip=20pt
+\renewcommand{\baselinestretch}{1}
+\title{Discussion of Upcoming and Desired \\ Design and Coding Decisions \\ in PortfolioAnalytics\citet{PortfolioAnalytics}}
+
+
+
+\author{
+Brian G. Peterson\\
+brian at braverock.com \\ \\ \\ }
+
+\date{\today}
+
+\maketitle
+\thispagestyle{empty} % produces no numbering on the first page
+
+\renewcommand{\baselinestretch}{1}
+\begin{abstract}
+PortfolioAnalytics has grown significantly since it was initially written, and will continue to grow and change, especially with the increased involvement of additional portfolio managers and with work on the next version of Doug Martin et. al.'s \emph{Modern Portfolio Optimization}\citep{Scherer2005}
+
+This document lays out Some current state information, some design musings, and some things that we desire to address.
+
+It is my hope that interested readers and users will give us feedback, and possibly even code contributions, to make some of this functionality a reality.
+\end{abstract}
+
+%\end{titlepage}
+
+%\baselineskip=20pt
+\newpage
+\renewcommand{\baselinestretch}{1.3}
+
+\tableofcontents
+
+\newpage
+
+\section{Introduction}
+%% \ref{sec:CVaRbudgets}
+%%\section{Portfolio CVaR budgets \label{sec:CVaRbudgets}}
+%%\subsection{Definition}
+Difference between constraints and objectives
+
+Renaming constraints object, separating constraints and objectives, collections of objectives multi-objective optimization
+
+Specifying constraints
+
+Relaxing constraints penalized versus direct
+
+
+
+\section{Generalizing Constraints \label{sec:constraints}}
+Our overall goal with Portfolioanalytics is to allow the use of many different portfolio solvers to solve the same portfolio problem specification. On the constraints front, this includes support for box constraints, inequality constraints, turnover, and full investment.
+\subsection{Current State \label{ss:currentstate}}
+
+\begin{description}
+
+\item[ Box Constraints ] box constraints (min/max) are supported for all optimization engines, this is a basic feature of any optimization solver in R. It is worth noting that \emph{most} optimization solvers in R support \emph{only} box constraints.
+\\ Box constraints are of course necessary, but not sufficient, and a portfolio that satisfies the box constraints may very well not satisfy any number of other constraints on the combinations of weights.
+
+\item[ Full Investment Constraint ] a full investment constraint or min\_sum, max\_sum constraint is supported for all solvers inside the constrained\_objective function using either a normalization method or a penalty method
+The normalization method simply scales the supplied parameters to either the minimum or the maximum if the sum is outside the allowed bounds. This has the advantage of being fast, but the disadvantages of decreasing the number of portfolios that will be tested that have assets that use your max/min box constraints, because of the scaling effects. You'll get close, but very few tested portfolios, perhaps none, will have assets that exactly hit the max or min box constrained weights.
+\\ The penalty method simply uses the absolute value of the difference for the sum of the weight vector from your min\_sum or max\_sum (depending on which was violated) as part of the penalized objective output that the solver is working on. This has the advantage that you are not doing transformations on the supplied weight vector inside the constrained\_objective function, but the disadvantage that it may take the solver a long time to find a population that meets the objectives.
+\\ For the ROI solvers, min\_sum and max\_sum are supported as linear constraints on the sum of the weights vector.
+
+\item[Linear Inequality Constraints] individual linear inequality constraints are currently supported only for the ROI solvers, because ROI supports these types of constraints for at least Rglpk and quadprog solvers, and apparently also several other solvers that directly support these types of constraints, such as ipop. These constraints can indicate that specific assets must be larger or smaller than other assets in the portfolio.
+
+\item[Group Inequality Constraints]linear group inequality constraints are currently supported only for the ROI solvers. These constraints can separate the portfolio assets into groups, and apply basic inequalities "$>$","$<$","$>=$", "$<=$", etc to them so that the sum of the weights in the group must satisfy the constraint versus another group or groups.
+
+
+\item[Turnover] turnover is currently supported as an objective that can be added to your overall portfolio objectives, and is handled inside constrained objective. I think that it could also be handled as a true constraint, which I'll discuss in a bit.
+
+\end{description}
+
+\subsection{Improving the Current State of Constraints}
+
+\begin{description}
+\item[Modularize Constraints] today, the cox constraints are included in the \code{constraints} constructor. It would be better to have a portfolio specification object that included multiple sections: constraints, objectives, assets. (this is how the object is organized, but that's not obvious to the user). I think that we should have an \code{add.constraint} function like \code{add.objective} that would add specific types of constraints:
+ \begin{enumerate}
+ \item box constraints
+ \item asset inequality constraints
+ \item group inequality constraints
+ \item turnover constraint
+ \item full investment or leverage constratint
+ \end{enumerate}
+
+\item[Creating a mapping function]
+
+\code{DEoptim} contains the ability to use a mapping function to manage constraints, but there are no generalized mapping functions available. For PortfolioAnalytics, I think that we can write a constraint mapping function that could do the trick, even with general optimization solvers that use only box constraints.
+The mapping function should have the following features:
+ \begin{itemize}
+ \item[methods:] the methods should be able to be turned on and off, and applied in different orders. For some constraint mapping, it will be important to do things in a particular order. Also, for solvers that support certain types of constraints directly, it will be important to use the solver's features, and not use the corresponding mapping functionality.
+ \item[layering:] \code{ROI} constains function \code{rbind.L\_constraint}, which combines the various linear inwequality constraints into a single model. We should examine this and see if we can make use of it, or something like it, to create a consolidated inequality constraint mapping capability
+ \item[relocatable:] for some solvers such as \code{DEoptim}, the solver can use the mapping function to only evaluate the objective for portfolios that meet the constraints. For other solvers, where only box constraints are supported, we will need to either penalize or transform (see discussussion above in \ref{ss:currentstate}) weights vector later in the process, inside the \code{constrained\_objective} function.
+ \item[relax constraints:]we need the ability to relax infeasible constraints, either via the penalty method (just find the closest) or when transforming the weights vector to a feasible set. see also \ref{sec:penalty} for a discussion of adaptive penalties.
+
+ \end{itemize}
+
+The mapping function could easily be incorporated directly into random portfolios, and some vcode might even move from random portfolios into the mapping function. DEoptim can call the mapping function directly when generating a population. For outher solvers, we'll need to read the specification, determine what types of constraints need to be applied, and utilize any solver-specific functionality to support as many of them as possible. For any remaining constraints that the solver cannot apply directly, we can call the mapping function to either penalize or transfrom the weights on the remaining methods inside \code{constrained\_objective}.
+
+\end{description}
+
+\section{Penalty Functions \label{sec:penalty}}
+The current state uses a user-defined fixed penalty function for each objective, multiplying the exceedence or difference of the objective from a target against a fixed penalty. This requires the user to understand how penalty terms influence optimization, and to modify their terms as required.
+
+The multiple papers since 2003 or so suggest that an adaptive penalty that changes with the number of iterations and the variability of the answers for the objective can significantly improve convergence. [add references]. As we re-do the constraints, we should consider applying the penalty there for small feasible constraint areas (e.g. after trying several hundred times to get a random draw that fits, use adaptively penalized contraints to get as close as possible), but even more importantly perhaps we should support an adaptive constraint in the objectives.
+
+Several different methods have been proposed. In the case of constraints, penalties should probably be relaxed as more infeasible solutions are found, as the feasible space is likely to be small. In the sase of objectives, arguably the opposte is true, where penalties should increase as the number of iterations increases, to speed convergence to a sinlge solution, hopefully at or near the global minima.
+
+\bibliographystyle{chicago}
+\bibliography{PA.bib}
+
+\end{document}
Deleted: pkg/PortfolioAnalytics/inst/doc/DesignThoughts.tex
===================================================================
--- pkg/PortfolioAnalytics/inst/doc/DesignThoughts.tex 2012-09-02 01:56:23 UTC (rev 2271)
+++ pkg/PortfolioAnalytics/inst/doc/DesignThoughts.tex 2012-09-02 22:24:14 UTC (rev 2272)
@@ -1,171 +0,0 @@
-%!TEX root = ../39.tex
-
-\documentclass[12pt,letterpaper,english]{article}
-\pagestyle{plain} \setlength{\textheight}{21cm}
-\setlength{\textwidth}{15cm} \setlength{\footskip}{1.0cm}
-
-%\usepackage{harvard}
-\usepackage{makeidx} % allows index generation
-\usepackage{graphicx} % standard LaTeX graphics tool
- % when including figure files
-\usepackage{multicol} % used for the two-column index
-\usepackage[bottom]{footmisc}% places footnotes at page bottom
-\usepackage{ctable}
-\usepackage{graphicx}
-\usepackage{verbatim}
-\usepackage{hyperref}
-% see the list of further useful packages
-% in the Springer Reference Guide, Sects. 2.3, 3.1-3.3
-
-\usepackage[longnamesfirst]{natbib}
-\usepackage{rotating}
-
-%\usepackage{noweb}
-%\usepackage[ae,hyper]{Rd}
-\usepackage{Rd}
-\usepackage{Sweave}
-\usepackage{graphicx}
-
-\usepackage{booktabs}
-\usepackage{enumerate}
-\usepackage{url}
-%\usepackage[bottomafter,first]{draftcopy}
-
-\newcommand{\rem}[1]{}
-
-
-%\numberwithin{equation}{section}
-\renewcommand{\baselinestretch}{1.3}
-
-
-\newcommand{\afterbox}{\bigskip
- \normalsize
- \lineskip=.45ex
- \baselineskip 3.5ex
- \noindent
- \textheight 19.5cm}
-
-\newcommand{\argmin}{{\operatorname{argmin}}}
-\newcommand{\argmax}{{\operatorname{argmax}}}
-\newcommand{\med}{{\operatorname{med}}}
-\newcommand{\ave}{{\operatorname{ave}}}
-\newcommand{\Tr}{{\operatorname{Tr}}}
-%\newcommand{\plim}{{\operatorname{plim}}}
-
-\renewcommand{\cite}{\citeasnoun}
-
-\def \vec{{\mbox{vec }}}
-\def \unvec{{\mbox{unvec}}}
-\def \diag{{\mbox{diag }}}
-
-
-\synctex=1
-
-\setlength{\parindent}{0mm} \setlength{\parskip}{1.5mm}
-
-\newcommand{\comm}[1]{\begin{quote}{\large \bf (#1)}\end{quote}}
-
-\begin{document}
-\vspace{-2cm}
-%\baselineskip=20pt
-\renewcommand{\baselinestretch}{1}
-\title{Discussion of Upcoming and Desired \\ Design and Coding Decisions \\ in PortfolioAnalytics\citet{PortfolioAnalytics}}
-
-
-
-\author{
-Brian G. Peterson\\
-brian at braverock.com \\ \\ \\ }
-
-\date{\today}
-
-\maketitle
-\thispagestyle{empty} % produces no numbering on the first page
-
-\renewcommand{\baselinestretch}{1}
-\begin{abstract}
-PortfolioAnalytics has grown significantly since it was initially written, and will continue to grow and change, especially with the increased involvement of additional portfolio managers and with work on the next version of Doug Martin et. al.'s \emph{Modern Portfolio Optimization}\citep{Scherer2005}
-
-This document lays out Some current state information, some design musings, and some things that we desire to address.
-
-It is my hope that interested readers and users will give us feedback, and possibly even code contributions, to make some of this functionality a reality.
-\end{abstract}
-
-%\end{titlepage}
-
-%\baselineskip=20pt
-\newpage
-\renewcommand{\baselinestretch}{1.3}
-
-\tableofcontents
-
-\newpage
-
-\section{Introduction}
-%% \ref{sec:CVaRbudgets}
-%%\section{Portfolio CVaR budgets \label{sec:CVaRbudgets}}
-%%\subsection{Definition}
-Difference between constraints and objectives
-
-Renaming constraints object, separating constraints and objectives, collections of objectives multi-objective optimization
-
-Specifying constraints
-
-Relaxing constraints penalized versus direct
-
-
-
-\section{Generalizing Constraints \label{sec:constraints}}
-Our overall goal with Portfolioanalytics is to allow the use of many different portfolio solvers to solve the same portfolio problem specification. On the constraints front, this includes support for box constraints, inequality constraints, turnover, and full investment.
-\subsection{Current State \label{ss:currentstate}}
-
-\begin{description}
-
-\item[ Box Constraints ] box constraints (min/max) are supported for all optimization engines, this is a basic feature of any optimization solver in R. It is worth noting that \emph{most} optimization solvers in R support \emph{only} box constraints.
-\\ Box constraints are of course necessary, but not sufficient, and a portfolio that satisfies the box constraints may very well not satisfy any number of other constraints on the combinations of weights.
-
-\item[ Full Investment Constraint ] a full investment constraint or min\_sum, max\_sum constraint is supported for all solvers inside the constrained\_objective function using either a normalization method or a penalty method
-The normalization method simply scales the supplied parameters to either the minimum or the maximum if the sum is outside the allowed bounds. This has the advantage of being fast, but the disadvantages of decreasing the number of portfolios that will be tested that have assets that use your max/min box constraints, because of the scaling effects. You'll get close, but very few tested portfolios, perhaps none, will have assets that exactly hit the max or min box constrained weights.
-\\ The penalty method simply uses the absolute value of the difference for the sum of the weight vector from your min\_sum or max\_sum (depending on which was violated) as part of the penalized objective output that the solver is working on. This has the advantage that you are not doing transformations on the supplied weight vector inside the constrained\_objective function, but the disadvantage that it may take the solver a long time to find a population that meets the objectives.
-\\ For the ROI solvers, min\_sum and max\_sum are supported as linear constraints on the sum of the weights vector.
-
-\item[Linear Inequality Constraints] individual linear inequality constraints are currently supported only for the ROI solvers, because ROI supports these types of constraints for at least Rglpk and quadprog solvers, and apparently also several other solvers that directly support these types of constraints, such as ipop. These constraints can indicate that specific assets must be larger or smaller than other assets in the portfolio.
-
-\item[Group Inequality Constraints]linear group inequality constraints are currently supported only for the ROI solvers. These constraints can separate the portfolio assets into groups, and apply basic inequalities "$>$","$<$","$>=$", "$<=$", etc to them so that the sum of the weights in the group must satisfy the constraint versus another group or groups.
-
-
-\item[Turnover] turnover is currently supported as an objective that can be added to your overall portfolio objectives, and is handled inside constrained objective. I think that it could also be handled as a true constraint, which I'll discuss in a bit.
-
-\end{description}
-
-\subsection{Improving the Current State of Constraints}
-
-\begin{description}
-\item[Modularize Constraints] today, the cox constraints are included in the \code{constraints} constructor. It would be better to have a portfolio specification object that included multiple sections: constraints, objectives, assets. (this is how the object is organized, but that's not obvious to the user). I think that we should have an \code{add.constraint} function like \code{add.objective} that would add specific types of constraints:
- \begin{enumerate}
- \item box constraints
- \item asset inequality constraints
- \item group inequality constraints
- \item turnover constraint
- \item full investment or leverage constratint
- \end{enumerate}
-
-\item[Creating a mapping function]
-
-\code{DEoptim} contains the ability to use a mapping function to manage constraints, but there are no generalized mapping functions available. For PortfolioAnalytics, I think that we can write a constraint mapping function that could do the trick, even with general optimization solvers that use only box constraints.
-The mapping function should have the following features:
- \begin{itemize}
- \item[methods:] the methods should be able to be turned on and off, and applied in different orders. For some constraint mapping, it will be important to do things in a particular order. Also, for solvers that support certain types of constraints directly, it will be important to use the solver's features, and not use the corresponding mapping functionality.
- \item[layering:] \code{ROI} constains function \code{rbind.L\_constraint}, which combines the various linear inwequality constraints into a single model. We should examine this and see if we can make use of it, or something like it, to create a consolidated inequality constraint mapping capability
- \item[relocatable:] for some solvers such as \code{DEoptim}, the solver can use the mapping function to only evaluate the objective for portfolios that meet the constraints. For other solvers, where only box constraints are supported, we will need to either penalize or transform (see discussussion above in \ref{ss:currentstate}) weights vector later in the process, inside the \code{constrained\_objective} function.
- \item[relax constraints:]we need the ability to relax infeasible constraints, either via the penalty method (just find the closest) or when transforming the weights vector to a feasible set.
- \end{itemize}
-
-The mapping function could easily be incorporated directly into random portfolios, and some vcode might even move from random portfolios into the mapping function. DEoptim can call the mapping function directly when generating a population. For outher solvers, we'll need to read the specification, determine what types of constraints need to be applied, and utilize any solver-specific functionality to support as many of them as possible. For any remaining constraints that the solever cannot apply directly, we can call the mapping function to either penalize or transfrom the weights on the remaining methods inside \code{constrained\_objective}.
-
-\end{description}
-
-\bibliographystyle{chicago}
-\bibliography{PA.bib}
-
-\end{document}
More information about the Returnanalytics-commits
mailing list