Propagatable

@propagatable expr

Define a struct and automatically generate its propagation methods from five orthogonal, stackable field tags:

• @fprop (factory propagation): tagged fields receive factory_child calls when factory is invoked, recursing runtime values (observation weights, prior results, solvers, …) down the composition tree. A factory(x, args...) method is always generated (it is the identity when no field is tagged @fprop/@wprop).
• @wprop (weights replacement): tagged observation-weights fields are replaced by an incoming ObsWeights argument via _wprop (and left unchanged when none is threaded). Use @wprop for the weights slot and @fprop for sub-estimators — a weights field that defaults to nothing must become the incoming weights, which conflicts with @fprop's nothing-passthrough.
• @vprop (view propagation): tagged fields receive port_opt_view calls when a view (an index selection) is propagated, recursing into composed children and slicing data arrays. A port_opt_view method is generated only when at least one field is tagged @vprop.
• @pprop (prior selection): tagged fields are selected from the same-named field on a prior result via sel(getfield(x, :f), getproperty(pr, :f)).
• @cprop (context selection): tagged fields are selected against a threaded optimiser value (a solver) found by type via sel(getfield(x, :f), _ctx(args...)).

When at least one field is tagged @pprop or @cprop, a second method factory(x, pr::AbstractPriorResult, args...) is generated. It selects @pprop/@cprop fields as above and threads @fprop-only fields with pr (factory_child(getfield(x, :f), pr, args...)); a field tagged both @pprop and @fprop is prior-selected in this method (@pprop wins). It then calls resolve_deferred_quantities on the selected struct — the identity unless the type declares a method — so the Deferred-Quantity resolution runs last and a slot that holds one sees the solver, the observation weights and the children already settled. Because this method is more specific than the general factory(x, args...), it is chosen whenever a prior is passed.

Untagged fields pass through unchanged in every method, regardless of type — tagging is explicit and opt-in. The tags are independent and the relevant field sets genuinely diverge. @pprop and @cprop are mutually exclusive on one field (a value comes from exactly one source); legal stacks are @pprop @fprop (sub-estimator) and @pprop @wprop (weights slot).

Two consequences of the emitted code are contracts on the declaration, and both are checked where the struct is written rather than at the first call:

• Every generated method rebuilds the struct as StructName(; field = …) over all fields, tagged or not, so every field name must also be a keyword of the outer constructor. A kwargs... slurp does not satisfy this: it accepts the keyword and then discards it.
• The prior method reads getproperty(pr, :field), so every @pprop field name must be a property of a prior result (see prior_result_property_pool).

The macro registers each declaration in PROPAGATABLE_CONTRACTS, and check_propagatable_contracts checks the whole registry once the module is complete. A mistyped field name therefore fails at precompilation with a suggest_declared_key suggestion, rather than surfacing as a MethodError at the first factory call. forward_prior leans on the same contract.

The tag set itself is data. PROP_TAG_NAMES holds the rows, prop_tag_expr holds each tag's field transform, and PROP_TAG_CHANNELS holds each channel's gate and tag precedence, so a new propagation channel is a table row rather than an edit at seven sites.

Composes with @concrete (put @propagatable outermost):

@propagatable @concrete struct MyMeasure <: RiskMeasure    @pprop @wprop w       # prior factory selects pr.w; ObsWeights factory fills w    @pprop sigma          # prior-selected from pr.sigma    @fprop alg            # threaded (recursed) with pr / args    config                # passed through unchanged    function MyMeasure(w, sigma, alg, config)        return new{typeof(w), typeof(sigma), typeof(alg), typeof(config)}(w, sigma, alg,                                                                          config)    endend

@wprop drives two channels at once, and they do different things to the same field: factory replaces it with an incoming ObsWeights value, while obs_weights_view indexes the value already there, to a set of observations. A weights field therefore needs no second tag to join the observation-axis view.

The generated factory/port_opt_view/obs_weights_view methods are added to the PortfolioOptimisers functions, so @propagatable works correctly for types defined in external packages.

Docstrings on the enclosing definition are forwarded correctly via Base.@__doc__.

Algorithm

