Re: [lmi] [lmi-commits] master a91cbc67: Make two comparisons work even for x87

[Vadim Zeitlin]

On Wed, 11 May 2022 10:52:42 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:

GC> branch: master
GC> commit a91cbc67d7479e4b51a268748b9d1dabe2b66806
GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> 
GC>     Make two comparisons work even for x87
GC>     
GC>     Replacing a 7PP-rate table to address this anomaly:
GC>     
GC>       https://lists.nongnu.org/archive/html/lmi/2022-05/msg00006.html
GC>     | Table #10 specifies 8 decimals, but 17 were necessary.
GC>     
GC>     caused MEC year to change from 12 (correct) to 3 (incorrect) for one
GC>     test case.
GC>     
GC>     Changing the if-conditional from "X < Y" to "X < Y && X ≉ Y":
GC>       if(CumSevenPP < CumPmts && !materially_equal(CumSevenPP, CumPmts))
GC>     fixed that test case. However, that fix caused the assertion to fire for
GC>     a second test case; changing it from "X ≤ Y" to "X ≤ Y || X ≈ Y":
GC>       CumPmts <= CumSevenPP || materially_equal(CumSevenPP, CumPmts)
GC>     prevented it from firing, and resolved a latent problem with that test
GC>     case.

 IMHO these checks would be more readable if we had a materially_less() or
its moral equivalent under some other name ("substantially_less" perhaps?).

GC> @@ -557,7 +557,12 @@ double Irc7702A::MaxNonMecPremium
GC>          {
GC>          if(TestPeriodDur < TestPeriodLen)
GC>              {
GC> -            LMI_ASSERT(CumPmts <= CumSevenPP);
GC> +            // Weird condition--see:
GC> +            //   
https://lists.nongnu.org/archive/html/lmi/2022-05/msg00006.html
GC> +            LMI_ASSERT
GC> +                (  CumPmts <= CumSevenPP
GC> +                || materially_equal(CumSevenPP, CumPmts)
GC> +                );

 And having such function would also allow to put this URL in a single
place instead of duplicating it wherever it's applicable.

 Of course, it's just a nitpick, I don't have anything materially
significant to contribute here as I don't see any better solution to the
problem.

 Regards,
VZ

pgpD0UffiQb5X.pgp
Description: PGP signature