QuantLib › quantlib-dev

precision in cubicsplineinterpolation (and in general)

Classic

List

Threaded

7 messages Options

Sylvain Bertrand

precision in cubicsplineinterpolation (and in general)

Hi,

As I'm working on spline implementations, I've encountered issues with the precision of Real.

The calculations I'm doing rely heavily on precision, and it is not an option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667.

2 things here:

- I want to raise to your attention the fact that the current spline implementation is also affected by this (though to a lesser extent)

- I would like to know if any of you have used workarounds for this, and what you did

Thanks

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

Sylvain Bertrand

Re: precision in cubicsplineinterpolation (and in general)

I assume this has never been an issue for anyone...

I've looked around in the limits.h and other headers in the stdlib and boost, and I've come to the conclusion that increasing the precision of the Real would probably have a lot of impacts.

Is anyone here familiar with those matters?

On 7/22/08, Sylvain Bertrand <[hidden email]> wrote:

Hi,

As I'm working on spline implementations, I've encountered issues with the precision of Real.

The calculations I'm doing rely heavily on precision, and it is not an option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667.

2 things here:

- I want to raise to your attention the fact that the current spline implementation is also affected by this (though to a lesser extent)

- I would like to know if any of you have used workarounds for this, and what you did

Thanks

Sylvain

Sylvain Bertrand

Re: precision in cubicsplineinterpolation (and in general)

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.

If QL_REAL was changed to float, it would produce the same error, and I would need 0.f here.

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?

Let me know how you guys feel...

On 7/23/08, Sylvain Bertrand <[hidden email]> wrote:

I assume this has never been an issue for anyone...

I've looked around in the limits.h and other headers in the stdlib and boost, and I've come to the conclusion that increasing the precision of the Real would probably have a lot of impacts.

Is anyone here familiar with those matters?

On 7/22/08, Sylvain Bertrand <[hidden email]> wrote:

Hi,

As I'm working on spline implementations, I've encountered issues with the precision of Real.

The calculations I'm doing rely heavily on precision, and it is not an option for me to consider 1e-20 as 0 or 2.0/3 as 0.666667.

2 things here:

- I want to raise to your attention the fact that the current spline implementation is also affected by this (though to a lesser extent)

- I would like to know if any of you have used workarounds for this, and what you did

Thanks

Sylvain

Luigi Ballabio

Re: precision in cubicsplineinterpolation (and in general)

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.

> 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.

Luigi

--

Weiler's Law:
Nothing is impossible for the man who doesn't have to
do it himself.

-------------------------------------------------------------------------
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

Sylvain Bertrand

Re: precision in cubicsplineinterpolation (and in general)

On 8/4/08, Luigi Ballabio <[hidden email]> wrote:

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

Luigi Ballabio

Re: precision in cubicsplineinterpolation (and in general)

Hi Sylvain,
apologies for the long silence.

On Mon, 2008-08-04 at 11:55 -0400, Sylvain Bertrand wrote:

> 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.

You're right, this is not a good 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.

Possibly. It would make the Matrix code quite a bit more complicated,
though. Do you think it would be possible to improve the accuracy of
matrix calculations while keeping the double type? Maybe by using some
smarter algorithms instead of the naive ones we used?

Later,
Luigi

--

The rule on staying alive as a forecaster is to give 'em a number or
give 'em a date, but never give 'em both at once.
-- Jane Bryant Quinn

-------------------------------------------------------------------------
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

Sylvain Bertrand

Re: precision in cubicsplineinterpolation (and in general)

Hi Luigi,

On Fri, Aug 22, 2008 at 11:52 AM, Luigi Ballabio <[hidden email]> wrote:

Possibly. It would make the Matrix code quite a bit more complicated,
though. Do you think it would be possible to improve the accuracy of
matrix calculations while keeping the double type? Maybe by using some
smarter algorithms instead of the naive ones we used?

That sounds unlikely. Here we're talking about basic algebra, it's not an "optimization with constraint" problem.
Would a generic (real) matrix template not be useful though?
I agree it would probably involve a significant amount of work in that class, but not outside if by default we consider Matrix as Matrix<QL_REAL>.

Let me know what you think.

Sylvain