Risk budgeting

struct RiskBudgetingResult{__T_jr, __T_r, __T_prb, __T_fb} <: RiskJuMPOptimisationResult

Result type for Risk Budgeting portfolio optimisation.

Fields

• jr: Shared JuMP result core, see JuMPOptimisationResult.

• r: The risk measure the optimisation ran under, or a vector of them, stored resolved — a Deferred Quantity has already been fitted and an unstated slot has already taken the prior's field. A resolved measure is fitted state, not configuration, so it belongs on the Result. Pass it back as expected_risk(res.r, res.w, res.pr; sca = res.sca).

• prb: Processed risk budgeting configuration.

• fb: The fallback chain that answered this result: the (estimator, result) pair of every attempt optimise made before this one, in the order they ran, or nothing when the estimator it was asked of answered (see FbChain).

Property access delegates to the embedded JuMPOptimisationResult; unknown properties forward to prb first, then through jr (including the virtual :w and the pa fall-through).

Constructors

RiskBudgetingResult(;    jr::JuMPOptimisationResult,    r::BaseRM_VecBaseRM,    prb::Union{ProcessedAssetRiskBudgetingAttributes,               ProcessedFactorRiskBudgetingAttributes},    fb::Option{<:OptE_Opt_FbChain}) -> RiskBudgetingResult

Keywords correspond to the struct's fields.

Related

• RiskBudgeting
• RelaxedRiskBudgetingResult
• RiskJuMPOptimisationResult
• JuMPOptimisationResult

struct LogRiskBudgeting{T} <: RiskBudgetingFormulation

Log-barrier formulation for Risk Budgeting.

Adds the constraint $\boldsymbol{b}^\intercal \ln(\boldsymbol{y}) \geq 0$, whose Karush-Kuhn-Tucker conditions are the risk budgeting condition. The logarithm needs a positive argument, so the solution lies in one orthant. An optional orthant vector z states which one, asset by asset.

The orthant vector is an extension of the published model, which reaches a long-short portfolio through MixedIntegerRiskBudgeting instead. Stating the orthant costs no binary variable, and it needs the signs to be known in advance.

Fields

• z: Optional orthant vector of ±1 defining which assets can have negative weights (-1) or must be positive (+1). If nothing, all assets have positive weights.

Constructors

LogRiskBudgeting(;    z::Option{<:VecInt} = nothing) -> LogRiskBudgeting

Keywords correspond to the struct's fields.

Validation

• If z is provided: !isempty(z) and all(x -> abs(x) == 1, z).

Related

• RiskBudgetingFormulation
• MixedIntegerRiskBudgeting
• RiskBudgeting

References

• [5] D. Cajas. Advanced Portfolio Optimization: A Cutting-edge Quantitative Approach (Springer Nature Switzerland, 2025). Section 10.1.3, Equations 10.8-10.10.
• [136] S. Maillard, T. Roncalli and J. Teiletche. On the properties of equally-weighted risk contributions portfolios. Available at SSRN 1271972 (2008).
• [137] B. Bruder and T. Roncalli. Managing risk exposures using the risk budgeting approach. Available at SSRN 2009778 (2012).

struct MixedIntegerRiskBudgeting <: RiskBudgetingFormulation

Mixed-integer formulation for Risk Budgeting.

Uses binary variables and big-M constraints to enforce the risk budget constraints. This can find the minimal risk portfolio which meets the risk budgeting constraints by exploring all possible sign combinations of weights. This can be very expensive for large universes.

Related

• RiskBudgetingFormulation
• LogRiskBudgeting
• RiskBudgeting

References

• [5] D. Cajas. Advanced Portfolio Optimization: A Cutting-edge Quantitative Approach (Springer Nature Switzerland, 2025). Section 10.1.4, Equation 10.11.
• [138] MOSEK ApS. MOSEK Portfolio Optimization Cookbook (2023).

struct AssetRiskBudgeting{__T_rkb, __T_sets, __T_alg} <: RiskBudgetingAlgorithm

Asset-level Risk Budgeting algorithm.

