lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] select tables terminology


From: Greg Chicares
Subject: Re: [lmi] select tables terminology
Date: Mon, 15 Feb 2016 14:44:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 2016-02-15 12:34, Vadim Zeitlin wrote:
> On Mon, 15 Feb 2016 11:57:27 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The number 0..3 in the header row is called "duration".
[...]
> GC> By convention, it always begins at zero.
> 
>  Interesting, they definitely start with 1 in the select tables produced by
> the existing "table_utilities -e" command, e.g. here is an extract:
> 
> Minimum age: 10
> Maximum age: 121
> Select period: 3
> Maximum select age: 80
> Number of decimal places: 5
> Table values:
>            1        2        3  Ult.
>  10  0.00106  0.00140  0.00165  0.00186   13
> ...
>  80  0.06520  0.10486  0.13557  0.16221   83
>  84                             0.17425   84
> ...
> 121                             1.00000  121
> 
>  I don't think the column labels should be changed to 0,1,2 here, should
> they?

Unfortunately, we cannot change them now.

Ideally, the format would have been designed like this:

 [x]     q[x]   q[x]+1   q[x]+2     qx+3  x+3
  10  0.00106  0.00140  0.00165  0.00186   13
 ...
  80  0.06520  0.10486  0.13557  0.16221   83

following the textbook example at the top of page 105 here:

  
https://books.google.com/books?id=Hm3uCAAAQBAJ&pg=PA104&dq=%22section+of+select+and+ultimate+table%22&hl=en&sa=X&ved=0ahUKEwiPlu6Z_PnKAhWD1CYKHYjaDCsQ6AEIHTAA#v=onepage&q=%22section%20of%20select%20and%20ultimate%20table%22&f=false

However, it wasn't designed that way, and we have to follow the actual
design for backward compatibility. Apparently the column headings are
origin-one ordinals.

> GC> The numbers {a0..a3}..{c2..c5} below the "duration" labels are called
> GC> "select rates".
> 
>  I just call them "values" currently. It's done in several places, so I'm a
> bit reluctant to change this, but if you think it would be more clear to
> use "select rates", I can do it, of course. In this case I'd like to know
> what should be used for the values in the aggregate and duration tables:
> just "rates" perhaps?

I suggest you continue to call them all "values". "Rates" would be as good,
but there's no reason to change that.

We would call the values in the ultimate column "ultimate rates" and the
others "select rates" when we need to make that distinction; otherwise,
they're all just "rates" or "values".

> GC> The ultimate column label doesn't have a name; it's just an ultimate
> GC> column label. The numbers x4..x7 below it are called "ultimate rates".
> 
>  So this is another (slight) complication, currently I use the same
> function (and hence give the same error message in case of a problem) for
> both the select and ultimate rates...

Just do what makes sense to you in context. E.g., if the structure of the
program is such that you don't know locally whether you're reading select
or ultimate rates, there's no need to add complexity to figure out which
it is; whereas if you're reading select rates in one function and ultimate
rates in another, you may as well indicate which one it is if that's easy
and seems useful for error messages.

> GC> > - The ages on the right hand side of the column (4..7) (which I 
> inventively
> GC> >   call "right hand side age")?
> GC> 
> GC> "Ultimate age".
> GC> 
> GC> > - If there is a term for the RHS ages, should some special term be also
> GC> >   used for the LHS ones?
> GC> 
> GC> "Select age".
> 
>  Thanks, adjusted as well. I still use just "age" for the non-select tables
> however, please correct me if this is wrong.

That's good enough. Some tables are actually keyed by duration and don't
depend on age--e.g., you can probably find a "lapse" table that works that
way somewhere in the public 'qx_ins' database; but I don't recall whether
the old code recognizes that distinction, and it doesn't matter much in
practice because the meaning should be clear from the context. If you just
use "age" for the (first) index column in error messages, that's okay.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]