Re: [lmi] organization of XML actuarial tables

[Václav Slavík]

Hi,

On 26 Apr 2012, at 03:11, Greg Chicares wrote:
>    double T7702COI[9] =
>        {
>         39,  37,  35,  // female   sm, ns, us
>         45,  57,  41,  // male     sm, ns, us
>        111, 109, 107,  // unisex   sm, ns, us
>        };
>    Add(database_entity(DB_Irc7702QTable, NDIMS, dims7702, T7702COI));
> 
> we shouldn't go through an intermediate phase like this:
> 
>    char* T7702COI[9] =
>        {
>         "table_39",  "table_37",  "table_35",  // female   sm, ns, us
> ...
>        };
>    Add(database_entity(DB_Irc7702QTable, NDIMS, dims7702, T7702COI));
> 
> (with collateral intermediate changes to the code that reads and writes
> 'database_entity' objects)

Just to be clear, I had a less intrusive intermediate phase in mind. The only 
code that would change would be actuarial_table.?pp, the rest would remain the 
same. actuarial_table implementation would change and would use XML data files 
instead of the binary ones. For example, actuarial_table("qx_ann.dat", 37) 
would load the table from qx_ann_37.xml (or using some other naming scheme). 
The idea was that this phase would replace tables storage format without 
affecting anything else, in API or user experience, and I thought it would make 
testing easier.

BTW, automatic exhaustive testing is easy in this phase: load all tables from 
XML and SOA in parallel, call specific_values() for all possible values, 
compare the results. It's ~10^4 specific_values() calls per table, that doesn't 
sound too bad. I plan to do this in any case, to satisfy myself that the XML 
code is correct.

> when we ultimately want something like:
> 
>    Add(database_entity(DB_Irc7702QTable, "CSO1980ByGenderAndSmoker"));
> 
> The crucial motivation to make errors less likely; I think a one-step
> approach will also save some work, but that's just a bonus. It's really
> hard to adhere to a zero-defects standard when working on intermediate
> changes that we know we're going to replace.

OK.

> I'm thinking we should tackle this as follows. Write the new code that
> will be added to the lmi repository, and unit test it, leaving the old
> code in place. Then, wherever we call the old code, also call the new
> code, and compare the results to make sure they're perfectly identical.

Yes, this makes sense. From a brief look at the code, actuarial_table is used 
only in a few places, so this should be doable relatively painlessly.

Regards,
Vaclav