1. Find the struct with propagatable_find_struct, which gives struct_node and rebuild, the function that puts a replacement struct back inside the same chain of wrapping macros.
2. Read type_head and body off struct_node, and read struct_name off type_head with propagatable_bare_name, which drops the type parameters and the supertype.
3. Parse the body with propagatable_parse_body, which gives tagged, the field names per tag; all_fields, every declared field in declaration order; and new_body, the body with every tag stripped.
4. Build new_struct from new_body, and chain from rebuild(new_struct). chain is the original declaration with the tags gone, so @concrete and Julia both see an ordinary struct.
5. Bind POMOD to the module that defines the macro, and qualify every emitted name against it. A bare name would resolve in the caller's module, where function factory(…) declares a new function of the caller's own and the method never reaches PortfolioOptimisers.factory. That failure is silent, because the declaration compiles and the type never joins the propagation chain.
6. Emit the factory method. When prop_channel_active holds for the factory channel, the body is a call to the keyword constructor whose pairs come from prop_channel_pairs; otherwise the body is x itself. This method is always emitted, so an untagged @propagatable struct still answers factory with the identity.
7. When the view channel is active, emit port_opt_view(x::StructName, i, args...), whose channel threads i before args....
8. When the obs channel is active, emit obs_weights_view(x::StructName, i), whose channel threads i and takes no tail.
9. When the prior channel is active, emit factory(x::StructName, pr::AbstractPriorResult, args...; kwargs...). Its body selects every tagged field off x and then hands the selected struct to resolve_deferred_quantities, so the Deferred-Quantity resolution runs last. A Deferred Quantity and a Calibration Rule therefore see the solver, the observation weights and the children in the state the optimisation settled them in, and a rule may call ERM or RRM. This method is more specific than the one of step 6, so a call that threads a prior chooses it.
10. Build pprop_tuple, the @pprop-tagged field names as a tuple of quoted symbols.
11. Return one escaped block holding, in order: Base.@__doc__ chain, so a docstring on the declaration reaches the struct; the emitted methods; and the call to propagatable_register! that records the type and pprop_tuple.

Steps 6 to 9 differ only in the method head and in the arguments that the channel threads. Each reads its gate and its tag precedence off PROP_TAG_CHANNELS, so a new channel is a row of that table, a branch in prop_tag_expr and a stub macro, rather than an edit at seven sites.

Related

• @fprop
• @vprop
• @pprop
• @cprop
• @wprop
• PROP_TAG_NAMES
• PROP_TAG_CHANNELS
• prop_channel_active
• prop_channel_pairs
• propagatable_parse_body
• propagatable_register!
• check_propagatable_contracts
• factory
• port_opt_view
• obs_weights_view

@fprop field

Field tag for use inside a @propagatable struct body. Marks the field as participating in factory propagation — factory_child will be called on it when factory is invoked on the enclosing struct.

Algorithm

The tag never expands. @propagatable runs first and consumes it, so the steps below are what happens to the tagged field, not what this macro does.

1. propagatable_parse_body peels the tag off the field, records the field name under :fprop, and puts the stripped field into the struct body. Neither Julia nor a wrapped macro such as @concrete ever sees the tag.

2. prop_channel_active reads the recorded name. The channels this tag gates are the factory channel and the obs channel, and each active channel makes @propagatable emit one method.

3. prop_channel_pairs builds the keyword pair of the field for each emitted method, and prop_tag_expr gives the value:

   • factory channel: factory_child(x.field, args...; kwargs...), which recurses into the child.
   • obs channel: obs_weights_view(x.field, i), which recurses into the child on the observation axis.

4. The generated method rebuilds the struct with its keyword constructor, so every validation the constructor carries runs again on the propagated value.

Step 3 is the whole meaning of the tag. The same tag has two transforms, because a channel decides what a tag means. The obs channel does not gate on @fprop, so a struct whose only tag is @fprop gains no obs_weights_view method; the tag is consulted there only when a sibling field carries @wprop.

This macro body itself raises an error. It is reached only when the tag is written outside a @propagatable struct body, where nothing consumed it.

Related

• @propagatable
• @vprop
• @wprop
• factory
• factory_child
• obs_weights_view
• PROP_TAG_CHANNELS

@vprop field

Field tag for use inside a @propagatable struct body. Marks the field as participating in port_opt_view propagation — port_opt_view will be called on it when a view (index selection) is propagated through the enclosing struct.

Orthogonal to @fprop; the two may be stacked on one field (@fprop @vprop field) when it participates in both factory and view propagation.

Algorithm

The tag never expands. @propagatable runs first and consumes it, so the steps below are what happens to the tagged field, not what this macro does.

1. propagatable_parse_body peels the tag off the field, records the field name under :vprop, and puts the stripped field into the struct body. Neither Julia nor a wrapped macro such as @concrete ever sees the tag.
2. prop_channel_active reads the recorded name. The channels this tag gates are the view channel alone, and each active channel makes @propagatable emit one method.
3. prop_channel_pairs builds the keyword pair of the field for each emitted method, and prop_tag_expr gives the value: view_child(x.field, i, args...), which is port_opt_view(x.field, i, args...) for every value but a precomputed optimisation result, kept as it is. The channel forwards the threaded tail and no keywords.
4. The generated method rebuilds the struct with its keyword constructor, so every validation the constructor carries runs again on the propagated value.

Step 3 is the whole meaning of the tag. @vprop appears in one channel, so it carries one transform and no channel can give it a second meaning. The index that the method threads selects assets; the observation axis has its own verb, obs_weights_view.

This macro body itself raises an error. It is reached only when the tag is written outside a @propagatable struct body, where nothing consumed it.

Related

• @propagatable
• @fprop
• port_opt_view
• PROP_TAG_CHANNELS

@pprop field

Field tag for use inside a @propagatable struct body. Marks the field as prior-selected: when factory(x, pr::AbstractPriorResult, …) is invoked, the field is set to sel(getfield(x, :field), getproperty(pr, :field)) — the risk-measure value if present, else the same-named moment from the prior result.

