Re: [lmi] Terse list of valuable projects

[Greg Chicares]

On 2010-03-18 13:56Z, Vadim Zeitlin wrote:
> On Thu, 18 Mar 2010 13:43:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> You might wonder whether 'input sequences'
> GC>   http://www.nongnu.org/lmi/sequence_input.html
> GC> should be represented by one xml element for each year (they are 
> sequences,
> GC> after all...aren't they?). The answer is "no",
> 
>  This seems indeed clear. They're not sequences even though they can be
> realized as one once the age (is that all?) is given.

No, that isn't all:

        ,int a_issue_age         = your age when you buy a policy
        ,int a_retirement_age    = age at which you plan to retire
        ,int a_inforce_duration  = how many years ago you bought the policy
        ,int a_effective_year    = calendar year [not used yet]

and even this:

        ,int a_last_possible_duration

is mutable (users can change from a policy that ends at age 95 to
one that ends at age 100, e.g.).

> GC> Consider a payment represented thus:
> GC>   10000 20; 0
> 
>  OTOH this doesn't answer the question of how should they be represented in
> XML. If we want to follow the atomicity principle to the hilt, we'd need to
> represent each semicolon-separated part with a tag. And then we'd need
> nested tags to describe each of them. E.g. the simple example above would
> become
> 
>       <sequence>
>               <interval>
>                       <value>10000</value>
>                       <count>20</count>
>               </interval>
>               <interval>
>                       <value>0</value>
>                       <count>rest</count>  <!-- or -1 or whatever... -->
>               </interval>
>       </sequence>
> 
> Of course, handling of "#" and "@" modifiers would require more tags...

Interesting. I hadn't thought of breaking them into atoms at semicolons.

If we changed the xml that way, then we'd need to recombine the atoms
when reading an input file. Perhaps more significantly:

'input_sequence.hpp':
// Strings might simply be saved exactly as entered. That seems to be
// the least surprising way.

That's what we actually do.

// Alternatively, we can choose a canonical representation for input file
// storage. Explicit interval notation is probably best because it
// has the greatest flexibility; half-open intervals of the form [x, y)
// are preferable.

That's not what we do. We could view this as "canonicalizing" the input,
but to end users, it's more like *mangling*: "I saved a file, and when
I reloaded it, there was all this weird math stuff...".

Perhaps it's possible to use a more elaborate xml representation that
translates back to what the user entered, character for character. But
even ascertaining whether that's possible sounds difficult, so first we
must ask whether we'd ever want to use xslt with this, or to display
it with CSS or FO.

Such a thing could be somewhat useful:
  http://savannah.nongnu.org/support/?105596
  "Print individual input"
although it's hardly indispensable (that item has stayed in "Need info"
status since 2006). As for:
  "The purpose is to help users and reviewers check input."
what I believe that means is mainly verifying that input was entered
correctly--not that 'input sequences' have been realized correctly.

There's actually another purpose: making it easy to grasp the salient
input details at a glance, for instance on a single "cover page" that
echoes a summary of the input. The essential problem is that salience
is subjective, and there isn't a single input field that's not
important in some context. Years ago, we and some end users spent
multiple person-months chasing after an abridgement of input that
would show everything of significance at a glance. No one was ever
really satisfied with the result (and therefore we never spent the
time to migrate it to lmi from the predecessor system). The hardest
technical problem was 'input sequences', which can potentially be
extremely long; at the time, we decided to truncate them to fit on
one printed line with a trailing '...'. That's ideal in every case
where truncation does not occur, but....

Anyway, just because it's hard doesn't mean it's without value, and
just because we failed once doesn't mean we shouldn't take a fresh
look. I wouldn't direct any effort toward this end for now, but perhaps
while working on the related aspects that we've been discussing one of
us will see a tidy solution.

However, I doubt that such a solution will require changing the way we
store 'input sequences' in xml input files.