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

[Vadim Zeitlin]

On Thu, 22 Mar 2012 11:58:01 +0100 Václav Slavík <address@hidden> wrote:

VS> On 22 Mar 2012, at 00:25, Vadim Zeitlin wrote:
VS> > I have almost no knowledge of the domain so I may be missing something
VS> > utterly obvious to both you and Vaclav, but why do we have to specify the
VS> > minimal and maximal ages at all? I.e. what would be wrong with having
VS> > 
VS> >   <table>
VS> >           <select period="3">
VS> >                   <row age="10">
VS> >                           <value>0.00106</value>
VS> >                           <value>0.00140</value>
VS> >                           <value>0.00165</value>
VS> >                   </row>
VS> >                   <row age="11">
VS> >                           <value>0.00113</value>
VS> >                           <value>0.00148</value>
VS> >                           <value>0.00175</value>
VS> >                   </row>
VS> >                   ...
VS> >           </select>
VS> >   </table>
VS> > 
VS> > "row" might be a bad choice but this structure seems to map directly to 
the
VS> > usual table representation and doesn't suffer from any redundancy so 
what's
VS> > wrong with it?
VS> 
VS> Consider a 1D table. Your version is overly verbose for it:
VS> 
VS> <table>
VS>    <row age="1">0.198</row>
VS>    <row age="2">0.194</row>
VS>    <row age="3">0.190</row>
VS>    ...another 60 rows...
VS>    </age>
VS> </table>
VS> 
VS> Too verbose, to be read easily, redundant and error-prone [1], compared
VS> to implicit numbering in
VS> 
VS> <rows min="1" max="63">
VS>    <row>0.198</row>
VS>    <row>0.194</row>
VS>    <row>0.190</row>
VS>    ...another 60 rows...
VS> </rows>

 Hi,

 I'm not sure I agree with everything here. My version is more verbose,
clearly, but I'd argue that it's not a huge problem in practice. As for
"redundant", I'd rather say "explicit" and IMHO "explicit" is better than
"implicit". Finally, I definitely disagree with "error-prone" as it's too
easy to add a row in a wrong place or modify a wrong row by mistake in
your version if you ever edit the file by hand (I optimistically assume
that changing it programmatically will always work correctly :-). E.g. just
imagine updating the 47th row of a min=1 max=63 table. How are you going to
even find it?

VS> [1] It's easy to miss a row number or to list one twice. We could use
VS> Schematron assert (emebedded in RELAX NG grammar) to verify that the
VS> number of <row> elements is max-min+1 under my scheme, but I'm not sure
VS> if we can verify that the row numbers are sequential. Although on the
VS> other hand, it may actually be an advantage that gaps are permitted by
VS> this format...

 I think the most important would be to verify that there are no duplicate
rows. The rest is IMHO either not really a serious problem (rows out of
order) or might actually even be useful (possibility to have gaps, as you
say).

 Anyhow, as I said, I really don't know much about the problem domain so I
won't argue for one or the other format, but I just think that being
explicit is rather an advantage compared to implicitly numbering the rows
and not a problem.

 Regards,
VZ