50Y off-par OIS calculating NPV, Zero Coupon Rate Delta and Zero Coupon Rate Gamma (no mathematical simplifications (e.g. using an exchange of principle to simulate floating leg, pretending their are no holidays / weekends etc)).Took me 3 seconds which seems painfully slow on an "average piece of kit" using a single threaded algorithm. Please tell me it can be done faster, and if so by how much and on what kind of hardware and what kind of software tricks I should be employing.ThanksRiskUser

I do not know what it is. But may be you can state it in more mathematical terms,so one can see, how it *might* be calculated (despite the possibility, that it is nothandled that way by practitioners) and not just using your particular way.

Does it involve only pricing from an already-built curve, or may involve bumping/rebuilding curve? Building OIS curve may be expensive.

OIS - Overnight Index Swap. So in this case I am assuming daily compounded rate (on good business days) paid annually.QuoteOriginally posted by: AVtI do not know what it is. But may be you can state it in more mathematical terms,so one can see, how it *might* be calculated (despite the possibility, that it is nothandled that way by practitioners) and not just using your particular way.

Interesting observation. For pricing you can assume a pre-bootstrapped curve.There are two options for calculating the risk:1) Bump the curve practically2) Calculate the derivatives at the cashflow dates and then project the results to some pre-defined grid point structureI like 2) but am willing to "compromise" for speed.QuoteOriginally posted by: zhouxingDoes it involve only pricing from an already-built curve, or may involve bumping/rebuilding curve? Building OIS curve may be expensive.

QuoteThere are two options for calculating the risk:1) Bump the curve practically2) Calculate the derivatives at the cashflow dates and then project the results to some pre-defined grid point structureI like 2) but am willing to "compromise" for speed.Yes, (2) is much faster than (1) and the risk is much "clean", but some traders believe/prefer a "wavy" risk using (1). This is a "common" feature. Your OP specifically mentioned the OIS curve. To correctly build an OIS is much more expensive than to build a 3M/6M LIBOR curve because of the daily compounding feature. So everything else being equal, it will take longer to get OIS risk.

QuoteOriginally posted by: RiskUser50Y off-par OIS calculating NPV, Zero Coupon Rate Delta and Zero Coupon Rate Gamma (no mathematical simplifications (e.g. using an exchange of principle to simulate floating leg, pretending their are no holidays / weekends etc)).It is not very clear to me what you are doing. Is it- Computing the NPV, delta and gamma of an IRS in multi-curve (e.g. with OIS discounting).- Computing the NPV, ... of an OIS in multi-curve.Is the "Zero Coupon Rate Gamma" the full cross-gamma (matrix nxn with n the number of point on your curve) or just one gamma for parallel curve shift? Does the time include the construction of the relevant curves?Does the time include the computation of the instrument dates or only its pv, ... supposing that the dates are already computed?What do you mean by "no mathematical simplification"? Is it no "approximation" (the result should be exact) or "no efficient implementation" (only direct application of the standard formulas).I checked on my desktop for the following:Constructing a 50Y OIS (all dates with market conventions): 96 msPricing the OIS in multi-curve framework (one discounting and forward ON): <1 msDelta to zero-coupon rate for the OIS in multi-curve: 1.5 ms. The delta is computed using algorithmic differentiation at each cash-flow date (similar to your 2) below).I don't have the gamma directly but at worst it could be computed by finite difference (bump and recompute) on the delta. It will depend on the number of point on your curve. If you have 20 point on your curve, that would be around 30 ms 1.5ms x 20).The most time consuming task is (as often for simple instruments) the date generation from market conventions.

