[lmi-commits] [4880] Merge two headers

[Greg Chicares]

Revision: 4880
          http://svn.sv.gnu.org/viewvc/?view=rev&root=lmi&revision=4880
Author:   chicares
Date:     2010-05-01 10:42:43 +0000 (Sat, 01 May 2010)
Log Message:
-----------
Merge two headers

Modified Paths:
--------------
    lmi/trunk/ChangeLog
    lmi/trunk/Makefile.am
    lmi/trunk/database_view_editor.hpp
    lmi/trunk/ihs_database.cpp
    lmi/trunk/ihs_dbdict.hpp
    lmi/trunk/ihs_dbvalue.cpp

Removed Paths:
-------------
    lmi/trunk/ihs_dbvalue.hpp

Modified: lmi/trunk/ChangeLog
===================================================================
--- lmi/trunk/ChangeLog 2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/ChangeLog 2010-05-01 10:42:43 UTC (rev 4880)
@@ -25189,3 +25189,41 @@
   ihs_dbvalue.hpp
 Remove gratuitous dissimilarities.
 
+20100501T0115Z <address@hidden> [737]
+
+  dbvalue.cpp
+  dbvalue.hpp
+  ihs_dbvalue.cpp
+  ihs_dbvalue.hpp
+Mark data members with a '_' suffix.
+
+20100501T0142Z <address@hidden> [737]
+
+  dbvalue.cpp
+  ihs_dbvalue.cpp
+  ihs_dbvalue.hpp
+Respell certain arguments.
+
+20100501T0236Z <address@hidden> [737]
+
+  dbvalue.cpp
+  dbvalue.hpp
+Remove gratuitous dissimilarities.
+
+20100501T0306Z <address@hidden> [735]
+
+  dbvalue.hpp
+  ihs_dbvalue.hpp
+Remove even more gratuitous dissimilarities, rendering two headers
+practically identical.
+
+20100501T1042Z <address@hidden> [735]
+
+  Makefile.am
+  database_view_editor.hpp
+  ihs_database.cpp
+  ihs_dbdict.hpp
+  ihs_dbvalue.cpp
+  ihs_dbvalue.hpp [expunged]
+Merge two headers.
+

Modified: lmi/trunk/Makefile.am
===================================================================
--- lmi/trunk/Makefile.am       2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/Makefile.am       2010-05-01 10:42:43 UTC (rev 4880)
@@ -911,7 +911,6 @@
     icon_monger.hpp \
     ihs_commfns.hpp \
     ihs_dbdict.hpp \
-    ihs_dbvalue.hpp \
     ihs_funddata.hpp \
     ihs_irc7702a.hpp \
     ihs_irc7702.hpp \

Modified: lmi/trunk/database_view_editor.hpp
===================================================================
--- lmi/trunk/database_view_editor.hpp  2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/database_view_editor.hpp  2010-05-01 10:42:43 UTC (rev 4880)
@@ -34,11 +34,11 @@
 #include "multidimgrid_safe.hpp"
 #include "multidimgrid_tools.hpp"
 
-// EVGENIY !! I suspect that we can avoid including "ihs_dbvalue.hpp"
+// EVGENIY !! I suspect that we can avoid including "dbvalue.hpp"
 // here by reworking or moving code for which a forward declaration
 // doesn't work today.
 
-#include "ihs_dbvalue.hpp"
+#include "dbvalue.hpp"
 
 #include <boost/shared_ptr.hpp>
 
@@ -147,7 +147,7 @@
 
 /// Class is the version of MultiDimGrid customized for '.database' data.
 ///
-/// Grid edit the data that depends upon 7 axis described in ihs_dbvalue.hpp
+/// Grid edit the data that depends upon 7 axis described in 'dbvalue.hpp'
 
 class DatabaseEditorGrid
   :public MultiDimGrid

Modified: lmi/trunk/ihs_database.cpp
===================================================================
--- lmi/trunk/ihs_database.cpp  2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/ihs_database.cpp  2010-05-01 10:42:43 UTC (rev 4880)
@@ -35,8 +35,8 @@
 #include "assert_lmi.hpp"
 #include "data_directory.hpp"
 #include "dbnames.hpp"
+#include "dbvalue.hpp"
 #include "ihs_dbdict.hpp"
-#include "ihs_dbvalue.hpp"
 #include "oecumenic_enumerations.hpp"
 #include "product_data.hpp"
 #include "yare_input.hpp"

