lmi
[Top][All Lists]
Advanced

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

Re: [lmi] actuarial tables format (was Re: Terse list of valuable projec


From: Greg Chicares
Subject: Re: [lmi] actuarial tables format (was Re: Terse list of valuable projects)
Date: Thu, 22 Mar 2012 00:00:18 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 2012-03-21 23:25Z, Vadim Zeitlin wrote:
[...]
>  I have almost no knowledge of the domain so I may be missing something
> utterly obvious to both you and Vaclav, but why do we have to specify the
> minimal and maximal ages at all? I.e. what would be wrong with having
> 
>       <table>
>               <select period="3">
>                       <row age="10">
>                               <value>0.00106</value>
>                               <value>0.00140</value>
>                               <value>0.00165</value>
>                       </row>
>                       <row age="11">
>                               <value>0.00113</value>
>                               <value>0.00148</value>
>                               <value>0.00175</value>
>                       </row>
>                       ...

That wouldn't create any issue in the problem domain. Any table has a
minimum and maximum age (or duration), but exhaustively specifying all
possible values:
  <row age="10">...,<row age="11">..., ... <row age="80">
expresses that as effectively as <table min_age="10", max_age="80>
(because we can guarantee that they're consecutive integers). I think
that means the design can be driven by the solution domain.

A quick glance at the code in 'actuarial_table.cpp' leaves me with
the impression that min_age_ and max_age_ are used mainly for the
assertion of preconditions that a table lookup won't segfault: they
don't seem to be central to the design.

We'd want to be able to ascertain the min and max somehow, even if
only for creating a spinctrl or combobox to select among available
hyperplanes in a product-editor extension. But in that case it's
okay if ascertaining them takes several million CPU cycles.



reply via email to

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