AssetRiskBudgeting specifies the risk budget as a vector of asset-level risk targets, optionally grouped by asset sets.

Fields

• rkb: Risk budget estimator or result.

• sets: Sets used to map estimator values to assets.

• alg: Risk budget algorithm.

Constructors

AssetRiskBudgeting(;    rkb::Option{<:RkbE_Rkb} = nothing,    sets::Option{<:UniverseSets} = nothing,    alg::RiskBudgetingFormulation = LogRiskBudgeting()) -> AssetRiskBudgeting

Keywords correspond to the struct's fields.

Validation

• If rkb is a RiskBudgetEstimator: !isnothing(sets).

View parameters

When port_opt_view is called on this type, the following @vprop-tagged fields are automatically subset to the selected indices:

• rkb: Recursively viewed via port_opt_view.
• sets: Sliced to the selected indices via port_opt_view.
• alg: Recursively viewed via port_opt_view.

Related

• RiskBudgetingAlgorithm
• FactorRiskBudgeting
• RiskBudgeting
• port_opt_view

References

• [5] D. Cajas. Advanced Portfolio Optimization: A Cutting-edge Quantitative Approach (Springer Nature Switzerland, 2025). Section 10.1.
• [136] S. Maillard, T. Roncalli and J. Teiletche. On the properties of equally-weighted risk contributions portfolios. Available at SSRN 1271972 (2008).
• [137] B. Bruder and T. Roncalli. Managing risk exposures using the risk budgeting approach. Available at SSRN 2009778 (2012).

struct FactorRiskBudgeting{__T_re, __T_rkb, __T_sets, __T_flag} <: RiskBudgetingAlgorithm

Factor-level Risk Budgeting algorithm.

FactorRiskBudgeting specifies the risk budget at the factor level, using a factor model regression to decompose risk across factors and an idiosyncratic component.

A named budget is written in factor names and resolved against the factor axis re names — factor_axis_key reads sets.tfkey off the time-series family and sets.cfkey off the cross-sectional one. That axis must name the columns of rr.L in order — see risk_budget_universe_key.

Fields

• re: Regression estimator.

• rkb: Risk budget estimator or result.

• sets: Universe sets. A factor axis is what this algorithm reads — factor_axis_key picks sets.tfkey or sets.cfkey off re, so the axis follows the loadings family rather than the caller. It is the universe the risk budget is written in, and it must name the columns of rr.L in order — the budget is over the factor weights w1, one per column of the loadings the risk decomposition uses. It is only read when rkb is a RiskBudgetEstimator; a RiskBudget result carries its own vector and resolves no names. The asset axis is required by UniverseSets and is what a view slices — the factor entries come back from port_opt_view untouched.

• flag: Algorithm selection flag.

Constructors

FactorRiskBudgeting(;    re::RegE_Reg = StepwiseRegression(),    rkb::Option{<:RkbE_Rkb} = nothing,    sets::Option{<:UniverseSets} = nothing,    flag::Bool = true) -> FactorRiskBudgeting

Keywords correspond to the struct's fields.

Validation

• If rkb is a RiskBudgetEstimator: !isnothing(sets).

View parameters

When port_opt_view is called on this type, the following @vprop-tagged fields are automatically subset to the selected indices:

• re: Loadings sliced to the selected assets via port_opt_view.
• sets: Sliced via port_opt_view, which subsets the asset axis and leaves the factor entries untouched. The field participates in views because it may carry both axes; rkb does not, because a factor budget has no asset index to slice by.

Related

• RiskBudgetingAlgorithm
• AssetRiskBudgeting
• RiskBudgeting
• risk_budget_universe_key
• port_opt_view

References

• [5] D. Cajas. Advanced Portfolio Optimization: A Cutting-edge Quantitative Approach (Springer Nature Switzerland, 2025). Section 10.2.2, Equation 10.21.
• [132] T. Roncalli and G. Weisang. Risk parity portfolios with risk factors. Available at SSRN 2155159 (2012).

struct RiskBudgeting{__T_opt, __T_r, __T_rba, __T_wi, __T_fb} <: RiskJuMPOptimisationEstimator

