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

[Václav Slavík]

Hi,

On 22 Mar 2012, at 00:25, 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>
>                       ...
>               </select>
>       </table>
> 
> "row" might be a bad choice but this structure seems to map directly to the
> usual table representation and doesn't suffer from any redundancy so what's
> wrong with it?

Consider a 1D table. Your version is overly verbose for it:

<table>
   <row age="1">0.198</row>
   <row age="2">0.194</row>
   <row age="3">0.190</row>
   ...another 60 rows...
   </age>
</table>

Too verbose, to be read easily, redundant and error-prone [1], compared to 
implicit numbering in

<rows min="1" max="63">
   <row>0.198</row>
   <row>0.194</row>
   <row>0.190</row>
   ...another 60 rows...
</rows>

And my initial proposal used by-columns orientation for 2D tables, i.e. your 
example above would have the form of 

<select period="3">
  <rows min="1" max="63">
    <row>0.198</row>
    <row>0.194</row>
    <row>0.190</row>
    ...another 60 rows...
  </rows>
  <rows min="1" max="63">
    ...
  </rows>
  <rows min="1" max="63">
    ...
  </rows>
</select>

But as soon we reverse the orientation to be by-rows — as Greg convincingly 
argues, for better human readability — and so every <row> contains 3 values in 
our example, then yes, what you wrote above is exactly what I would use. 
Because unnumbered row entries are only workable if the content of the row is 
very brief (and "brief" for this purpose means "fits on one line"), otherwise 
it's better to explicitly write the indices down as in <row age="N">. And then 
there's no reason for redundant min & max attributes.

More in my forthcoming reply to Greg.

Regards,
Vaclav

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