introduce scale for rate helpers

[pcaspers]

resolves #2396

Question:s How backwards compatible do we want to be, i.e.

• can we maybe incorporate the scale into the quoteError()?
• do we want an option to enable the scaling in IterativeBootstrap (maybe yes, because it is widely used and we might change many results) and in GlobalBootstrap (maybe not necessary, since it is probably not so commonly used)

[coveralls]

coverage: 74.356% (+0.001%) from 74.355% when pulling 1c155151f2bda9545973e14f2863d0217aadc310 on pcaspers:ratehelper_scale into 7fa295f752a00eff4abcd7c55c1e2d055cb300fb on lballabio:master.

[eltoder]

I think this is not the right way to go about this.

In general, for global bootstrap we can assign weights to benchmarks. There are many ways to come up with weights, generally based on liquidity and "importance", so weights should be provided by the user. This is how we deal with futures in our code -- we scale their weights by 1e-2. Currently, global bootstrap does not allow passing custom weights -- all quote errors get a weight of 1. (Partially because of this we pass an empty list of helpers into the curve and add everything via additionalHelpers and additionalPenalties.) I think it would be good to allow passing custom weights into the bootstrapper. This is a generic and backwards compatible change that gives a lot of flexibility. You can also use it to solve your issue with normalizing futures vs swaps.

If we think that this is not good enough and want a more out-of-the-box experience, I think we should change quoteError(). We could just add a scale to the base class and multiply the difference inside of quoteError() like you are suggesting in the comment. But a more generic thing to do is to make quoteError virtual. Then we can override it for futures to just return values in the rates space directly. I think this is cleaner.

Other notes on your change:

1. I agree that the scale for futures is 0.01, but not sure why are you adding 100 for swaps? Swaps are already in the rates space, so should just be 1. Also, you missed another constructor and other types of swaps (at least OIS, but probably others too).
2. For the iterative bootstrap the scale of errors does not make a difference, because the accuracy is for the x values (dfs or rates), not for the f values (errors).

[pcaspers]

Thanks for your feedback @eltoder. The changes were not meant to be complete. I just wanted to sketch one possible approach to start the discussion.

You are right, what I did is not consistent, I wanted to scale all quote errors to order 1, i.e., to scale the swap quote error by 1E2, but leave the future quote error untouched.

Anyway, I agree that user-provided weights are more flexible, and I think we don't need to normalize the orders of the quote errors then. I can make this change in this branch here.

And agreed on the IterativeBootstrap, this is independent of the scale of the errors.

[eltoder]

If you want to scale swaps, you'll also need to scale deposits, fras, etc? I think there are fewer helpers for futures (just regular and overnight), so scaling futures seems easier. But in any case, if you go with custom weights in global bootstrap, everyone can do their own thing.

[pcaspers]

Yes, indeed. The custom weights are a much better approach.