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

[Greg Chicares]

On 2006-1-8 13:39 UTC, Vadim Zeitlin wrote:
> On Sat, 07 Jan 2006 03:55:46 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> To get closer to the lmi problem domain, imagine that some entity varies
> GC> across the Strike axis only: it's 1 X 1 X 17 X 1.
> 
>  I thought being able to do it programmatically would be enough because I
> believed the given entity would always vary by a fixed number of axis but I
> now realize I was wrong. So I think that I do understand what's missing
> now, let me write it down for verification:
> 
>       What is missing is a way for the user to remove the unwanted axis,
>       i.e. those along which the data doesn't change at all.
> 
>  Is this correct?

The user can also add an axis that had not previously been used.

The entity in the sample program has four axes: it's 2 X 2 X 17 X 12.
The third axis is variable; let's say its length must be in [1, 17].
Then the possible dimensions of the entity are

  1 X 1 X N X 12
  1 X 2 X N X 12
  2 X 1 X N X 12
  2 X 2 X N X 12
  1 X 1 X N X  1
  1 X 2 X N X  1
  2 X 1 X N X  1
  2 X 2 X N X  1

for N in [1, 17], and the user must be able to navigate between any
pair of states, potentially taking more than one action. Going from
  1 X 1 X N X 12
to
  1 X 2 X N X 12
is presumably one action in the GUI, while going from
  1 X 1 X N X 12
to
  2 X 2 X N X  1
is probably three actions.

And the length N of the third axis can be changed. These are all
changes to the shape of the data itself.

Without changing the shape, the user can select only which axes are
displayed.

> GC> I think you had pointed out that a bimodal interface generally has one 
> mode
> GC> too many, and in most cases I'd agree. If there's a better way to offer
> GC> these capabilities, that's great. I just don't see them in the sample
> GC> program right now, but maybe they exist and belong elsewhere.
> 
>  If my above statement is correct, we just need to be able to
> enable/disable the axis from the UI.

Yes: enable or disable.

> This can be done either with a
> "[x] varies along" checkbox near each axis

That's the paradigm used by the legacy editor.

> or by adding a special "doesn't
> matter" value to each combobox.

That would be a different paradigm; let's think it through....

> Although conceptually a checkbox would seem
> preferable (because being enabled/disabled is orthogonal to the set of axis
> values),

Yes, it's orthogonal.

> I think a special "doesn't matter" value would be easier to use in
> practice because starting to use a currently unused axis would be easier
> then (instead of having to click a checkbox and then choosing a value from
> the combobox, you'd choose the value directly).
> 
>  So I'd like to propose to add a (optional as I think sometimes an axis
> might be mandatory)

That's an interesting point; let me address it in a footnote [1]
because it's tangential to the present topic.

> special value to each axis combobox which would disable
> it when selected. What do you think about this?

Here's what I think it would look like then.

In the sample program, the possible axes are:

  2  {Put, Call}          [Option type]
  2  {European, American} [Exercise type]
  17 {10, 15, 20...90}    [Strike]
  12 {January..December}  [Maturity]

Suppose an entity varies across the first, second, and fourth axes,
so it's 2 X 2 X 1 X 12, and we're currently viewing a slice that
encompasses the first two axes:

  X axis: Option type
  Y axis: Exercise type

A "modal" interface might present the other two axes like this:

  Strike:   [Disabled: the entity doesn't vary across this axis.]
  Maturity: [Force selection: one of twelve months]

but instead of that, I think you'd offer

  Strike:   "Invariant" | {"European", "American"}
  Maturity: "Invariant" | {"January", "February", ... "December"}

in effect combining the two modalities in the combobox choices.

Here's what I think. MDGrid is a general-purpose component, or at
least it's much more generic than the product editor; if you envision
reusing it in other circumstances, then it should be designed the way
you think best, though of course I'd like to make sure that won't make
life harder for lmi users.

Now, lmi users may benefit from the legacy editor's modality: it
prevents them from "accidentally" changing the dimension of an entity.
Is there another way to give them that "safety" within your new
paradigm? Yes, I think--one could potentially add a "lock dimensions"
checkbox. If selected, it would prevent crossing the vertical bar in:
  Strike:   "Invariant" | {"European", "American"}
so that "Invariant", if chosen, could be displayed but disabled; and,
if "Invariant" is not chosen, then a selection between "European" and
"American" options would be forced. This would simplify use of the
interface in the typical case where an entity actually varies across
zero or one dimensions, because almost everything would be grayed and
the user could only choose which axes to display. We could even go
one step further: offer no choice at all for scalars, and, for one-
dimensional entities, force a vertical display, again with no choices.
To offer no choices when no reasonable choice exists seems to be the
best UI design of all. If the user "unlocks" the dimensions, then
that's a deliberate choice to enter a less safe "mode".

Consider also how the editor might be used for read-only files. We
might make the editor available to people who shouldn't ever change
anything, neither values nor dimensions. Opening a file in read-only
mode would have the effect of forcing the "lock dimensions" behavior,
and also of locking the grid against input. That's a reasonable use
that we had not previously discussed.

And, if this idea doesn't greatly appeal to you, consider making the
"lock dimensions" behavior optional, say, with a constructor flag.
If the flag isn't given, then no such checkbox would even be shown,
as if the option didn't exist. What do you think?

---------

Note [1]: The legacy editor is really four editors, one for each file
extension in {.db4, .pol, .rnd, .tir}, which represent four different
data structures today. As we discussed some months ago, it would be
much better to use a single, more-generic data structure for all.
Now, '.tir' data by its nature always requires a pair of axes, and
doesn't permit variation across any of the axes used for '.db4' data.
In that sense, I guess it is useful to regard some axes as mandatory
(and others as forbidden) in certain cases.

To complicate things further, we have been asked to permit '.tir'
data to vary by "Duration" and "State" only, but never any of the
other '.db4' axes. That's not required today, but it's a potential
enhancement that we should keep in mind, even if only to avoid
making it much harder to add later.

There's one more enhancement that we probably will work on this year:
adding an "effective date" axis to every entity in all these files.
In the context of the sample program, historical option prices would
be stored by date. This axis would represent the lower bound on the
price's effective period: thus,
  date       price
  2005-01-01   100  applicable over the interval [20050101, 20050401)
  2005-04-01   120
  2005-07-01   110
  ...
for prices that vary quarterly. This is a new idea that has just
come up recently.