[lmi] An ironic i686+i87 surprise

[Greg Chicares]

An anomaly in this file from 2005:
  https://download.savannah.gnu.org/releases/lmi/lmi-data-20050618T1440Z.tar.bz2
was unearthed by the rate-table tool:
  $wine /opt/lmi/bin/rate_table_tool.exe --accept --file=/opt/lmi/data/sample 
--extract-all
[...]
  Table #10 specifies 8 decimals, but 17 were necessary.
  This flaw has been corrected, and the CRC recalculated.
  [rate_table.cpp : 1860]
so I corrected it by truncating the data to eight decimals (locally for
now, but I plan to upload a replacement soon).

Running a system test and inspecting all the differences carefully, I found
exactly one unexpected regression: on an ancient test case that pays exactly
the so-called "seven-pay premium" (a tax limit) each year, the cumulative
payment now exceeds the cumulative limit in year three. You don't have
to understand US taxation to grasp this: just think of the limit as $X;
you are allowed to pay exactly $X for the first seven years; each year, lmi
tests whether the cumulative amount actually paid exceeds the limit, i.e.:
  test (N * $X) > (N * $X), for each integral year N={1,2,3,4,5,6,7}
That a value cannot exceed itself is not axiomatic in x87 arithmetic.

Of course, I'm subliminally aware of that, but in practice I've coded
such statements as though the reflexive axiom holds, and exercised more
care in cases where the evidence says otherwise (as, for example, in
the condition:
  materially_equal(cum_prem, CumPmts)
that occurs later in the same file). Now the evidence has changed, as
explained in this article I was just reading:

https://hal.archives-ouvertes.fr/hal-00128124/file/floating-point-article.pdf
| All designs — such as the common compilation schemes on the Intel 32-bit
| platform — where the results can change depending on seemingly irrelevant
| circumstances such as the insertion of a “print” statement make debugging 
fringe
| conditions in floating-point programs difficult, because the insertion of 
logging
| instructions may perturb results. They also make several program analysis
| techniques unsound, leading to sometimes expensive fixes.

No anomaly in this particular condition had never previously arisen,
neither in our 1400 regression-test cases, nor in production (where,
if it had occurred, some end user would have pointed it out to us).

The values even look identical (though their difference is not zero):
  Warning: 
  221576.600000000005821 CumPmts
  221576.600000000005821 CumSevenPP
  7.27595761418342590332e-12 excess
  [ihs_irc7702a.cpp : 723]
when I insert a "print" statement thus:

--8<----8<----8<----8<----8<----8<----8<----8<----8<--
diff --git a/ihs_irc7702a.cpp b/ihs_irc7702a.cpp
index 35a1abece..ee4c68fd8 100644
--- a/ihs_irc7702a.cpp
+++ b/ihs_irc7702a.cpp
@@ -709,9 +709,19 @@ double Irc7702A::UpdatePmt7702A
             }
         */
         CumPmts += a_Payment;
-        if(CumSevenPP < CumPmts)
+        double excess = CumPmts - CumSevenPP;
+        if(0.0 < excess)
+//      if(CumSevenPP < CumPmts)
             {
             IsMec = true;
+            warning() << std::setprecision(21);
+            warning()
+                << '\n'
+                << CumPmts << " CumPmts\n"
+                << CumSevenPP << " CumSevenPP\n"
+                << excess << " excess\n"
+                << LMI_FLUSH
+                ;
 /* TODO ?? TAXATION !! Reenable after testing.
             if(mce_reduce_prem == AvoidMec)
                 {
--8<----8<----8<----8<----8<----8<----8<----8<----8<--

I discovered this anomaly because this:
  Table #10 specifies 8 decimals, but 17 were necessary.
violates a precondition that I'd like to assert in 'ul_utilities.cpp',
(whose motivation was to reduce the regression-test differences
between 32- and 64-bit builds)--ironically, because the anomaly is
not reproduced in 64-bit builds.