Agreed that calculating a number already present for lookup isn’t efficient.

However, suppose you want to parallel shift the forecast (ibor) curve. Specifically …

- extract the index curve from RatesProvider
- wrap it withing ParallelShiftedCurve.absolute(…)
- build new rates provider using the wrapped forecast curve

If you use this new rate provider to calculate par swap rates, the first floating point cash flow will be wrong, because it uses the reset rate from the original curve.

However, if you change the code in DiscountIborIndexRate::rate() to pull from the time series if the fixing date is before the valuation date (instead of on or before the valuation date) then the first floating point cash flow will be correct (i.e. consistent with the shift) since it will be calculated.

We could generalize this to any case where the underlying forecast continuously compounded zero rates are adjusted (e.g. parallel shifts, monte carlo calcl, etc.) . Calculating the first floating point would give the same reset rate that went into the calibration for an *unmodified* curve (albeit slightly sub-optimal in terms of efficiency) and give a *consistent* first floating point cash flow when the underlying zero rates are modified.

Does this make sense or is this just wrong?