You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OIS swaps have coupons determined by compounded daily interest rates settled every few months. The valuation of future coupons is computationally similar to the valuation of a LIBOR payment, in that the valuation involves the ratio of two discount factors associated with the start and end of the accrual period. A problem can arise on seasoned trades in the current period. A naïve implementation will, for each trade, look up fixings for each business day, and compute the compounded growth of those fixing values. This calculation potentially involving hundreds of multiplications which is much slower than simply computing the coupon amount with a single LIBOR fixing.
It then describes a process for making this faster. Basically, you compound together your fixings to make a time series of compounded fixings, starting from an arbitrary origin, then to calculate a compounded rate over some span of time, you take the compounded rates at the start and end, and divide them. It's sort of the telescopic formula backwards, or put another way, basic arithmetic. If you take the evaluation date as the origin, and compound backwards (so the time series grows into the past), then you don't even need to divide, it's already the number you need.
Perhaps we could add a method Rate OvernightIndex::compoundedFixings(const Date& fromFixingDate, const Date& toFixingDate), then implement it on top of a compounded time series. The compounded series could be generated on demand from the individual historical fixings. Base it on the evaluation date, and throw away the series if the evaluation date changes.
There should be no, or negligible, user-visible change, just better performance when calculating with large numbers of seasoned OISs.
You may well think that use case is not important enough to worry about. I get the impression from the mailing list that this is not the focus of interest for most QuantLib users!
The text was updated successfully, but these errors were encountered:
This issue was automatically marked as stale because it has been open 60 days with no activity. Remove stale label or comment, or this will be closed in two weeks.
As a blog post points out:
It then describes a process for making this faster. Basically, you compound together your fixings to make a time series of compounded fixings, starting from an arbitrary origin, then to calculate a compounded rate over some span of time, you take the compounded rates at the start and end, and divide them. It's sort of the telescopic formula backwards, or put another way, basic arithmetic. If you take the evaluation date as the origin, and compound backwards (so the time series grows into the past), then you don't even need to divide, it's already the number you need.
Perhaps we could add a method
Rate OvernightIndex::compoundedFixings(const Date& fromFixingDate, const Date& toFixingDate)
, then implement it on top of a compounded time series. The compounded series could be generated on demand from the individual historical fixings. Base it on the evaluation date, and throw away the series if the evaluation date changes.There should be no, or negligible, user-visible change, just better performance when calculating with large numbers of seasoned OISs.
You may well think that use case is not important enough to worry about. I get the impression from the mailing list that this is not the focus of interest for most QuantLib users!
The text was updated successfully, but these errors were encountered: