Re: [lmi] first version of multi dimensional data editor control checked in

[Greg Chicares]

[tab character in original title changed to a space]

Wendy's off skiing for a week, so let me jump in.

On 2006-1-6 22:15 UTC, Vadim Zeitlin wrote:
> On Fri, 6 Jan 2006 11:15:20 -0500 "Boutin, Wendy" <address@hidden> wrote:
> 
> BW> > the axis (or dimensions) used are determined by the program logic.
> BW> > But, of course, nothing prevents the programmer from using different
> BW> > axis for different products.
> BW> 
> BW> Are you saying that we are to control that logic in lmi?
> 
>  Yes, I think so. Just to be totally clear: the MDGrid is _just_ the grid
> part of the control. It's completely generic and quite independent of lmi
> and so can be developed, tested and so on independently. Now, of course,
> the entire product editor is very lmi-specific and will be implemented on
> top of MDGrid and will deal with changing the axis in accordance with the
> item chosen in the tree.

Yes, it's good to separate the features. I think the question is which part
of the program needs to handle one particular feature described below.

> BW> I think there's just one variable that varies across all axes in the 
> BW> current prototype, but we really need to be able to change the 
> BW> dimensionality of the axes. Almost all of our data varies on fewer 
> BW> than all axes, usually three or four of the seven available, but 

Three or four at most, but more often zero or one.

> BW> there's no way to limit the axes that shouldn't vary.
> 
>  I still have the impression that I don't understand what do you mean :-(
> You can select the axis in the prototype and you can also select the set of
> values for one of them ("strike", by choosing the min and max values --
> this is equivalent of "duration" in lmi product editor). What exactly is
> missing?

The entity hardcoded in the sample program seems to vary across all axes.
AFAICT, the user can select which axes to display, and, for the Strike
axis, the minimum and maximum axis-values to display. And the user can
change the data-value of any cell on the right-hand side.

What I don't see is a way for the user to change the dimensionality of
the data. I think the data is always of dimension 2 X 2 X 17 X 12:
  2  {Put, Call}          [Option type]
  2  {European, American} [Exercise type]
  17 {10, 15, 20...90}    [Strike]
  12 {January..December}  [Maturity]
though of course that might just be my misunderstanding.

To get closer to the lmi problem domain, imagine that some entity varies
across the Strike axis only: it's 1 X 1 X 17 X 1. Without changing its
dimensionality, the user can view and change all its seventeen data-values
by selecting Strike as the only view-axis. Up to this point, I don't think
there's any misunderstanding (unless it's mine).

> BW> >  No, there are no popup dialogs but, AFAICS, none are needed.Unless I'm
> BW> > missing something in turn?
> BW> 
> BW> I got that impression from Greg's email here
> BW>   http://lists.nongnu.org/archive/html/lmi/2005-08/msg00039.html
> BW> which discusses the popup dialog. 
> 
>  I've just reread it but I still don't manage to see what are we missing
> right now. Could you please give an example of what should be possible but
> is not (in the current prototype)?

This message
  http://lists.gnu.org/archive/html/lmi/2005-07/msg00002.html
in the portion beginning with the string
  "Each entity is tabular: an array with potentially seven dimensions"
describes the data structure of each entity, and what I don't yet see in
the current prototype is how to change those dimensions.

For the entity above, a user could select view-axes Maturity and Option
type. That should show a 1 X 1 grid, because the entity is 1 X 1 X 17 X 1
* 1  {unused}          [Option type]
  1  {unused}          [Exercise type]
  17 {10, 15, 20...90} [Strike]
* 1  {unused}          [Maturity]
and only the asterisked axes are displayed. Perhaps MDGrid already takes
care of that if the product editor passes it such an entity. (Of course,
a 1 X 1 grid isn't very useful, so it's unlikely that a user would do that;
nondegenerate cases arise when, e.g., an entity varies across three axes
and two of those are selected for display.)

Now suppose this entity is to have only five values along its Strike axis:
the user wants to change its dimensionality to 1 X 1 X 5 X 1. Or suppose
the user wants to make it vary across the Maturity axis, changing its
dimensionality to 1 X 1 X 5 X 2. How can that be done?

One way is to use a bimodal interface. The legacy interface worked this way:

 - Mode 0:
     dimensionality fixed
     values editable
     view-axes selectable
     range of Strike axis fixed
       [the current prototype permits constraints on the Strike axis
       in this mode, I think; that's more flexibility than is needed,
       and I fear it may confuse users]

 - Mode 1:
     dimensionality mutable by (de)selecting axes
     upper limit of Strike axis editable
       [the current prototype offers an editable lower limit as well,
       but we'd like to prevent users from using or even seeing that]
     nothing else shown: values and view-axes irrelevant

I think you had pointed out that a bimodal interface generally has one mode
too many, and in most cases I'd agree. If there's a better way to offer
these capabilities, that's great. I just don't see them in the sample
program right now, but maybe they exist and belong elsewhere.