>>It is not very clear to me what you are doing. Is it>>- Computing the NPV, delta and gamma of an IRS in multi-curve (e.g. with OIS discounting).>>- Computing the NPV, ... of an OIS in multi-curve.Computing the NPV, delta and gamma of an OIS in a multi-curve framework>>Is the "Zero Coupon Rate Gamma" the full cross-gamma (matrix nxn with n the number of point on your curve) or just one gamma for parallel curve shift? Full cross-gamma>>Does the time include the construction of the relevant curves?No>>Does the time include the computation of the instrument dates or only its pv, ... supposing that the dates are already computed?Computations are from scratch (i.e. dates are not already computed)>>What do you mean by "no mathematical simplification"? Is it no "approximation" (the result should be exact) or "no efficient implementation" (only direct >>application of the standard formulas).Basically this means that I need to calculate all the individual Foward Rates observing the full day count convention and date roll conventions, compound up annually and finally observe the rounding rules of the underlying index definition to obtain the foward cashflows. In other absolutely inch perfect for defining the future cashflows versus the current cashflow.>>Pricing the OIS in multi-curve framework (one discounting and forward ON): <1 ms>>Delta to zero-coupon rate for the OIS in multi-curve: 1.5 ms. The delta is computed using algorithmic differentiation at each cash-flow date (similar to> >>your 2) below).Is this using a 3rd party piece of software or something you have built in-house. Do you know if it is a multi-threaded or single-threaded algorithm? I agree with your point around dates, but my gut feel is that I am being killed on the interpolation routines (not much I can do about it as it is 3rd party software).QuoteOriginally posted by: mathmarcQuoteOriginally posted by: RiskUser50Y off-par OIS calculating NPV, Zero Coupon Rate Delta and Zero Coupon Rate Gamma (no mathematical simplifications (e.g. using an exchange of principle to simulate floating leg, pretending their are no holidays / weekends etc)).It is not very clear to me what you are doing. Is it- Computing the NPV, delta and gamma of an IRS in multi-curve (e.g. with OIS discounting).- Computing the NPV, ... of an OIS in multi-curve.Is the "Zero Coupon Rate Gamma" the full cross-gamma (matrix nxn with n the number of point on your curve) or just one gamma for parallel curve shift? Does the time include the construction of the relevant curves?Does the time include the computation of the instrument dates or only its pv, ... supposing that the dates are already computed?What do you mean by "no mathematical simplification"? Is it no "approximation" (the result should be exact) or "no efficient implementation" (only direct application of the standard formulas).I checked on my desktop for the following:Constructing a 50Y OIS (all dates with market conventions): 96 msPricing the OIS in multi-curve framework (one discounting and forward ON): <1 msDelta to zero-coupon rate for the OIS in multi-curve: 1.5 ms. The delta is computed using algorithmic differentiation at each cash-flow date (similar to your 2) below).I don't have the gamma directly but at worst it could be computed by finite difference (bump and recompute) on the delta. It will depend on the number of point on your curve. If you have 20 point on your curve, that would be around 30 ms 1.5ms x 20).The most time consuming task is (as often for simple instruments) the date generation from market conventions.

QuoteOriginally posted by: RiskUserBasically this means that I need to calculate all the individual Foward Rates observing the full day count convention and date roll conventions, compound up annually and finally observe the rounding rules of the underlying index definition to obtain the foward cashflows. In other absolutely inch perfect for defining the future cashflows versus the current cashflow.Is this using a 3rd party piece of software or something you have built in-house. Do you know if it is a multi-threaded or single-threaded algorithm? I agree with your point around dates, but my gut feel is that I am being killed on the interpolation routines (not much I can do about it as it is 3rd party software).The Fed Fund and EONIA swaps pay a rate which is compounded in the natural way for overnight rates (\prod 1+\delta_i r_i). So you don't need the estimation of the daily forward and their composition, it is equivalent to compute the payment period (annual) forward rate. The only point that is not taken into account in that efficient procedure is the rounding. Eonia rate (in percent) is displayed to three decimal places (one tenth of a basis point). Do you think it is important to have the correct rounding procedure for the valuation?You ask about the software I used. I'm working for a software provider; so the software is build in-house but at the same time third party for any one else. The quant library we are producing is open source (like most of our system). The library being open source, the last par of your comment does not apply: it is a third party software, but if you want to tweak (improve) it, you are free to do so. The algorithm used for OIS are not multi-threaded (the global system is definitively multi-thread). The figures I mentioned are from a single thread. They are from an Eclipse test, running them directly should be a little bit faster. The code is in Java. So if you run it several time, the JVM "hot spot" the code and is faster on the second run. If I run the tests twice, on the second run I get: 5 ms for the construction, 15 ms for 100 x price and 120 ms for 100 x delta (I use 100 prices, if I use 1 price, the results come as 0 ms!).QuoteOIS swap P50Y (construction): 5 ms100 OIS swap P50Y (price): 14 ms100 OIS swap P50Y (delta): 111 msLet me advertise (discreetly) for it: The company is called OpenGamma (www.opengamma.com), the code can be obtained from http://developers.opengamma.com/. The OIS is part of the next version (1.0) that will be released on April 2.