Risk Budgeting (RB) portfolio optimiser.

RiskBudgeting allocates portfolio weights so that each asset (or factor) contributes a specified fraction of the total portfolio risk. It uses a logarithmic or mixed-integer formulation and can be combined with any risk measure.

Fields

• opt: JuMP optimiser configuration.

• r: Risk measure or vector of risk measures.

• rba: Risk budget algorithm.

• wi: Initial portfolio weights for warm-starting the solver.

• fb: Fallback result or estimator.

Constructors

RiskBudgeting(;    opt::JuMPOptimiser,    r::TD{<:RM_VecRM} = Variance(),    rba::TD{<:RiskBudgetingAlgorithm} = AssetRiskBudgeting(),    wi::TD_Option{<:VecNum} = nothing,    fb::TDO_Option{<:OptE_Opt} = nothing) -> RiskBudgeting

Keywords correspond to the struct's fields. Fields typed TD, TD_Option or TDO_Option may hold a TimeDependent per-fold schedule instead of a static value: the risk measure, budgeting algorithm (and with it the risk budget), warm start and fallback are problem definition, so a cross-validation fold loop resolves them per fold, and a fold-less optimise runs with each at its static default (nothing for wi and fb).

Validation

• If r is a vector: !isempty(r).
• If wi is provided: !isempty(wi).
• fb schedules: bind !== :nearest.

Mathematical definition

A positive homogeneous convex risk measure splits into the risk contributions of the assets, which is the Euler decomposition:

\[\begin{align} \rho(\boldsymbol{w}) &= \sum_{i=1}^{N} RC_{i}(\boldsymbol{w})\,, \quad RC_{i}(\boldsymbol{w}) = w_{i} \frac{\partial \rho(\boldsymbol{w})}{\partial w_{i}}\,. \end{align}\]

A risk budgeting portfolio is one whose contributions stand in the stated proportions $\boldsymbol{b}$:

\[\begin{align} w_{i} \frac{\partial \rho(\boldsymbol{w})}{\partial w_{i}} &= b_{i} \, \rho(\boldsymbol{w})\,, \quad \sum_{i=1}^{N} b_{i} = 1\,, \quad b_{i} \geq 0\,. \end{align}\]

That condition is not solved directly. LogRiskBudgeting solves the equivalent problem, in which a logarithmic constraint replaces it. Its solution $\boldsymbol{y}$ is determined up to scale, and the weights are recovered as $\boldsymbol{w} = \boldsymbol{y} / k$:

\[\begin{align} \underset{\boldsymbol{y},\, k}{\min} \; &\rho(\boldsymbol{y}) \\ \text{s.t.} \quad &\boldsymbol{b}^\intercal \ln(\boldsymbol{y}) \geq 0\,, \\ &\boldsymbol{1}^\intercal \boldsymbol{y} = k\,, \\ &\boldsymbol{y} \geq \boldsymbol{0}\,. \end{align}\]

The right-hand side of the logarithmic constraint sets the scale of $\boldsymbol{y}$ alone, so 0 is used where the published model writes an arbitrary constant. The Karush-Kuhn-Tucker conditions of this problem are the risk budgeting condition above.

The logarithm confines the solution to one orthant. MixedIntegerRiskBudgeting reaches a long-short portfolio by splitting the weight into two non-negative parts and taking the logarithm of their sum, and a binary vector holds one part at zero per asset:

\[\begin{align} \underset{\boldsymbol{y}^{+},\, \boldsymbol{y}^{-},\, \boldsymbol{z},\, k}{\min} \; &\rho(\boldsymbol{y}) \\ \text{s.t.} \quad &\boldsymbol{b}^\intercal \ln(\boldsymbol{y}^{+} + \boldsymbol{y}^{-}) \geq 0\,, \\ &\boldsymbol{y} = \boldsymbol{y}^{+} - \boldsymbol{y}^{-}\,, \quad \boldsymbol{1}^\intercal \boldsymbol{y} \geq k\,, \\ &\boldsymbol{y}^{+} \leq M \boldsymbol{z}\,, \quad \boldsymbol{y}^{-} \leq M (\boldsymbol{1} - \boldsymbol{z})\,, \\ &\boldsymbol{y}^{+},\, \boldsymbol{y}^{-} \geq \boldsymbol{0}\,, \quad \boldsymbol{z} \in \{0, 1\}^{N}\,. \end{align}\]

