Re: [lmi] Group premium quotes

[Greg Chicares]

On 2015-08-18 21:18, Vadim Zeitlin wrote:
> On Sun, 16 Aug 2015 17:07:38 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I see a small cosmetic issue when running a large census with sizable
> GC> face amounts: the total fields can overflow.
> 
>  I actually thought about this problem but in the haste of the last day
> fixes forgot to mention it, thanks for bringing it up.
> 
> GC> Copying and pasting from
> GC> the first two total fields yields:
> GC>   7$73,383,898.001,4$91,376.55
> GC> The first of those two fields should be
> GC>    773,383,898 [here, as in the rest of this column, no ".00" is needed]
> 
>  OK, this is just my bug, I hadn't realized this. Fixing this is trivial
> though: the code already uses either "f0" or "f2" formats depending on the
> desired number of the digits after the colon, so here "f2" just needs to be
> replaced with "f0".

Either "f0" or "f2", depending on the column: committed 20150826T1702Z,
revision 6268.

That doesn't entirely solve the problem, but it makes it less severe because
the widest column ("Face Amount") is now formatted as an integer. Proceeding...

> GC> Given that this report's only use case is a narrow, specialized niche,
> GC> an expeditious resolution such as widening these two columns by any
> GC> convenient means might be good enough. OTOH, I have the impression
> GC> (without looking at the code, because that would be cheating) that the
> GC> columns widths are calculated based on the header widths (because the
> GC> data in the second and fourth totaled columns are identical in this
> GC> case, and the fourth is wider); if that's the case, then perhaps it's
> GC> just as easy, and better, to take the width of the totals into account.
> 
>  Actually the width is hard coded. I thought it was acceptable to do
> because the column headers themselves are hard coded too, so I just define
> both the header and the corresponding width in the "column_definitions"
> array. This is not very general and would definitely need to be changed if
> we wanted the headers to be customizable by the users but for now this
> makes it very easy to change the columns widths: just add more nines to the
> "widest_text_" field of the corresponding array element.

I added a nine to each (committed 20150826T1714Z, revision 6269), but that
doesn't seem to solve the problem. With this updated format:
    ,{"%s\nPremium"                      ,    "$9,999,999.00"   }
the string "$1,491,376.55" still doesn't fit in the first of four premium
columns, which is narrower than the other three (where similar amounts fit).

> GC> And the headers seem to need more vertical room. I see:
> GC> 
> GC>         |              |              |    Annual
> GC>         |    Annual    |    Annual    | Premium with
> GC>  Annual | Premium with | Premium with |   Waiver &
> GC> 
> GC> where I'd expect another line like
> GC> 
> GC> Premium |    Waiver    |      ADB     |     ADB
> 
>  This is much more worrisome as I didn't see this in my testing. I can't
> easily test this under MSW right now as I only have my Linux notebook which
> doesn't have enough space to allow me to run MSW VM with the full
> development environment on it but I'll retest this as soon as I get back.

Thanks. Don't hurry back just for this.