Pre-calculate the FixedRateCoupon::amount()

[ralfkonrad]

We can calculate the FixedRateCoupon::amount() in the constructor as it will never change.

Therefore, we can skip calling virtual void LazyObject::calculate() const each time the amount is requested. That the amount() is never requested is very unlikely (probably only when the FixedRateCoupon is already expired) so this might slightly improve performance.

[pcaspers]

When you build real trades there are usually expired coupons and maybe many of them. On the other hand LazyObject::calculate() only checks one boolean once the coupon is calculated. I doubt this is noticeable in any real set up?

It is also not guaranteed that the nominal won't change after construction since nominal() is virtual and could be overridden in a class that derives from FixedRateCoupon.

[coveralls]

coverage: 71.901% (-0.002%) from 71.903% when pulling 5511aad on ralfkonrad:very_lazy_fixedratecoupon into 94eae2c on lballabio:master.

[ralfkonrad]

It is also not guaranteed that the nominal won't change after construction since nominal() is virtual and could be overridden in a class that derives from FixedRateCoupon.

Business-wise it seems to be very unlikely that someone passes a nominal especially to a FixedRateCoupon to overrides its value later on. At least I'm not aware of a real Coupon where the nominal is calculated based on some rules. That's typically what the amount() is used for.

But true, from a OOP perspective that's technically allowed. So, let's keep it as it is.

---

When you build real trades there are usually expired coupons and maybe many of them.

IMO this isn't a real argument. If performance is really important and very 2ms extra counts then I wouldn't load an unused Coupon for such a trade at all. And if they are expired but still somehow used is normally equivalent with FixedRateCoupon::amount() is also needed.

On the other hand LazyObject::calculate() only checks one boolean once the coupon is calculated. I doubt this is noticeable in any real set up?

Probably not. I think I was biased by the old, pre-lazy-cashflow implementation where the amount() was calculated each time it was requested which I found an overkill. But I'm curious, I will give it a try and benchmark it.

[pcaspers]

Business-wise it seems to be very unlikely that someone passes a nominal especially to a FixedRateCoupon to overrides its value later on. At least I'm not aware of a real Coupon where the nominal is calculated based on some rules. That's typically what the amount() is used for.

Here is an example https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/floatingannuitycoupon.cpp#L65. You could do something similar for the fixed rate coupon if want to model a float-to-fixed annuity loan.

IMO this isn't a real argument.

Well, we do this in ORE. I think it would be quite messy if we would optimise away expired coupons. In general you want to represent your trade as is, not all analytics / reports are as simple as pricing a trade on a fixed evaluation date.