FactorRiskBudgeting states the budget over the factors instead. The weights are re-based onto the factor axis, $\boldsymbol{y} = (\mathbf{B}^\intercal)^{+} \boldsymbol{y}_{f}$, and the logarithmic constraint is written on $\boldsymbol{b}_{f}^\intercal \ln(\boldsymbol{y}_{f})$.

Where:

• $\boldsymbol{w}$: Portfolio weight vector.
• $w_{i}$: Portfolio weight of asset $i$.
• $\boldsymbol{y}$: Unscaled weight vector, the decision variable. $\boldsymbol{w} = \boldsymbol{y} / k$.
• $k$: Scaling variable.
• $\rho(\boldsymbol{w})$: Portfolio risk measure.
• $RC_{i}(\boldsymbol{w})$: Risk contribution of asset $i$.
• $\boldsymbol{b}$: Risk budget vector, rba.rkb.
• $\boldsymbol{b}_{f}$: Risk budget vector over the factors.
• $\boldsymbol{y}_{f}$: Factor exposure vector.
• $\mathbf{B}$: Loading matrix.
• $\boldsymbol{z}$: Binary vector. $z_{i} = 1$ lets asset $i$ be long, $z_{i} = 0$ lets it be short.
• $M$: Large constant of the big-M constraints.
• $N$: Number of assets.

Details

• Every logarithm is modelled as an exponential cone.
• k is a free variable under this head, not k >= 0 and not the literal 1. The logarithmic constraint pins the scale on its own.

Propagated parameters

When factory is called on this type, the following @fprop-tagged fields are automatically propagated:

• opt: Recursively updated via factory.
• r: Recursively updated via factory.
• fb: Recursively updated via factory.

View parameters

RiskBudgeting defines its own port_opt_view method rather than deriving one from field tags.

• The method reads the returns matrix X as its third argument. When opt.pe already holds a prior result, the method replaces X with opt.pe.X, so the children are viewed against the prior's own observations rather than the caller's matrix.
• opt and r recurse through port_opt_view with that matrix. rba recurses with the index alone.
• wi is sliced to the selected assets.
• fb is carried through unchanged.

Related

• optimise
• RiskBudgetingResult
• scalarise_risk_expression!
• set_risk_constraints!
• RiskJuMPOptimisationEstimator
• MeanRisk
• RelaxedRiskBudgeting
• AssetRiskBudgeting
• FactorRiskBudgeting
• factory
• port_opt_view

References

• [5] D. Cajas. Advanced Portfolio Optimization: A Cutting-edge Quantitative Approach (Springer Nature Switzerland, 2025). Chapter 10.
• [136] S. Maillard, T. Roncalli and J. Teiletche. On the properties of equally-weighted risk contributions portfolios. Available at SSRN 1271972 (2008).
• [137] B. Bruder and T. Roncalli. Managing risk exposures using the risk budgeting approach. Available at SSRN 2009778 (2012).
• [132] T. Roncalli and G. Weisang. Risk parity portfolios with risk factors. Available at SSRN 2155159 (2012).

factory(a::Union{Nothing, <:AbstractEstimator, <:AbstractAlgorithm,
                 <:AbstractResult}, args...; kwargs...) -> a
factory(a::AbstractVector{<:Union{Nothing, <:AbstractEstimator, <:AbstractAlgorithm,
                                  <:AbstractResult}}, args...; kwargs...) -> Vector

No-op factory function for constructing objects with a uniform interface.

Defining methods which dispatch on the first argument allows for a consistent factory interface across different types.

