Re: [lmi] .tir files data structures in lmi

[Greg Chicares]

On 2006-2-15 13:58 UTC, Evgeniy Tarassov wrote:
>
> Could you please help me understand the .tir file data meaning? I have
> a hard time of aligning what i've learned from stratified_charges.?pp
> files with our mdgrid-alike approach. :)
> 
> If i understand correclty stratified_charges class is just a
> dictionary of stratified_entities (which is the entities to edit --
> the list on the left in product_editor). Every stratified_entity
> contains an array of limits and an array of values (both arrays are
> vector<double>). From the old ihs application it seems that the index
> of those arrays is a thingy called "band" and that its something
> similar to the age axis -- the last value determines the value for
> higher indexes.

See lmi's 'stratified_algorithms.hpp' for an explanation.

> As you could see from this letter i'm not really sure of the meaning
> of class variables/members. Should it be something like in the old
> legacy editor?

The legacy editor has its own facility to edit '.tir' files.
It's much like the legacy '.db4' facility, except that it
always shows two grid columns: there is no choice of axes.
Two columns here doesn't mean two axes: the abstraction is
better thought of as one column of pairs, sorted in
increasing order of "bands". Of course, grid cells don't
readily accommodate pairs of doubles, so two columns are
used.

> ------------------------------------------------------------------------------
> | Entity1  |  X Axis :                     |      <Grid Data>   |
> | Entity2  |  Y Axis :                     |      <Grid Data>   |
> | Entity3  |                                  |      <Grid Data>   |
> | Entity4  |  # Bands: 1..99           |      <Grid Data>   |
> | Entity5  |  Variable: limit/value    |      <Grid Data>   |
> -----------------------------------------------------------------------------
> Here "# Bands" axis can take value from the 1..99 range and
> corresponds to the index for those two arrays in stratified_entities
> class (limits and values).
> Variable axis can take the value limit or value (it correcsponds to
> limits array and values array).

I'm not sure how this concept should map onto MDGrid. I
haven't thought it through carefully. Would it make sense
to emulate the legacy editor's interface as much as
possible?

Some day we'll want to go beyond the legacy interface.
I'd like to call the first column either 'band' or 'tier',
depending on each entity's nature as described in the file
cited above; today that nature isn't expressed in the '.tir'
files, but in the future it can be an xml attribute. I'm
sure we'll also want, some day, to let '.tir' data vary by
at least some designated axes, something like the way '.db4'
data does today. We plan to add an "effective date" axis to
to everything, for instance, as described in my message of
2006-01-08T19:59Z to this mailing list; perhaps that's the
only axis we'll ever allow '.tir' data to vary by. Again,
that's not possible with today's '.tir' files, but we should
avoid doing anything now that makes such changes difficult
in the future.

> There is also dictionary read/write interface visibility issue. Both
> functions in stratified_charges for reading from and writing to a file
> are private and the class has two friends TierDocument and TierView
> not implemented in any lmi file. Should i replicate the same workaroud
> as for db4 and implement one of those classes and derive tir editor
> window from it to gain access to private structures of both
> stratified_charges and stratified_entity classes?

That sounds best to me: the Adaptor pattern again. There
is a great deal of proprietary code that uses classes like
'TierDocument', and you can't really tell whether any
change would break it. (It's OK to use GPL code in a
proprietary derivative work that's never distributed to
anyone, which is what we're doing here.)