Orthogonal to, and stackable with, @wprop (@pprop @wprop w gives a weights field both a prior factory and an ObsWeights factory) or @fprop; @pprop wins in the prior method. Mutually exclusive with @cprop on a single field.

Algorithm

The tag never expands. @propagatable runs first and consumes it, so the steps below are what happens to the tagged field, not what this macro does.

1. propagatable_parse_body peels the tag off the field, records the field name under :pprop, and puts the stripped field into the struct body. Neither Julia nor a wrapped macro such as @concrete ever sees the tag.
2. prop_channel_active reads the recorded name. The channels this tag gates are the prior channel alone, and each active channel makes @propagatable emit one method.
3. prop_channel_pairs builds the keyword pair of the field for each emitted method, and prop_tag_expr gives the value: sel(x.field, getproperty(pr, :field)). The prior result supplies the property of the same name as the field, so the tag names no source of its own.
4. The generated method rebuilds the struct with its keyword constructor, so every validation the constructor carries runs again on the propagated value.

Step 3 is the whole meaning of the tag. @pprop is first in the prior channel's precedence, so a field carrying both @pprop and @fprop takes the prior transform on that channel and the factory transform on the factory channel.

This macro body itself raises an error. It is reached only when the tag is written outside a @propagatable struct body, where nothing consumed it.

Related

• @propagatable
• @cprop
• @wprop
• factory
• PROP_TAG_CHANNELS

@wprop field

Field tag for use inside a @propagatable struct body. Marks the field as an observation-weights slot: when factory(x, w::ObsWeights, …) is invoked, the field is replaced by the incoming weights via _wprop; when no ObsWeights is threaded, it is left unchanged.

Distinct from @fprop, which recurses into a sub-estimator value and leaves a nothing value untouched. A weights field defaults to nothing (meaning "uniform") and must become the incoming weights — so it cannot share @fprop's nothing-handling without the two semantics colliding. Use @wprop for the w/weights field and @fprop for sub-estimators.

Algorithm

The tag never expands. @propagatable runs first and consumes it, so the steps below are what happens to the tagged field, not what this macro does.

1. propagatable_parse_body peels the tag off the field, records the field name under :wprop, and puts the stripped field into the struct body. Neither Julia nor a wrapped macro such as @concrete ever sees the tag.

2. prop_channel_active reads the recorded name. The channels this tag gates are the factory channel and the obs channel, and each active channel makes @propagatable emit one method.

3. prop_channel_pairs builds the keyword pair of the field for each emitted method, and prop_tag_expr gives the value:

   • factory channel: _wprop(x.field, args...; kwargs...), which replaces the field with an incoming ObsWeights and keeps it when none is threaded.
   • obs channel: nothing_scalar_array_getindex(x.field, i), which indexes the value already there to the selected observations. Indexing rather than viewing is what keeps the AbstractWeights subtype.

4. The generated method rebuilds the struct with its keyword constructor, so every validation the constructor carries runs again on the propagated value.

Step 3 is the whole meaning of the tag. The two channels do different things to the same field, which is the one place a reader learns that factory and obs_weights_view are not two names for one operation. @wprop is also the only tag that gates the obs channel, so a field opts a struct into obs_weights_view by carrying this tag and no second one.

This macro body itself raises an error. It is reached only when the tag is written outside a @propagatable struct body, where nothing consumed it.

Related

• @propagatable
• @fprop
• @pprop
• factory
• _wprop
• obs_weights_view
• ObsWeights
• PROP_TAG_CHANNELS

@cprop field

Field tag for use inside a @propagatable struct body. Marks the field as context-selected: when factory(x, pr::AbstractPriorResult, …) is invoked, the field is set to sel(getfield(x, :field), _ctx(args...)) — the risk-measure value if present, else the threaded optimiser value (a solver) located by type in the variadic tail. Used for slv fields, whose source is a threaded argument rather than the prior. Mutually exclusive with @pprop on a single field.

Algorithm

The tag never expands. @propagatable runs first and consumes it, so the steps below are what happens to the tagged field, not what this macro does.

1. propagatable_parse_body peels the tag off the field, records the field name under :cprop, and puts the stripped field into the struct body. Neither Julia nor a wrapped macro such as @concrete ever sees the tag.
2. prop_channel_active reads the recorded name. The channels this tag gates are the prior channel alone, and each active channel makes @propagatable emit one method.
3. prop_channel_pairs builds the keyword pair of the field for each emitted method, and prop_tag_expr gives the value: sel(x.field, _ctx(args...)). _ctx finds the value by type in the threaded tail, so the source is an argument and not the prior result.
4. The generated method rebuilds the struct with its keyword constructor, so every validation the constructor carries runs again on the propagated value.

Step 3 is the whole meaning of the tag. @cprop follows @pprop in the prior channel's precedence, and the two are mutually exclusive on one field.

This macro body itself raises an error. It is reached only when the tag is written outside a @propagatable struct body, where nothing consumed it.

Related

• @propagatable
• @pprop
• factory
• PROP_TAG_CHANNELS

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(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(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(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(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