factory and port_opt_view are the two propagation mechanisms in this library. They are duals: factory threads runtime values (prior moments, observation weights, previous portfolio weights) down through a composed struct tree; port_opt_view threads an index selection (a subset of assets or observations) down through the same tree.

The vector method is the one forwarding contract for every vector-valued propagation field: it applies factory to each element and forwards args... and kwargs... unchanged, so a family that admits a vector of estimators, algorithms, or results needs no method of its own. A family that needs more than the forward, such as a concrete element type (concrete_typed_array_if_abstract), defines its own more specific method.

Algorithm

The scalar method:

1. Return a unchanged, and drop args... and kwargs.... This method is the leaf of the recursion, and it is what makes an untagged type safe to call the verb on.

The vector method:

1. For each element ai of a, call factory on ai, and forward args... and kwargs... unchanged.
2. Collect the results into a new vector, in the order of a, and return it.

A @propagatable struct with at least one @fprop- or @wprop-tagged field carries a generated method that dominates the scalar method. That method rebuilds the struct with its keyword constructor, sending each @fprop field through factory_child and each @wprop field through _wprop.

Arguments

• a: Indicates no object should be constructed, or a vector whose elements are rebuilt one by one.
• args...: Arbitrary positional arguments (ignored by the scalar method, forwarded by the vector method).
• kwargs...: Arbitrary keyword arguments (ignored by the scalar method, forwarded by the vector method).

Returns

• a: The input unchanged.
• v::Vector: The element-wise rebuilds, for the vector method.

Examples

julia> factory(nothing, 1, 2; x = 3)julia> factory(MeanValue())MeanValue  w ┴ nothing

Related

• port_opt_view
• AbstractEstimator
• AbstractAlgorithm
• AbstractResult

factory(res::NonFiniteAllocationOptimisationResult, fb::Option{<:OptE_Opt_FbChain})

Rebuild a continuous optimisation result with an updated fallback record fb.

Every optimisation result carries fb as its last field, so the generic rebuild copies all fields unchanged except the trailing fb. Concrete result types may override this method when rebuilding requires more than swapping fb. optimise is the one caller, and it hands in the FbChain it walked.

Related

• OptE_Opt_FbChain
• NonFiniteAllocationOptimisationResult

factory(
    opt::Union{NonFiniteAllocationOptimisationEstimator, NonFiniteAllocationOptimisationResult},
    _
) -> RandomWeighted{_A, var"#s185", _B, _C, _D, _E, _F, Bool} where {_A, var"#s185"<:AbstractRNG, _B, _C, _D, _E, _F}

Return opt unchanged.

Default pass-through factory for optimisation estimators and results. Overridden for estimators that carry parameters requiring update at each optimisation step.

Related

• OptE_Opt
• factory

getproperty(
    r::Union{NonRiskJuMPOptimisationResult, RiskJuMPOptimisationResult},
    sym::Symbol
) -> Any

Default property access for RJR_NRJR: unique fields resolve directly; everything else delegates to the embedded JuMPOptimisationResult jr.

port_opt_view(::RiskBudgetingFormulation, args...) -> nothing

Default fallback for risk budgeting formulation view. Returns nothing for formulations that do not require view slicing.

port_opt_view(x, i, args...; kwargs...) -> nothing_scalar_array_view(x, i)

Sub-select an estimator, result, or algorithm to the asset/observation index i.

port_opt_view is the index-selection counterpart of factory: where factory threads runtime values down a composed struct tree, port_opt_view threads an index selection — restricting every data-bearing field and composed child to the subset i. It is the mechanism that makes meta-optimisers (NestedClustered, SubsetResampling) and cross-validation variants operate on subproblems with identical struct shapes.

Callers do not normally call port_opt_view directly; it is driven by meta-optimisers and cross-validation internals. It is public (not exported) because extension authors who implement a new composed estimator may need to define a method. Use @vprop on data-bearing fields to have the method generated automatically.

This universal fallback handles leaf values: arrays are sliced via nothing_scalar_array_view; scalars, nothing, estimators without data fields, and algorithms pass through unchanged. Composed structs that recurse into children define their own (more specific) method — emitted by @vprop or hand-written.

