Re: [lmi] tasks 2007: bug 104481: fund selection

[Greg Chicares]

On 2007-2-16 12:24 UTC, Evgeniy Tarassov wrote:
> Permit fund selection
> http://savannah.nongnu.org/support/?104481
>    Separate-account products typically offer a variety of funds.
>    The GUI should allow allocations among funds, e.g., 30% in one
>    and 70% in another, as well as equal allocations to all available
>    funds. Allocations must total 100%. Some products offer both
>    separate- and general-account options, while others don't.
> 
> I dont understand the terminology :S and as a consequence i dont
> really follow the feature description. Could you please slightly
> explain it in terms of existing classes/data structures/input controls
> from lmi_wx? Or maybe you could explain where does it happen now (the
> funds selection)?

It doesn't happen at all, now. I think you have a precompiled binary
of our legacy application, which did permit this, on its "Funds" tab;
but I hesitate to point you in that direction because it may be
difficult to understand without expertise in the insurance domain,
so instead let me try to factor out the domain dependence. (I'll send
you a screenshot of the legacy application anyway--privately, because
it contains some proprietary information.)

You have a certain amount of money, and a certain number of bank
accounts--say, up to forty accounts. You want to place various
percentages of your money in those accounts. Typically, you'll
choose a small number of accounts. Any money that you don't put in
a bank, you keep in your pocket. The available bank accounts are
specified in a '.fnd' file.

The user needs to specify the percentage that goes in each account.
So we've got a vector of percentages p0, p1, ... p39 constrained by
  0 <= px <= 100
and
  100 <= sum of all px
The percentage that remains in your pocket is a dependent variable:
  100 - sum of all px
Only the percentages matter; the actual amount of money is not
relevant, and actually changes over time, but the px are constant.

Because the cardinality of the problem is sizable--perhaps forty--you
might first think of using a grid. But the typical cardinality is much
lower, so, in the legacy application at least, it seemed okay to
 - select accounts from a listbox, one at a time
 - offer a textcontrol for editing the percentage for the fund
     currently selected in the listbox
 - dynamically update listbox contents to reflect each account's
     current percentage as well as its identifying name
 - show what remains in your pocket, in a static textcontrol

Then, whenever you select account k in the listbox, its percentage
pk is constrained to
 0 <= pk <= 100 - (sum of all px) + current value of pk
and the input routines enforce that constraint: you can't move
focus away from the px textcontrol if you've entered a value
outside those bounds, until you correct it.

I hope the screenshot makes that clear enough. For lmi, we could
consider a grid instead--that might make much more sense.

There's one complication:

>    Allocations must total 100%. Some products offer both
>    separate- and general-account options, while others don't.

Here, "general account" is what I called "your pocket" above.

To stretch my analogy, that would mean that in some cases you
have another constraint: that no money remain in your pocket,
so that the allocation percentages must strictly total 100%:
  100 = sum of all px
In that case, the legacy application simply chose the first
bank as the default, making its allocation a dependent variable,
so that it served the role your pocket would otherwise play,
and that first bank account consequently was removed from the
listbox. I can't think of a better way to handle that.

Oh, and there's another complication: the user can select a
checkbox or radiobutton that makes the px uniformly equal, in
which case the listbox and textcontrol above are disabled.

I wish I knew a physics analogy that would make this clearer to
you. It's a partitioning problem subject to a conservation law.
The problem is actually very simple. If my explanation and the
screenshot don't seem simple, then that probably indicates that
a grid would have been a better choice.