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

[Vadim Zeitlin]

On Sun, 30 Jul 2017 02:57:41 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-07-30 00:21, Vadim Zeitlin wrote:
GC> > On Sat, 29 Jul 2017 22:44:46 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Thus, for general- and separate- account policies respectively we have
GC> > GC> these two sub-bases:
GC> > GC>   mce_gen_basis: {"Current", "Guaranteed", "Midpoint"}
GC> > GC>   mce_sep_basis: {"Hypothetical", "Zero", "Half of hypothetical"}
GC> > GC> each of cardinality three, which combine mystically to form the seven
GC> > GC> combinations in 'mce_run_basis', of which five are actually used. 
Surely
GC> > GC> this {2,3,5,7} pattern resulting from interference between federal and
GC> > GC> state regulation must appeal to the Pythagorean in you.
GC> > 
GC> >  This is very impressive but, even more surprisingly, quite 
understandable,
GC> > thank you! I hope I don't spoil everything by asking a potentially very
GC> > stupid question, but is what you called "Hypothetical" above the same 
thing
GC> > as is called "full" in the actual code or did I miss another part of the
GC> > pattern?
GC> 
GC> The inline documentation for set_run_basis_from_cloven_bases()
GC> (below) is supposed to answer such questions, and I think it
GC> does answer this one in the affirmative,

 Thanks for pointing me to this comment, it will undoubtedly be useful to
return to it later when I forget all this in a couple of months (I try
being optimistic for once and didn't write weeks or days).

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

 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.

 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?

 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.

 Thanks again,
VZ