The threaded tail args... (typically the returns matrix X for the JuMP families) and any kwargs are accepted and dropped here, so a macro-threaded port_opt_view(child, i, X) never MethodErrors on a leaf field.

Algorithm

1. Drop args... and kwargs.... This method is the leaf of the recursion, so it threads nothing further.
2. Return nothing_scalar_array_view of x at i, whose own algorithm names the rule for each leaf type.

Related

• factory
• @vprop
• nothing_scalar_array_view

port_opt_view(::RiskBudgetingFormulation, args...) -> nothing

Default fallback for risk budgeting formulation view. Returns nothing for formulations that do not require view slicing.

port_opt_view(x, i, args...; kwargs...) -> nothing_scalar_array_view(x, i)

Sub-select an estimator, result, or algorithm to the asset/observation index i.

port_opt_view is the index-selection counterpart of factory: where factory threads runtime values down a composed struct tree, port_opt_view threads an index selection — restricting every data-bearing field and composed child to the subset i. It is the mechanism that makes meta-optimisers (NestedClustered, SubsetResampling) and cross-validation variants operate on subproblems with identical struct shapes.

Callers do not normally call port_opt_view directly; it is driven by meta-optimisers and cross-validation internals. It is public (not exported) because extension authors who implement a new composed estimator may need to define a method. Use @vprop on data-bearing fields to have the method generated automatically.

This universal fallback handles leaf values: arrays are sliced via nothing_scalar_array_view; scalars, nothing, estimators without data fields, and algorithms pass through unchanged. Composed structs that recurse into children define their own (more specific) method — emitted by @vprop or hand-written.

The threaded tail args... (typically the returns matrix X for the JuMP families) and any kwargs are accepted and dropped here, so a macro-threaded port_opt_view(child, i, X) never MethodErrors on a leaf field.

Algorithm

1. Drop args... and kwargs.... This method is the leaf of the recursion, so it threads nothing further.
2. Return nothing_scalar_array_view of x at i, whose own algorithm names the rule for each leaf type.

Related

• factory
• @vprop
• nothing_scalar_array_view

port_opt_view(::RiskBudgetingFormulation, args...) -> nothing

Default fallback for risk budgeting formulation view. Returns nothing for formulations that do not require view slicing.

factory(a::Union{Nothing, <:AbstractEstimator, <:AbstractAlgorithm,
                 <:AbstractResult}, args...; kwargs...) -> a
factory(a::AbstractVector{<:Union{Nothing, <:AbstractEstimator, <:AbstractAlgorithm,
                                  <:AbstractResult}}, args...; kwargs...) -> Vector

No-op factory function for constructing objects with a uniform interface.

Defining methods which dispatch on the first argument allows for a consistent factory interface across different types.

factory and port_opt_view are the two propagation mechanisms in this library. They are duals: factory threads runtime values (prior moments, observation weights, previous portfolio weights) down through a composed struct tree; port_opt_view threads an index selection (a subset of assets or observations) down through the same tree.

The vector method is the one forwarding contract for every vector-valued propagation field: it applies factory to each element and forwards args... and kwargs... unchanged, so a family that admits a vector of estimators, algorithms, or results needs no method of its own. A family that needs more than the forward, such as a concrete element type (concrete_typed_array_if_abstract), defines its own more specific method.

Algorithm

The scalar method:

1. Return a unchanged, and drop args... and kwargs.... This method is the leaf of the recursion, and it is what makes an untagged type safe to call the verb on.

The vector method:

1. For each element ai of a, call factory on ai, and forward args... and kwargs... unchanged.
2. Collect the results into a new vector, in the order of a, and return it.

A @propagatable struct with at least one @fprop- or @wprop-tagged field carries a generated method that dominates the scalar method. That method rebuilds the struct with its keyword constructor, sending each @fprop field through factory_child and each @wprop field through _wprop.

Arguments

• a: Indicates no object should be constructed, or a vector whose elements are rebuilt one by one.
• args...: Arbitrary positional arguments (ignored by the scalar method, forwarded by the vector method).
• kwargs...: Arbitrary keyword arguments (ignored by the scalar method, forwarded by the vector method).

