Re: [lmi] InputSequence questions

[Greg Chicares]

On 2010-04-05 14:34Z, Vaclav Slavik wrote:
> 
> here's another build of the demo, with some changes:
> http://dl.dropbox.com/u/1978132/seq_entry_demo-v2.7z

Thanks. I didn't get to your last email over the holiday weekend,
so let me reply to it here...

> On Fri, 2010-04-02 at 10:11 +0200, Vaclav Slavik wrote:
[...]
> Both of these bugs seem to be specific to wxWidgets trunk; the
> executable above built against 2.8-svn doesn't suffer from them as far
> as I can tell.

Okay, so we'll need to update the wx version we're using when it comes
time to put this new code into production.

>> Here's an idea for the "from" column: instead of the current text, find
>> the preceding endpoint expressed in _absolute_ terms, and express "from"
>> relative to it:
>> 
>>    from issue date           until [retirement]
>>    from retirement           until [for # years] [  5]
>>    from retirement + 5 yrs   until [for # years] [ 10]
>>    from retirement + 15 yrs  until [maturity]
>> 
>> What do you think?
> 
> I implemented this so that you can see it in action.

It's simple. It's clear. And I can't think of any other approach that
would be as good.

I'm still struggling with the phrase "for # years". This reads rough:
  from retirement + 7 years until for # years 2, then
                            ^^^^^^^^^^^^^^^^^^^
However, if we simply used "# years" instead, then I'm sure people
would ask how "year" and "# years" differ. Let me suggest:

  show this     instead of this
  ---------     ---------------
   duration         year
    # years      for # years

Alternatively, maybe it would be better to bring "until" out of static text
and into the combobox, for all selections except "for # years"; thus:

  [100] from issue date       [until age  ] [47], then
  [200] from age 47           [until year ] [ 5], then
  [300] from year 5           [for # years] [ 2], then
  [400] from year 5 + 2 years [until maturity]

Does that seem better?

BTW, the static-text portion of this:
  [400] from year 5 + 2 years [until maturity]
seems a little odd the first time you look at it--can't the computer
add five and two?--but once you switch the "year 5" control between
"for # years" and "retirement", it does make sense, because the
"+ 2 years" part always stays the same. If there are two successive
"for # years" offsets, then you add the offsets, which is obviously
right. But you never add the offset to the base, which upon reflection
I'm growing to believe is also right.

What do you think of using
  from 2 years after year 5
       ^^^^^^^^^^^^^
instead of
  from year 5 + 2 years
                  ^^^^^^^^^
? It takes four more characters, where less would be better. But it
would be more natural English, at least in some contexts:
  from 2 years after retirement   | perfectly natural
  from 2 years after age 47       | good
  from 2 years after year 5       | strange
versus:
  from retirement + 2 years   | less natural, but perfectly clear
  from age 47 + 2 years       | okay
  from year 5 + 2 years       | a little weird
I'm not really sure whether one is better than the other.

Here's an implementation detail. If I enter
  1  year 3
  2  for # years 7
  3  for # years 2
and then change the first from "year" to "retirement", then only the
second line's static text is updated as desired; the third and fourth
lines remain:
  from age 3 + 7 years
  from age 3 + 9 years
instead of changing to
  from retirement + 7 years
  from retirement + 9 years

>> > I imagine there's a default context for the input sequence, e.g.,
>> > issue age zero and so on. 
>> 
>> I don't know, is there? That is, do we know these parameters everywhere
>> input sequences are edited?
> 
> ...but not yet this.

This is an important question. You had said:
| I assumed that the whole point of expressing and
| editing the sequences in an abstract way that you don't know these at
| the time of editing...
while I was assuming the opposite. But both those POVs are right in a way;
it all depends on the situation.

Suppose we've opened a '.cns' file. There are several "edit" menuitems:

(A) THESIS

  Census | Edit cell

A cell has a concrete context: e.g., it has a definite issue age. That
age can be changed independently (on the "Client" tab), causing the
sequence to be reinterpreted (if it depends on age). But issue age has
a definite value whenever we edit an input sequence in this situation.

(B) ANTITHESIS

  Census | Edit class defaults
  Census | Edit case defaults

In these situations, parameters like issue age do have values, but those
values are more incidental than definitive: they can be thought of as
exemplifying the range of possible values. What these commands edit is
certainly not a particular concrete cell; it's more like an abstract
platonic ideal. (But not quite: I think an "ideal" human in that sense
would have no particular age, whereas this is really an "exemplar" that
has a particular age that is to be thought of as variable. This becomes
important later in the discussion.)

(C) SYNTHESIS

We can say first of all that (A) is the predominant usage. For example,
we might use (B) to set a few parameters that are the same for all cells
in a census (such as a common effective date) once and only once; but
we'd use (A) to enter each individual's issue age, gender, premium,
insurance amount, and so on. So, if (A) and (B) must conflict, then (A)
has to win.

But they needn't actually conflict. We can observe that (B) does have
a complete context, in that the class and case defaults are legitimate
instances of class Input (as is each cell). Thus, the class default has
*some* specific issue age; it needn't equal any individual cell's issue
age, and it doesn't describe any actual person, but the issue-age data
member must have *some* value. And a competent user would endeavor to
make that value at least plausible, and probably even typical.

In case (A), we'd like to validate the input sequence in context.
In case (B), it does no harm to validate it in the context supplied;
even if that context is composed largely of default values, a sequence
shouldn't be invalid with such values.

Let's take a tangible example. Suppose case-default premium is entered as
  1000, 60;0 [or the equivalent in the GUI editor]
and the case-default context is
   45 issue age
  100 maturity age
Then the sequence is diagnosably erroneous, and if practicable should be
diagnosed as such. If that sequence is valid for every cell, then we can
deduce that all cells are issue age 40 or less, and therefore the case
default issue age should not be 45; it's okay to diagnose that. But it's
much more likely that some cell is age 45 or older.

But now we come to the central question of validation: when should input
be validated?

In lmi today, sequences aren't validated when they're entered. Indeed,
invalid sequence input can even be saved. Errors are diagnosed only when
the census is "run", via either of
  Census | Run selected cell
  Census | Run case
or one of the "Census | Print" options that "run" implicitly. That's a
defect IMO. Our pre-wx legacy program made at least a strong attempt to
validate sequences at entry, which is much nicer. Today, though, even an
unconditionally-invalid sequence like
  1000,5; 2000,3;0
is detected only at "run" time:
  Interval [ 5, 3 ) is improper: it ends before it begins.
[BTW, I don't mean to suggest splitting validation into two phases--one
to flag input like [5,3) that would be erroneous in any context, and
another for everything else.]

Now, we could do this:

Index: input_harmonization.cpp
===================================================================
--- input_harmonization.cpp     (revision 4821)
+++ input_harmonization.cpp     (working copy)
@@ -947,6 +947,7 @@
         SupplementalReportColumn10.allow(*i, home_office_only);
         SupplementalReportColumn11.allow(*i, home_office_only);
         }
+    RealizeAllSequenceInput();
 }

 /// Change values as required for consistency.

and that would be a big step forward, because the
  Interval [ 5, 3 ) is improper: it ends before it begins.
message would appear in the static control at the bottom of the tabbed
dialog. I wouldn't apply that change without careful refinement; just
to cite one obvious improvement, focus should be locked in the sequence
field when this problem is diagnosed. To cite a less obvious (and graver)
problem, suppose two sequence fields contain
  1000, 60;0 [or the equivalent in the GUI editor]
in an issue-age-30, maturity-age 100 context, and the age is changed
to 50; what exactly should the GUI do then?

And what ought to happen in case (B), when a case or class default
sequence is changed? If we want to trap every input error immediately,
then we really have to realize every input sequence for every cell;
but that may take too long. I have an actual case, captured in the
wild, which has 1296 cells; years ago I worked on one with 9000.

>> > The grammar for the "from X until" phrase is simple, so
>> > I think we can determine a width that would always suffice. It'd
>> > be helpful to see that in the demo so that we can judge whether
>> > that width appears excessive when the phrase is short (but I
>> > suspect that won't be a problem).
> 
> See the demo above. The dialog looks ugly for the simplest form of
> sequences, but anything else works well.

This works well. I wouldn't even call it ugly for the simplest case.
The spacing looks wide the first time you see it, but as soon as you
use "for # years" it all makes perfect sense.