lmi
[Top][All Lists]
Advanced

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

Re: [lmi] wx_test_default_input.cpp


From: Vadim Zeitlin
Subject: Re: [lmi] wx_test_default_input.cpp
Date: Sun, 14 Dec 2014 22:33:59 +0100

On Fri, 12 Dec 2014 21:07:38 +0000 Greg Chicares <address@hidden> wrote:

GC> /// Test selected parameters in the user-customizable default cell.
GC> ///
GC> /// Run this test only when the '--distribution' option is given.
GC> ///
GC> /// Write "ProductName" and "GeneralAccountRate" to stdout in that
GC> /// order on a single line. We maintain several different binary
GC> /// distributions, each with a specific default product, and that
GC> /// product's general-account rate is a crucial parameter that often
GC> /// varies from one month to the next, so a spot check seems wise.
GC> ///
GC> /// The expected value of "EffectiveDate" is normally the first day
GC> /// of the next month. (For example, to prepare a distribution that
GC> /// is to be used beginning January first, we must run this test in
GC> /// December, as validation should precede dissemination.)

 I wonder if the recent prospicience-related discussions change anything
for this retroactively (antespiciensly?)?

GC> /// Write both "EffectiveDate" and its expected value to stdout, both
GC> /// as JDN and as YYYYMMDD, all on a single line, e.g.:
GC> ///   EffectiveDate: 2457024 2015-01-01  expected: 2457024 2015-01-01
GC> /// Then print a warning on a separate line iff these two dates do not
GC> /// match; do this after writing parameters to stdout, so that they're
GC> /// still written even if this test abends. Inequality is an unusual
GC> /// condition requiring attention, but not necessarily an error, so a
GC> /// mere warning suffices; program flow should not be interrupted as
GC> /// for an assertion failure.

 Assuming they do not, here are the patches implementing the above with
just some very minor differences in output formatting: as I took the
existing date output code, the date is output as "2457024 (2015-01-01)",
i.e. uses extra parentheses compared to the above. I also separated the
fields with semicolons. In both cases it would be trivial to change this,
of course, I didn't do it just because I believe the current version is
more readable, but please let me know if you disagree.

 FWIW it would also make more sense to me to output the expected date only
if it's different from the effective one, but as you explicitly asked to
output both of them, even if they are equal, I did do it as requested,
although I admit I still wonder why is this useful. This is not very
important, of course.

 Here is an example of full output (with --distribution option):

        default_input: started
        EffectiveDate: 2456963 (2014-11-01); expected: 2457024 (2015-01-01)
        Warning: Effective date is different from the expected date.
        ProductName="sample"; GeneralAccountRate="0.06"
        time=120ms (for default_input)
        default_input: ok

 As always, please let me know if you see any problems with these patches,
VZ

Attachment: 0001-Refactor-extract-date-helpers-used-by-the-test-into-.patch
Description: Text document

Attachment: 0002-Update-default-input-test-to-correspond-to-the-revis.patch
Description: Text document


reply via email to

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