Re: [lmi] Can we remove unused elements of the columns title map?

[Greg Chicares]

On 2017-09-27 12:18, Vadim Zeitlin wrote:
> On Wed, 27 Sep 2017 00:57:23 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2017-09-26 23:12, Vadim Zeitlin wrote:
> [...]
> GC> >  Would anything be lost if I removed them? Or would it be easier for 
> you if
> GC> > I preserved them for now? Please notice that I don't think that it's 
> going
> GC> > to make reviewing the changes any easier because all these unused titles
> GC> > would still need to be changed, instead of being removed.
> GC> 
> GC> I'd like to know which ones you want to remove.
> 
>  Here is the total list of removed lines by my corresponding local commit:

[snip]

Thanks. Now I see the underlying logic: with very few exceptions, every
vector in the union of 'ledger_invariant.hpp' and 'ledger_variant.hpp'
corresponds to one or more entries in 'title_map', and to exactly one
map entry if we drop the suffixes like "_Current" and "_Guaranteed"
(for "variant" vectors that vary by such a "basis"). The only
exceptions are:
  AttainedAge and PolicyYear: indexes that are probably regenerated
  Fund*: old stuff that may be reanimated one day
  NetDeathBenefit: dynamically synthesized
  SupplDeathBft, SupplSpecAmt: alternative names (usually, the same
    names but beginning "Term" are used; "Suppl" names are the same
    values, captioned differently in some cases for business reasons)
Thus, there's a very strong relationship between the ledger vectors
and 'title_map', which we should preserve: an element should either
be removed from both, or removed from neither. All of them, or nearly
all, could be quite useful someday, even if they haven't been used in
over a decade, so I wouldn't want to remove a single one.

> GC> Probably many are just garbage, but maybe not all.

Now that I see the list--no, actually, every item was added for a
reason.

> GC> >  Final possibility would be to keep all this code completely unchanged
> GC> > and create another set of column titles in the PDF generation code
> GC> > itself. This would make the upcoming review simpler, and would allow me 
> to
> GC> > reuse the same map for all columns used in the illustration tables, 
> whether
> GC> > they correspond to mcenum_report_column elements or not.

This simplifying idea is interesting. And some of the variations
among names that denote the same column may be merely gratuitous,
such that unifying their names would be an improvement. However,
the business requirements are non-simple in some important cases...

> GC> > But it would also
> GC> > mean that the columns appearing both in "normal" and "supplemental" 
> reports
> GC> > would use the same name in both, which actually seems like an advantage 
> to
> GC> > me but which is not the case currently. E.g. consider a basic column 
> such
> GC> > as "AcctVal_Guaranteed" which uses "Account Value" labels in all the
> GC> > different tables it appears in, but "Guar Account Value" in supplemental
> GC> > reports. So I'm not really sure whether it would be a good idea.
> GC> 
> GC> In that example, I imagine (though I haven't checked) that the
> GC> "Account Value" header would appear only under a "Guaranteed"
> GC> multi-column super-header.
> 
>  Yes, I think you're right.
> 
> GC> I'll need to ask whether something like
> GC> 
> GC>   ------Guaranteed------
> GC>   Guar Acct  Guar Death
> GC>     Value      Benefit
> GC>   ---------  ----------
> GC> 
> GC> would be acceptable.
> 
>  It doesn't look good to me, so I don't think actual lmi users would be
> happy about it.

Yes, I see that clearly now.

> It would be possible to define a table with several columns
> to have entries for "with base specified" or "with implicit base" in it.
> 
>  However not all differences fall into this category, consider
> "PolicyFee_Current" column, for example: it's called "Admin Charge" in the
> supplemental page of the NASD illustrations, but "Curr Policy Fee" in the
> supplemental report. But maybe this one is actually just a mistake because
> there is also "AdminCharges" column in the reg_d_individual illustration
> which is actually set to "PolicyFee + SpecAmtLoad".

That one is probably a careless mistake.

> I suspect confirming or
> disproving this risks taking quite a bit of time and effort though,

Indeed. And even correcting a careless mistake requires permission
from the Ministry of Correctness.

> so I'd
> rather not wait until this is done and, for now, preserve exactly the same
> behaviour as is implemented by the current code and change/fix it later if
> needed.

Yes, this seems wise. As always, when you notice something dubious
like "Admin Charge" above, please write an inline comment with a
distinctive, greppable marker like "PDF !!" so that it won't be
forgotten.