Re: [lmi] Question about "Numeric summary" logic

[Greg Chicares]

On 2017-07-30 19:45, Vadim Zeitlin wrote:
> On Sun, 30 Jul 2017 02:57:41 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> The inline documentation for set_run_basis_from_cloven_bases()
[...]
> GC> /// Only these combinations ever arise:
> GC> ///   {CF, GF, MF, CZ, GZ, CH, GH} actually-used bases
> GC> /// of which only these subsets are used:
> GC> ///   {CF, GF, MF                } illustration reg
> GC> ///   {CF, GF,     CZ, GZ        } normal NASD
> GC> ///   {CF, GF,     CZ, GZ, CH, GH} three-rate NASD

BTW, each double-letter basis takes some time to run. Running all seven
when in practice only three or four are used would double the run time.

>  This also answers my (unasked) question about why neither CZ nor GZ were
> available in my (regular) illustration. I ran into this when trying to
> translate the max-lapse-year definition from XSLT to C++: in XSLT it's
> defined as max(LapseYear_Current, LapseYear_Guaranteed,
> LapseYear_CurrentZero, LapseYear_GuaranteedZero) and relies on the fact
> that the undefined variables evaluate to 0 -- while in C++ trying to access
> them results in an exception.

Now that you point it out, this is the "get-max-lapse-year" template,
which is called only through the trivial "max-lapse-year-text" template,
which is used only to set "max-lapse-year", which I guess is used to
decide how many rows to print in each table. It's wrong because it omits
"MF". It's also wrong because it omits "CH" and "GH": even though the
"*H" bases are no longer used in practice, they might someday be wanted
again. (In general, when a feature becomes obsolete, we should either
eradicate it or maintain it, and the decision here was not to eradicate
this.) It's also wrong because it's unnecessary--because we have this:

int Ledger::GetMaxLength() const
...
    // For all ledgers in the map, find the longest duration that must
    // be printed (until the last one lapses).
...
    for(auto const& i : l_map_rep)
        {
        max_length = std::max(max_length, i.second.LapseYear);
        }

which iterates implicitly over exactly the bases actually used.

>  I still wonder about something here: wouldn't LapseYear_Current always be
> at least as big as LapseYear_Guaranteed? Knowing that the former
> assumptions are at least as good, it would seem that the policy can only
> lapse later because of them, or am I missing something?

https://www.google.com/search?q=theory+practice+joke

I've seen this apparently-reasonable assumption violated. The first example
that comes to mind depends on the "policy loan" feature, which lets you borrow
against your "account value" and capitalize all interest, provided that there's
enough value left to pay the interest each year. On a guaranteed basis, suppose
we credit five percent on the amount you've borrowed, and charge you six 
percent.
On a current basis, these rates might fluctuate with financial markets: in the
1980s, for example, they were something like fifteen and sixteen percent,
respectively. (What's actually guaranteed is the "spread" between the rates
charged and credited: 6 - 5 = 16 - 15 = the same 1%). The "provided that" clause
above fails earlier on the current than on the guaranteed basis, and the policy
lapses because it becomes "overloaned".

>  Also, what is the right way to check whether CZ and/or GZ are available? I
> can only see how to check for them by explicitly checking for the
> corresponding member existence in GetLedgerMap(), but I'm not sure if I
> should do it like this because GetLedgerMap() is not used anywhere else and
> it doesn't look like a good idea to start using it and rely on the internal
> representation of different ledgers.

The answer depends on the reason why the question is asked. If you want to
know the maximum length, use Ledger::GetMaxLength() [above]. If you want
to know which bases to display on an illustration, the answer might be to
consult Database_->Query(DB_LedgerType), as Ledger::SetRunBases() does.
If you have a different reason, then perhaps a new member function should
be added to class Ledger, akin to GetMaxLength(): i.e., new PDF-generation
code should cooperate with lmi instead of trying to reinvent it, poorly,
as the old XSL code tried to do.