Returns

• a: The input unchanged.
• v::Vector: The element-wise rebuilds, for the vector method.

Examples

julia> factory(nothing, 1, 2; x = 3)julia> factory(MeanValue())MeanValue  w ┴ nothing

Related

• port_opt_view
• AbstractEstimator
• AbstractAlgorithm
• AbstractResult

factory(
    opt::Union{NonFiniteAllocationOptimisationEstimator, NonFiniteAllocationOptimisationResult},
    _
) -> RandomWeighted{_A, var"#s185", _B, _C, _D, _E, _F, Bool} where {_A, var"#s185"<:AbstractRNG, _B, _C, _D, _E, _F}

Return opt unchanged.

Default pass-through factory for optimisation estimators and results. Overridden for estimators that carry parameters requiring update at each optimisation step.

Related

• OptE_Opt
• factory

port_opt_view(
    rb::RiskBudgeting,
    i,
    X::AbstractMatrix{<:Union{var"#s136", var"#s53"} where {var"#s136"<:Number, var"#s53"<:AbstractJuMPScalar}},
    args...
) -> RiskBudgeting{JuMPOptimiser{__T_pe, __T_slv, __T_wb, __T_bgt, __T_sbgt, __T_gbgt, __T_xbgt, __T_lt, __T_st, __T_lcse, __T_cte, __T_gcarde, __T_sgcarde, __T_smtx, __T_sgmtx, __T_slt, __T_sst, __T_sglt, __T_sgst, __T_tn, __T_fees, __T_sets, __T_tr, __T_ple, __T_ret, __T_sca, __T_ccnt, __T_cobj, __T_sc, __T_so, __T_ss, __T_card, __T_scard, __T_l2c, __T_lpc, __T_linfc, __T_l1, __T_l2, __T_lp, __T_linf, __T_brt, __T_x_src, __T_strict, __T_cache}} where {__T_pe, __T_slv, __T_wb, __T_bgt, __T_sbgt, __T_gbgt, __T_xbgt, __T_lt, __T_st, __T_lcse, __T_cte, __T_gcarde, __T_sgcarde, __T_smtx, __T_sgmtx, __T_slt, __T_sst, __T_sglt, __T_sgst, __T_tn, __T_fees, __T_sets, __T_tr, __T_ple, __T_ret, __T_sca, __T_ccnt, __T_cobj, __T_sc, __T_so, __T_ss, __T_card, __T_scard, __T_l2c, __T_lpc, __T_linfc, __T_l1, __T_l2, __T_lp, __T_linf, __T_brt, __T_x_src, __T_strict, __T_cache}

Return a cluster-sliced copy of RiskBudgeting for asset index set i and returns matrix X.

optimise(rb::RiskBudgeting{<:Any, <:Any, <:Any, <:Any, Nothing},
         rd::ReturnsResult; dims::Int = 1,
         str_names::Bool = false, save::Bool = true, kwargs...) -> RiskBudgetingResult

Run the Risk Budgeting portfolio optimisation.

Arguments

• rb: The risk budgeting optimiser to use.
• rd: The returns result to use. If isa(rb.opt.pe, AbstractPriorResult), rd is not necessary if doing a standalone optimisation, but may be required/desired by fallbacks and/or clusterisation.
• dims: The dimension along which observations advance in time.
• str_names: Whether to use string names for the assets in the optimisation.
• save: Whether to save the JuMP model in the optimisation result.
• kwargs: Additional keyword arguments passed to the optimisation function.

Validation

• No field in the tree of rb holds an Online. An ArgumentError naming the field is thrown otherwise, through assert_batch_entry: a plain optimise is a batch fit, and a wrapper resolves only at the warm-up of the fold loop's online arm.

Related

• RiskBudgeting
• RiskBudgetingResult

needs_previous_weights(opt::RiskBudgeting) -> Any

Return true if any sub-estimator of opt requires previous portfolio weights (JuMP optimiser, risk measure, or fallback).