Implement relevanceRates in CallSpecifiedMultiProduct and CallSpecifiedPathwiseMultiProduct - #2852
Open
Nityahapani wants to merge 1 commit into
Conversation
…edPathwiseMultiProduct
Both constructors merged evolution times from the underlying product,
exercise times, rebate product, and strategy times, but passed no
relevanceRates to EvolutionDescription, leaving it to default to the
full [0, numberOfRates] range for every step:
// TODO: add relevant rates
evolution_ = EvolutionDescription(rateTimes1, mergedEvolutionTimes);
This means downstream simulation engines had no information about which
rates are actually needed at each step and were forced to evolve all
rates at every merged step, even when only a narrow subset is required.
Implementation:
For each merged evolution step, the relevant rate range is the union of:
- underlying_.evolution().relevanceRates()[undStep] when isPresent_[0][i]
- rebate_.evolution().relevanceRates()[rebStep] when isPresent_[2][i]
The step counters undStep and rebStep are advanced independently as we
walk through merged steps, mapping each merged step back to its source
product's step index via the isPresent_ flags.
For purely structural steps (exercise-only or strategy-only, where
neither underlying nor rebate is active), we conservatively fall back
to the full rate range [0, numberOfRates] since no narrower bound can
be inferred without querying the strategy itself.
The same logic is applied consistently to both CallSpecifiedMultiProduct
(multistep) and CallSpecifiedPathwiseMultiProduct (pathwise).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both constructors merged evolution times from the underlying product, exercise times, rebate product, and strategy times, but passed no relevanceRates to EvolutionDescription, leaving it to default to the full [0, numberOfRates] range for every step:
This means downstream simulation engines had no information about which rates are actually needed at each step and were forced to evolve all rates at every merged step, even when only a narrow subset is required.
Implementation:
For each merged evolution step, the relevant rate range is the union of:
The step counters undStep and rebStep are advanced independently as we walk through merged steps, mapping each merged step back to its source product's step index via the isPresent_ flags.
For purely structural steps (exercise-only or strategy-only, where neither underlying nor rebate is active), we conservatively fall back to the full rate range [0, numberOfRates] since no narrower bound can be inferred without querying the strategy itself.
The same logic is applied consistently to both CallSpecifiedMultiProduct (multistep) and CallSpecifiedPathwiseMultiProduct (pathwise).