Modified: lmi/trunk/ihs_dbdict.hpp
===================================================================
--- lmi/trunk/ihs_dbdict.hpp    2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/ihs_dbdict.hpp    2010-05-01 10:42:43 UTC (rev 4880)
@@ -30,7 +30,7 @@
 
 #include "config.hpp"
 
-#include "ihs_dbvalue.hpp" // Needed here for map declaration.
+#include "dbvalue.hpp" // Needed here for map declaration.
 #include "obstruct_slicing.hpp"
 #include "so_attributes.hpp"
 

Modified: lmi/trunk/ihs_dbvalue.cpp
===================================================================
--- lmi/trunk/ihs_dbvalue.cpp   2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/ihs_dbvalue.cpp   2010-05-01 10:42:43 UTC (rev 4880)
@@ -26,7 +26,7 @@
 #   pragma hdrstop
 #endif // __BORLANDC__
 
-#include "ihs_dbvalue.hpp"
+#include "dbvalue.hpp"
 
 #include "alert.hpp"
 #include "assert_lmi.hpp"

Deleted: lmi/trunk/ihs_dbvalue.hpp
===================================================================
--- lmi/trunk/ihs_dbvalue.hpp   2010-05-01 03:06:19 UTC (rev 4879)
+++ lmi/trunk/ihs_dbvalue.hpp   2010-05-01 10:42:43 UTC (rev 4880)
@@ -1,207 +0,0 @@
-// Product-database entity.
-//
-// Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 
2008, 2009, 2010 Gregory W. Chicares.
-//
-// This program is free software; you can redistribute it and/or modify
-// it under the terms of the GNU General Public License version 2 as
-// published by the Free Software Foundation.
-//
-// This program is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-//
-// You should have received a copy of the GNU General Public License
-// along with this program; if not, write to the Free Software Foundation,
-// Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
-//
-// http://savannah.nongnu.org/projects/lmi
-// email: <address@hidden>
-// snail: Chicares, 186 Belle Woods Drive, Glastonbury CT 06033, USA
-
-// $Id$
-
-#ifndef ihs_dbvalue_hpp
-#define ihs_dbvalue_hpp
-
-#ifdef dbvalue_hpp
-#   error Probable lmi/ihs header conflict.
-#endif // dbvalue_hpp
-
-#include "config.hpp"
-
-#include "dbindex.hpp"
-#include "obstruct_slicing.hpp"
-#include "so_attributes.hpp"
-#include "xml_lmi_fwd.hpp"
-
-#include <iosfwd>
-#include <string>
-#include <vector>
-
-namespace xml_serialize {template<typename T> struct xml_io;}
-
-/// Product-database entity.
-///
-/// Each entity varies across zero or more of the following axes:
-///   - gender
-///   - underwriting class
-///   - smoker
-///   - issue age
-///   - underwriting basis
-///   - state
-///   - duration [i.e., number of years since issue]
-/// in that order.
-///
-/// The last index is duration; i.e., duration varies most rapidly of
-/// all axes. In a typical query, all other axes are single-valued,
-/// but all durations are wanted; this axis ordering puts consecutive
-/// durational values in contiguous storage for efficient retrieval.
-
-class LMI_SO TDBValue
-    :virtual private obstruct_slicing<TDBValue>
-{
-    friend struct xml_serialize::xml_io<TDBValue>;
-
-  public:
-    // Separate enumerators here facilitate compile-time assertions
-    // in the database GUI, q.v.--an array could not be indexed to
-    // produce an arithmetic constant expression [5.19/3].
-    enum {e_number_of_axes    = 1 + TDBIndex::MaxIndex};
-    enum {e_max_dim_gender    =   3};
-    enum {e_max_dim_class     =   4};
-    enum {e_max_dim_smoking   =   3};
-    enum {e_max_dim_issue_age = 100};
-    enum {e_max_dim_uw_basis  =   5};
-    enum {e_max_dim_state     =  53};
-    enum {e_max_dim_duration  = 100};
-
-    TDBValue();
-    TDBValue
-        (int                key
-        ,int                ndims
-        ,int const*         dims
-        ,double const*      data
-        ,std::string const& gloss = std::string()
-        );
-    TDBValue
-        (int                        key
-        ,std::vector<int> const&    dims
-        ,std::vector<double> const& data
-        ,std::string const&         gloss = std::string()
-        );
-    TDBValue
-        (int                key
-        ,double             datum
-        ,std::string const& gloss = std::string()
-        );
-    TDBValue(TDBValue const&);
-    TDBValue& operator=(TDBValue const&);
-    ~TDBValue();
-
-    double const* operator[](TDBIndex const& idx) const;
-    double&       operator[](std::vector<int> const& idx);
-    double const* operator[](int const* idx) const; // Antediluvian
-
-    int GetKey()            const;
-    int GetNDims()          const; // Antediluvian: detect default-contructed 
objects.
-    int GetLength()         const;
-    int GetLength(int axis) const;
-    std::vector<int> const& GetAxisLengths() const;
-
-    void Reshape(std::vector<int> const& dims);
-
-    std::ostream& write(std::ostream&) const;
-
-    static std::vector<int> const& maximum_dimensions();
-    static bool Equivalent(TDBValue const&, TDBValue const&);
-    static bool VariesByState(TDBValue const&);
-
-  private:
-    int  getndata()      const;
-    void ParanoidCheck() const;
-    bool AreAllAxesOK()  const;
-
-    void read (xml::element const&);
-    void write(xml::element&) const;
-
-    int                 key_;
-    std::vector<int>    axis_lengths_;
-    std::vector<double> data_values_;
-    int                 ndims_; // Antediluvian: number of dimensions
-    int*                dims_;  // Antediluvian: dimensions
-    int                 ndata_; // Antediluvian: number of data
-    double*             data_;  // Antediluvian: data
-    std::string         gloss_;
-};
-
-/*
-Database items should be allowed to vary across numerous axes, such as
-    gender
-    underwriting class (e.g. preferred, standard, and various substd tables)
-    smoker
-    issue age (or attained age as an optional alternative?)
-    medical/paramedical/nonmedical
-    rate bands (see below)
-and maybe
-    months (e.g. lapse skewness)
-    mode (e.g. for lapse rate or mode weighting)
-and last of all
-    duration
-
-Does it make sense to use one axis each for
-    issue age--every year
-    issue age--quinquennial
-    issue age--decennial?
-Is it more natural to allow just the first, and offer a variety of methods
-for interpolation? Or does it make sense to offer just one issue-age axis,
-but provide a means of choosing whether it means annual, quinquennial, or
-whatever? I'm inclined to use just one axis.
-
-Rate bands are a horse of a different color. All axes are discrete, but for the
-others, the quantum values are dictated by nature. Even if a fractional gender
-status is contemplated as for a unisex product, database items are likely to be
-either a combination of discrete quantum states or a precalculated average that
-does not vary across the gender axis. But band breaks may vary across products.
-
-We could address this by adding a list of values, rather than hardcoding it.
-If we do that for band, then why not for gender as well? Why not for all axes?
-
-We choose not to make current/guaranteed a database axis. Of course it's a
-conceptual axis, across which many database entries do vary. But in practice
-the guaranteed and current versions of such an entry will often have different
-shapes. For instance, current COI rates may be select and ultimate while
-guaranteed COI rates are attained age--and if we represent this variation as
-an axis here, guaranteed COI rates must be coerced into a select and ultimate
-form. We think this problem is unlikely to arise with the axes we've chosen.
-
-The intention is to use this database for offline storage of almost all data.
-We want to provide an interface to the SOA's mortality table manager as an
-option. This is advantageous because it's a standard published program with
-carefully checked tables that will probably be expanded in the future. It's an
-option because not everyone will have it installed; for a build of this system
-that is limited to illustration applications, it may be desired not to use the
-SOA program for reasons of space.
-
-Note however that the SOA program does not handle very large tables correctly
-without modification. And even with modification it handles such tables slowly.
-The CRC check is costly.
-
-Probably the best approach is to use the SOA program for the things it does
-well, and the database otherwise. What does the SOA program do well?
-  usable GUI; new spreadsheet interface
-    apparently an add-in written only for one non-free spreadsheet
-  many tables, independently checked, often updated
-It seems better to provide a utility to "compile" an SOA table to this database
-format, and then always use the database. One advantage is that it'll run a lot
-faster. Another is that the tables are less easily viewed or modified by people
-who shouldn't; protecting integrity of data is a public policy concern, and
-preventing fraud not inconsistent with open source software. Even though the
-database code is open source, the data files it reads are not. It would be
-simple enough to add a proprietary encryption layer as a plugin between the
-present software and any sensitive file, with a default implementation that
-performs no encryption.
-*/
-
-#endif // ihs_dbvalue_hpp
-