[lmi] Why guaranteed vs. current is not a database axis

[Greg Chicares]

This morning Steven asked why database entities can vary across axes
  gender, underwriting-class, smoker, issue-age, underwriting-basis, state
but not current versus guaranteed. The original design decision is documented
in 'dbvalue.hpp':

| We choose not to make current/guaranteed a database axis. Of course it's a
| conceptual axis, across which many database entries do vary. But in practice
| the guaranteed and current versions of such an entry will often have different
| shapes. For instance, current COI rates may be select and ultimate while
| guaranteed COI rates are attained age--and if we represent this variation as
| an axis here, guaranteed COI rates must be coerced into a select and ultimate
| form. We think this problem is unlikely to arise with the axes we've chosen.

For instance, one proprietary product we support has COI rates that vary by
  {gender, underwriting-basis, smoker} on a current basis, but only
  {gender,                     smoker} on a guaranteed basis.
and another's vary by
  {gender, underwriting-basis, underwriting-class, smoker} for current, but
  {gender, underwriting-basis,                     smoker} for guaranteed.

That said, I no longer find the original rationale compelling, in light of
years of actual experience. The second product mentioned above has COI
table pointers of dimension
  3 x 4 x 3 x 5 [180 data] current
  3 x     3 x 5 [ 45 data] guaranteed
but
  the last axis always has the same value in its first 3 of 5 slots
    and the same value in its last 2 slots for guaranteed only
  the second axis for current has equal values in its last two hyperplanes
    and many other degeneracies
so the real picture that emerges is
  3 x 4 x 3 x 5 current    [180 data, of which  7 are unique]
  3 x     3 x 5 guaranteed [ 45 data, of which 18 are unique]
The argument in favor of the original design is to avoid sparseness; that
argument seems to fail in light of actual experience that shows sparseness
to be irreducibly intrinsic in the cases where it applied at all. IOW,
replicating a 3 x 3 x 5 array, which contains only 18 unique data, across
a new axis of dimension 4 doesn't do much more violence than representing
a set of 7 unique data in a 3 x 4 x 3 x 5 array.

And in most cases we're dealing with scalar pairs of guaranteed and current
parameters; it would be extremely beneficial in that overwhelmingly common
case to show both elements of the pair at the same time. The drawback is
a little more complexity--we'd actually have a five-dimensional table--but
passing from four to five dimensions is never the conceptual block that
passing from three to four is.

We ought to follow the same paradigm for data that's now in '.tir' files.
There, very often, current parameters have numerous breakpoints while
the corresponding guaranteed parameters are scalar, but there is great
simplicity in uniformity.

However, I think we should defer enhancements like this, and first get the
legacy code ported to wx--bearing in mind the changes we'd eventually like
to have, so that we don't do anything now that'll make them difficult later.