Posted by
Sylvain Bertrand on
URL: http://quantlib.414.s1.nabble.com/precision-in-cubicsplineinterpolation-and-in-general-tp12216p12220.html
On Wed, 2008-07-23 at 15:53 -0400, Sylvain Bertrand wrote:
> Anyway, I tried to change the QL_REAL from double to long double (it
> might actually partially solve my issue).
>
> But then I faced errors calling std::max with a long double on one
> side, and 0. on the other side. As everyone knows, 0. is a double, and
> max can only be called with two args of the same type. I would need
> 0.L here.
Yes, or we might specify std::max<Real>(x, 0) so that the 0 gets
converted to the right type.
In that case we would need to change all the calls to std::max on all the files (at least for consistency).
Is there some kind of approval process, to ensure the owners of each file (or the whole QL group) are ok with that?
> I'm quite confident on the fact that less than 0.1% of users have ever
> thought of changing QL_REAL, but what if? Is QuantLib supposed to
> support other types of Real?
We used the QL_REAL thing so that, in case one wanted to try and change
the default float type, we didn't have double hard-coded everywhere. But
we never tried very hard to make the library even compile with different
types.
As for your spline calculations, if you need long doubles, just go ahead
and use long double.
As the implementation relies heavily on matrix operations, I would need to use only long double matrices, which work if I set QL_REAL to long double for the whole library, since matrices are forced to the QL_REAL type.
"QL_REAL = long double" would then have to be the default for QL releases, otherwise the user would run the risk of using the cubic splines with very poor results (in that case there should also be a warning to prevent the user from changing the setting back to double and use the splines).
Is that something that would be acceptable? I personally don't think of it as the best option.
Another option would be to transform the current Matrix class into a template to support different types, which would give each piece of code the freedom to use the default QL_REAL or use more precision when needed.
Let me know what you think.
Sylvain
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev