Step execution
PortfolioOptimisers.constraint_step_value — Function
constraint_step_value(
ce::WeightBoundsEstimator,
ctx::PipelineContext
) -> WeightBounds
Compute the value a constraint step contributes to the constraints slot.
One method per constraint family, each calling that family's constraint-generation verb. The value is paired with its routing target by run_constraint_step; this method decides only what is computed, never where it lands.
Arguments
ce: The constraint estimator.ctx: The pipeline context.
Returns
- The computed value,
nothing, or a vector of either.
Related
constraint_step_value(
ce::ExposureConstraintEstimator,
ctx::PipelineContext
) -> Any
Compute an ExposureConstraintEstimator step's value: re-base its rows through the loadings of the pipeline's prior into an asset-space LinearConstraint.
This is the one constraint step that reads a computed slot other than :returns. The basis is ctx.prior.rr, so a prior step must come earlier; a prior that carries no regression makes constraint_space_basis throw, which is the intended failure — see ExposureConstraintEstimator.
ctx.returns is passed as well, so a space that names a regression estimator refits the loadings here rather than throwing. That is the one arrangement in which a prior carrying no factor block still admits a factor mandate — see FactorSpace.
The constraint is pinned to the pipeline's prior. Its rows were projected through the loadings this step saw, and a downstream optimiser that refits its own prior does not re-project them. Passing the estimator to the optimiser's lcse field instead recomputes the projection with the optimiser's own prior, per fold, which is what a cross-validated factor mandate needs.
Related