[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Group premium quotes
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Group premium quotes |
Date: |
Fri, 14 Aug 2015 02:12:27 +0200 |
On Thu, 13 Aug 2015 00:58:50 +0000 Greg Chicares <address@hidden> wrote:
GC> On 2015-07-17 02:25, Greg Chicares wrote:
GC> > On 2015-07-16 15:11, Vadim Zeitlin wrote:
GC> >
GC> >> - Numbers in all 4 "Quarterly premium" columns.
GC> >
GC> > Four new fields to be added to class LedgerInvariant. I could assign names
GC> > now for your use, but I'd rather wait until the compliance review is
complete
GC> > in case any more columns are needed.
GC>
GC> It seems pretty certain that no more columns are wanted, so these four
members
GC> double InitModalPrem00; // without riders
GC> double InitModalPrem01; // with WP only
GC> double InitModalPrem10; // with ADB only
GC> double InitModalPrem11; // with ADB and WP
GC> have been added to class LedgerInvariant on 20150813T0039Z.
Thank you, I've updated the code to use them, both for the column values
and for the totals. One small problem I have now is that the value of these
fields seems to vary significantly among the different cells of the same
census and in the example I'm using they have a different number of digits,
making the centered numbers look ugly (IMHO). I had chosen to center them
because the prototype did so, but I wonder if I should switch to right
aligning them instead?
GC> Key:
GC> WP = "waiver of premium"
GC> ADB = "accidental death benefit"
Thank you for the ADB explanation, I was wondering why using Android debug
bridge increased the premium so much...
GC> I went all cryptic on the names out of fear that the rider combinations
GC> might expand in future years, and I don't want names like
GC>
InitialModalPremium_WithWaiver_WithoutAccidentalDeathBenefit_WithSpouseRider_WithoutChildrenRider_WithGuaranteedInsurabilityOption_WithoutTermRider
GC> when
GC> InitModalPrem101010
GC> might reasonably be considered no less readable.
I'm sorry but I disagree. The current name choices seem to be really
unfortunate to me, it will be all but impossible to notice using a wrong
field. I'd definitely prefer to use symbolic names if it's not too late to
change your mind.
GC> Well, if it comes to that, we could talk about, say, putting these
GC> premiums in a bitfield-indexed array....
This would also be better but IMHO an overkill for just 4 fields. And we
can be relatively confident that there won't be much more of them because
there is just no place for many more columns in the report...
Regards,
VZ