Re: [lmi] Experimental implementation of non-MEC solves

[Greg Chicares]

On 2009-03-02 21:56Z, Greg Chicares wrote:
> On 2009-02-17 13:34Z, Greg Chicares wrote:
>> 
>> This non-MEC solve replaces the old feature that increases the
>> specified amount to avoid a MEC. That old feature will soon be
>> removed. It wasn't very practical, because requiring a (large)
>> increase every seven years presumes future insurability. And the
>> way we implemented it in 2002 left much to be desired: it fails
>> to increase the initial specified amount when necessary, and it
>> doesn't work at all for group carveout.
> 
> While trying to adjust system tests for the elimination of that
> old feature, I've discovered two previously-unidentified problems
> with it:

Not to mention the previously-identified problems, such as this:

    IncreaseSpecAmtToAvoidMec();
    // TODO ?? The increased specamt doesn't get propagated back to
    // the Irc7702_ object. This is an important defect and a test
    // escape.

among others.

> (2) It apparently increased the specified amount only for the
> primary "current" basis.
[...]
> eighth-year "EOYDeathBft" value in previously-saved results was
> 1692471 (as expected) on this basis only:
>   curr charges and genacct int, full sepacct int
> but 1000000 on all other bases. That's just plain wrong, and
> always has been.

How so? Because of the penultimate sentence in this excerpt:

http://lists.nongnu.org/archive/html/lmi/2006-01/msg00004.html
|
| [...] So much cleverness was expended frivolously that not
| enough remained to look into the suspected defects.
|
| Each of the 295 7702A system tests produces about ten thousand
| year-end values, few of which are relevant to 7702A.
| [...]
| off-anniversary MEC testing is incorrect, in a very general way that
| could easily have been detected by a simple unit test. The scope of
| the system test was too vast (295 * ~10000 = about 3000000 values),
| yet at the same time too narrow (zero valid off-anniversary tests).
| And there's another grave problem: none of the 2950000 values is
| known to be correct. Some are thought to have been validated to some
| degree by hand, but which, and how, are questions with no documented
| answers. These are mistakes to learn from, not to repeat.

Later this year we'll completely rework the 7702A code.