lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Product editor


From: Evgeniy Tarassov
Subject: [lmi] Product editor
Date: Wed, 8 Feb 2006 18:52:26 +0100

Hello,
I wanted to ask a couple of questions about lmi product_editor before
implementing it.
 Currently in lmi cvs there are two sets of files implementing product
and entities -- the ones without any prefix (dbvalue.hpp, dbdict.cpp,
etc.) and others with ihs_ prefix (ihs_dbvalue.cpp, ihs_dbvalue.hpp).
I suppose that ihs_ is the right set of files (i've got impression
that its the refactoring of the old ones). Is it correct?

> Every entity in every '.db4' file today depends on every one of those seven
> axes, and that's the complete set--there are no others, today.
> ...
>   {Gender, Class, Smoking, Issue Age, Underwriting, State} (not Duration)
>

I've noticed that there was an effort to extend the TDBValue class to
support more than those 7 axis (see extra_axes_names,
extra_axes_values, extra_axes_types class members in ihs_dbvalue.hpp),
but its not finished (see
 //  std::vector<double>::const_iterator     i_val = extra_axes_values.begin();
 ...
 //      i_val++; // TODO ?? Need std::vector of vectors?
 in ihs_dbvalue.cpp file (void
TDBValue::FixupIndex(std::vector<double>& idx) const method).

 Vis-a-vis db4 files editing: should we implement the support for
those additional axes, or should we suppose the set of axis to be
really freezed to those 7 axis (Gender, Class, Smoking, Issue Age,
Underwriting, State, Duration) and simply ignore the other part of
DBValue interface (support for additional axis)?

I've coded a small test program that uses mdgrid to edit TDBValue
object and discovered that when the user enables that entity variation
along at least 6 axis, the TDBValue object consumes at least 10Mb of
memory (for its internal data storage) and it takes ages to convert
the data when the user checks or uncheckes those variation checkboxes.
A example: imagine that we want our entity from db4 file vary upon all
dimensions its depends on:
gender    =   3
class     =   4
smoking   =   3
issue_age = 100
uw_basis  =   5
state     =  53
duration  = 100

3 * 4 * 3 * 100 * 5 * 53 * 100 * sizeof(double) = 763.200.000 (almost 1Gb)

 I suppose that this example is not realistic, but it shows that the
user with a couple of simple manipulations can make the program to
crash (out of memory) or at least to hang for quite some time.

Concerning those seven axis: i think i understand the meaning of first
6 of them -- gender, class, smoking, us_basis and state dimensions are
described by the corresponding xenum<> specialisations from
xenumtypes.hpp file containing the set of possible values and a set of
value names.
Is it correct that the issue_age axis takes its values in the [1..100]
range and it corresponds to the 'strike' axis we have in the
test_mdrgid example (Strike option is taken as a set of values in
[10..100] range with a step of 5)?
The duration axis is the problematic one for me. I have not found no
description of what it is in the code. Could you please briefly
explain to me what it is and how should it be implemented or where
should i learn it from (class or source file)? :)

Thank you in advance!


--
ET




reply via email to

[Prev in Thread] Current Thread [Next in Thread]