>>So you don't need the estimation of the daily forward and their composition, it is equivalent to compute the payment period (annual) forward rate. The only point that is not >>taken into account in that efficient procedure is the rounding. Eonia rate (in percent) is displayed to three decimal places (one tenth of a basis point). Do you think it is >>important to have the correct rounding procedure for the valuation?Depends on the user, from my perspective I need full accuracy. But that I mean observing the rounding rules of the index and the holiday and date convention of the interim foward rates as they are compounded up.Will certainly look at the site below.Cheers!QuoteOriginally posted by: mathmarcQuoteOriginally posted by: RiskUserBasically this means that I need to calculate all the individual Foward Rates observing the full day count convention and date roll conventions, compound up annually and finally observe the rounding rules of the underlying index definition to obtain the foward cashflows. In other absolutely inch perfect for defining the future cashflows versus the current cashflow.Is this using a 3rd party piece of software or something you have built in-house. Do you know if it is a multi-threaded or single-threaded algorithm? I agree with your point around dates, but my gut feel is that I am being killed on the interpolation routines (not much I can do about it as it is 3rd party software).The Fed Fund and EONIA swaps pay a rate which is compounded in the natural way for overnight rates (\prod 1+\delta_i r_i). So you don't need the estimation of the daily forward and their composition, it is equivalent to compute the payment period (annual) forward rate. The only point that is not taken into account in that efficient procedure is the rounding. Eonia rate (in percent) is displayed to three decimal places (one tenth of a basis point). Do you think it is important to have the correct rounding procedure for the valuation?You ask about the software I used. I'm working for a software provider; so the software is build in-house but at the same time third party for any one else. The quant library we are producing is open source (like most of our system). The library being open source, the last par of your comment does not apply: it is a third party software, but if you want to tweak (improve) it, you are free to do so. The algorithm used for OIS are not multi-threaded (the global system is definitively multi-thread). The figures I mentioned are from a single thread. They are from an Eclipse test, running them directly should be a little bit faster. The code is in Java. So if you run it several time, the JVM "hot spot" the code and is faster on the second run. If I run the tests twice, on the second run I get: 5 ms for the construction, 15 ms for 100 x price and 120 ms for 100 x delta (I use 100 prices, if I use 1 price, the results come as 0 ms!).QuoteOIS swap P50Y (construction): 5 ms100 OIS swap P50Y (price): 14 ms100 OIS swap P50Y (delta): 111 msLet me advertise (discreetly) for it: The company is called OpenGamma (www.opengamma.com), the code can be obtained from http://developers.opengamma.com/. The OIS is part of the next version (1.0) that will be released on April 2.

QuoteThe Fed Fund and EONIA swaps pay a rate which is compounded in the natural way for overnight rates (\prod 1+\delta_i r_i). So you don't need the estimation of the daily forward and their composition, it is equivalent to compute the payment period (annual) forward rate. This is correct (and saves lot of computation) for and OIS floating/fix swap. However you probably cannot do this for an OIS basis swap where spread is on the OIS side.

QuoteOriginally posted by: zhouxingThis is correct (and saves lot of computation) for and OIS floating/fix swap. However you probably cannot do this for an OIS basis swap where spread is on the OIS side.I have never traded OIS with spread. Where is the spread? Is it on the daily rates or on the final rate. With a spread of s, is itor is it?