Re: [lmi] Terse list of valuable projects

[Greg Chicares]

On 2010-03-16 13:49Z, Vaclav Slavik wrote:
> On Mon, 2010-03-15 at 17:01 +0000, Greg Chicares wrote:
>> > Configurable group roster showing input and values
>> >   http://savannah.nongnu.org/support/?105595
> 
> Could you elaborate on this? Being unfamiliar with the domain, I don't
> understand much of it... 

Okay, I'll start a new thread for that.

>> > SOA rate tables: use xml rather than binary
>> >   thus, replace 'actuarial_table*.?pp'
>> >   add a GUI; integrate into product editor
>> >   tables are free; schema isn't, so we can't use it:
>> >     http://64.49.242.57:8080/xtbml/jsp/index.jsp
>> 
>> This would be very nice to have, and it is a logical successor to the
>> immediately preceding item.
> 
> I was under the impression that actuarial_table.* reads existing data
> files in a format that you cannot influence

There are two formats, and we can't influence either of them. The format
we use right now is binary, and the only good thing we can say about it
is that reading it is probably fairly time-efficient. (Well, it also
obscures data that most insurance companies would consider proprietary;
but it doesn't do so very effectively because there's a gratis program
on the Society of Actuaries website that reads these files into a human-
readable form. With xml, we can get similarly weak security by using
whatever xml::document::save_to_file() does if its 'compression_level'
argument is nonzero. [BTW, does it happen to use, e.g., zlib? I haven't
explored 'compression_level', but it might help make xml product-file
handling faster.])

Aside from that, the binary format is disastrous: there are multiple
incompatible versions, and even members of the Society of Actuaries
balk at using it. But there's an xml format, which has all the
advantages of xml, along with the disadvantage that its accompanying
schema is incompatible with free software due to licensing. It would
be better for us to use that xml format (without using the schema)
instead of the binary format that we're currently using.

> and that's it's about
> inherently read-only data.

Actually it's not read only, even though it appears that way to most
users in most circumstances. In this respect, it's exactly the same
as any of our product files: developers need to be able to change the
contents, but most end users don't need to (and aren't permitted to).

> Is that not the case? Or, if it is, how would
> data be imported, would conversion from this format still be needed? 

We'd need to convert all our existing (proprietary and nonproprietary)
files to xml. We'd do that all at once, without preserving the ability
to read the old binary format. It would be handy to have a standalone
public program that would read binary (using 'actuarial_table*.?pp')
and write xml; after that's done, we could remove the existing
'actuarial_table*.?pp', presumably adding a class with a similar
interface to read (and write) xml tables.

Ultimately, it would be nice to add a GUI for these tables. But let's
not even think about that now.

>> >   include https://savannah.nongnu.org/support/?104480
> 
> Could you point me to the place where I can see this "mini language"
> used in the UI? 

Here's the user documentation:
  http://www.nongnu.org/lmi/sequence_input.html
'input_sequence.hpp' contains some formal documentation of what
the 'input_seq*.?pp' files do.

The GUI contains many 'input sequence' fields--for example, the
"Individual payment" field on the "Payments" tab.

Let's not try to implement this extra idea right away:
  https://savannah.nongnu.org/support/?104480#comment1
(It might be better to implement that as a separate "multiplier"
field, e.g.:
  "Individual payment":             10000
  "Individual payment multiplier":  1.0 1.01 1.02
would result in 10000 10100 10200....)