Closed scchess closed 9 years ago
I am away with limited connectivity right now, but I will try to take a closer look either in a few days or when I get back.
Do you have a worked example where this helps?
The problem with the current code is that the date counting is simply just approximation. This is very bad for a quantitative library where exact calculation is expected. There is already an issue raised at: https://github.com/eddelbuettel/rquantlib/issues/15. The same idea can be applied to fixed-income instruments where the time-to-maturity is absolutely critical. So far, I've only done it to the vanilla option because it's the simplest and allow you a chance to review before I spread my efforts to other instruments.
Let's say if I want to price an European option with year=1.0. Unfortunately, the current BS pricing code doesn't return me with something that is consistent with an online Black-Scholes calculator. You and I can look into the source code, but most users can't. They wouldn't have any idea why there is a small difference for such a simple option-pricing formula. Remember, they give RQuantLib a parameter year=1.0, they wouldn't know that QuantLib actually expects a date object.
Let the user to decide whatever day-counting that they want to use, we shouldn't put too much restriction on it. This should improve the overall accuracy of the pricing code. We can extend the idea to other instruments.
I can add a worked example, no problem.
The only real solution is to switch to double
instead of int
for date differences. That is a QuantLib issue, and there are some patches.
This simply is not something we can shoehorn easily in from this end.
Added a new R function for setting the global day-counter. This allow us to remove the hack in vanilla.cpp. Now, we can choose whatever day-counter we're interested before pricing a European option. This will lead to more accurate results.