Re: [lmi] Product editor API

[Greg Chicares]

On 2005-10-18 0:21 UTC, Vadim Zeitlin wrote:
> 
>  I'm designing the API of the MultiDimGrid class (suggestions for better
> names would be gratefully accepted) which is going to be used in the
> product editor window and I have a couple of questions:
> 
> 1. I suppose we're going to have an arbitrary number N of axis (i.e. not
>    limited nor fixed) and each axis can take different number of values.

lmi needs some small number of axes. Small, but mutable, not fixed.
Right now, the number is between five and ten, and is expected to
change slightly. Is there any advantage in limiting it to anything
less than, say, the range of a 32-bit int? It's OK if the number of
data in the total array isn't allowed to exceed 2^31.

Each axis can take on various values. The set of possible values for
each axis is mutable. Its cardinality is between two and sixty right
now, but we might need hundreds someday: for instance, I count 239
country codes in ISO 3166-1-Alpha-2 as of 2000-08-21, and we might
want that to be an axis.

Where I say these numbers are mutable, I mean when the system changes.
Users aren't allowed to change them. Yet it might be a very good idea
to let the program itself set them dynamically upon initialization:
then we could read axis values from a configuration file, and wouldn't
need to hardcode them in the source.

>    The only question is whether these values can always be handled as
>    strings or is it important to keep type information for them, i.e.
>    also handle integer (and maybe real/float?) values? One place where this
>    could be useful is the combobox for choosing the value of a dimension
>    which is neither X nor Y axis: if we knew that some dimension is
>    numeric, we could use a spin control instead of combobox which would be
>    more convenient to the user. Another advantage would be the possibility
>    to specify the axis values as (min, max[, step]) instead of having to
>    enumerate all of them, which is the only way to do it for strings.
>    The disadvantage is, of course, that API would be more complex.

Most axes are string-valued. Users would be baffled by integers: they'd
struggle to remember whether 'Female' is 0, 1, or something else.

But some axes are naturally integer, e.g., 'Duration'. The legacy editor
uses a combobox for uniformity; there are usually just a few 'Duration'
values, and never more than a hundred or so. What is more important, a
user would rarely wish to select a single duration, and one who did
would probably want to select the first duration.

Non-unit strides ("min, max[, step]") might be nice to have someday, but
lmi has no significant need for them at this time. We can omit that.

Sometimes I think of using floating-point values to interpolate between
integer-indexed values: for a C analogy, given
  double a[] = {0, 20};
the expression 'a[.34]' might return .78 . (Well, of course, one might
want geometric or harmonic rather than linear interpolation.) This is
concisely expressive, but, I'm afraid, not worth the bother.

>    So should we handle integer axis specially or just treat everything as
>    text?

I'd suggest keeping it simple, for now at least, and just using strings;
though others on the list are welcome to jump in with different ideas.

> 2. Along the same lines, what about the values in the grid? Here I suppose
>    we do want to have integers and reals and also strings. Is there
>    anything else?

This is a difficult question.

At first, I was going to say just strings. They're sufficient because
of C99 F.5/1: "Conversion from the widest supported IEC 60559 format to
decimal with DECIMAL_DIG digits and back is the identity function." I'd
like to store floating-point values in xml files: one major drawback of
the current binary '.db4' format is that it's not human readable.

The first version of lmi, about seven years ago, supported 16-bit tools
and stone-age hardware. It's no longer necessary to use binary files for
speed: we can now afford twenty-one significant digits plus a minus sign,
a decimal point, and a small exponent field to represent an eight-byte
double.

Upon reflection, though, I see that one might enter
  3.14159.26535
or
  $1,234.56
in a field that has to contain a valid floating-point value. Neither the
control class nor the data class necessarily needs to enforce that, if
they delegate validation to routines available elsewhere in lmi. However,
the delegated-validation approach wouldn't work in wx unless wx has its
own way of validating floating-point input, which I'm sure it does; and
at any rate the control needs some way of knowing the type, so that it
can call the right validator (for strings versus floating point, e.g.).

Some lmi data really must be boolean or integer, or floating point.
Type 'double' could be used for all arithmetic types--it doesn't really
matter if bool data are represented as '1e1' or '-0e144' as long as
their values compare equal to either one or zero--so the value-storage
type could differ from the validation-requirement type, if there's any
advantage to that. Saving a few bits isn't a meaningful advantage, but
simplicity is, so I'd recommend whatever is simplest. I guess that will
mean a single type for each entity, with all that entity's values stored
internally in whatever form makes the most sense.

We don't need heterogeneous entities, like the integer twelve for males,
the string "true" for females, and a boolean type for our third gender.
All elements of any entity are of the same type.

> 3. I want to separate the data access from the GUI control, hence
>    MultiDimGrid would be used with a MultiDimTable (if this reminds you of
>    wxGrid and wxGridTable it's not a coincidence, of course). The question
>    is what should be the interface of this table class: it can be either
>    similar to wxGridTable and be completely stateless and hence have a
>    single method taking N parameters (values for all dimensions) and
>    returning the value of a cell. Or it could have a SetSlice() method
>    taking N-2 values for the fixed dimensions and then a GetGrid() method
>    returning all values for the 2 remaining axis at once which could be
>    more efficient. But looking at the amount of data we have here,
>    efficiency is probably not very relevant and so convenience -- of
>    implementing this class in lmi -- is more important. So do you think it
>    would be more convenient to have a single GetValue(D1 d1, ... DN dn) or
>    something else? Notice that the same question also exists for setter
>    function(s).

The only interface lmi needs, aside from the GUI, is read_file() and
write_file(). To permit validation, I guess it's enough to get and set
one string or arithmetic scalar at a time.

The goal here is only to create an editor that reads and writes files.
Ultimately, they'll be xml files, though in the short term we could use
lmi's existing formats; but I imagine that doesn't matter much for
addressing the question you pose here.

The goal is not to write a general-purpose database that can serve data
to lmi. We've already got that. And lmi's non-GUI core doesn't depend
on any libraries except boost and libxml2, which are automatically
portable anywhere gcc is; I want to avoid making that core (which uses
the product databases) depend on wx because we might conceivably need
to port it to some exotic network server with bizarre restrictions
imposed for political reasons (e.g., no X server).