Re: [lmi] Unit test for PDF get_extra_pages_needed() function

[Greg Chicares]

On 2018-02-10 18:23, Greg Chicares wrote:
[...]
> What are the actual preconditions, and where are they enforced?
> The header:
>   /// Preconditions: total_rows > 0 && rows_per_page >= rows_per_group > 0
> seems to list more preconditions than the implementation:
>   // The caller must check for this precondition because this function is too
>   // low-level to be able to handle it correctly, e.g. it can't even use the
>   // appropriate error message.
>   LMI_ASSERT(rows_per_page >= rows_per_group);

The number of data rows cannot less than zero, but I think we need to allow
it to equal zero. To see why...

File | New | Census
Census | Edit cell
  on "Payments" tab:
    change "Individual payment" from default 20000 to 1
    OK
Census | Add cell
Census | Print case to PDF

The first cell doesn't survive even one month. In the problem domain, we'd
say it lapses immediately; in the solution domain, it has zero data rows.

Expected outcome: a PDF is created for each cell, and another one for the
composite. The first cell's PDF reflects its immediate lapse, somehow
(there may be some freedom in how we do that), but that doesn't prevent
the other cells from running or the composite from being generated.

Running with '--pyx=only_old_pdf' produces the desired outcome. The first
cell's PDF has zero data rows: it's like a PDF with one data row, except
that it has no data rows.

Running with '--pyx=only_new_pdf' produces only one PDF, for the first
cell only, and that PDF consists of a single blank page; because this
assertion in pre_render()
          LMI_ASSERT(extra_pages_ >= 0);
fails, processing stops, and no PDF is created for the second cell,
even though that second cell is valid.

I'm not sure exactly what we should ideally do for the first cell.
The '--pyx=only_old_pdf' behavior is acceptable because it has been in
production for decades and nobody has complained about it. Probably we
should copy that behavior. As an enhancement, maybe there should be some
indication that it lapsed (we'll have to see what end users think).

However, I don't think we can throw an exception and stop processing
the census. If the 900th of 1000 cells lapses before the end of the
first year, end users will have to alter the input to prevent that,
in order to get PDFs for the last 100 cells; but the input file might
be exactly what they want, such that they won't want to alter it.

I tried commenting out the assertion just to see what happens, not
really expecting that this would be the ultimate solution. Rerunning
the case this way, I saw:
  Logic error: there should have been -1 more pages after the page 5
and the first cell's PDF indeed showed "page 5 of 4", but PDFs were
produced for the other cells. I guess that logic error must be thrown
in a context where it's caught without preventing the other cells from
running, which is a step in the right direction.