[lmi-commits] [lmi] odd/eraseme d1ae1ea 4/4: Use currency type for max non-MEC payment

[Greg Chicares]

branch: odd/eraseme
commit d1ae1eaeef2ed1a1ddd15b47f19703d6a26b1e5d
Author: Gregory W. Chicares <gchicares@sbcglobal.net>
Commit: Gregory W. Chicares <gchicares@sbcglobal.net>

    Use currency type for max non-MEC payment
    
    This commit has a disastrous effect on performance as measured by
    'make cli_timing': for the first ('naic, no solve') scenario, the
    penalty is 14% for i686 and 30% for x86_64. How can that be?
---
 account_value.hpp |  2 +-
 ihs_avmly.cpp     | 23 ++++++++++-------------
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/account_value.hpp b/account_value.hpp
index 44b712d..48a001a 100644
--- a/account_value.hpp
+++ b/account_value.hpp
@@ -233,7 +233,7 @@ class LMI_SO AccountValue final
     void TxTestGPT                  ();
     void TxPmt(); // Antediluvian.
     void TxAscertainDesiredPayment  ();
-    void TxLimitPayment             (double a_maxpmt); // CURRENCY !! not 
currency?
+    void TxLimitPayment             (currency a_maxpmt);
     void TxRecognizePaymentFor7702A
         (currency a_pmt
         ,bool     a_this_payment_is_unnecessary
diff --git a/ihs_avmly.cpp b/ihs_avmly.cpp
index b391970..ba94499 100644
--- a/ihs_avmly.cpp
+++ b/ihs_avmly.cpp
@@ -159,12 +159,14 @@ void AccountValue::DoMonthDR()
 // TAXATION !! Should round here, but need to investigate regressions.
 //  max_necessary_premium = round_max_premium()(max_necessary_premium);
     // CURRENCY !! already rounded by class Irc7702A--appropriately?
-    double max_non_mec_premium = Irc7702A_->MaxNonMecPremium
-        (dblize(Dcv)
-        ,dblize(AnnualTargetPrem)
-        ,YearsTotLoadTgtLowestPremtax
-        ,YearsTotLoadExcLowestPremtax
-        ,dblize(kludge_account_value)
+    currency max_non_mec_premium = round_gross_premium().c
+        (Irc7702A_->MaxNonMecPremium
+            (dblize(Dcv)
+            ,dblize(AnnualTargetPrem)
+            ,YearsTotLoadTgtLowestPremtax
+            ,YearsTotLoadExcLowestPremtax
+            ,dblize(kludge_account_value)
+            )
         );
 
     // Saved for monthly detail report only. TAXATION !! Then are
@@ -1263,13 +1265,10 @@ void AccountValue::TxAscertainDesiredPayment()
 
 /// Limit payment (e.g., to the non-MEC maximum).
 ///
-/// The limit argument is of type double because the taxation code may
-/// return DBL_MAX. CURRENCY !! Can currency work with such values?
-///
 /// TAXATION !! Should this be called for gpt? or, if it's called,
 /// should it assert that it has no effect?
 
-void AccountValue::TxLimitPayment(double a_maxpmt)
+void AccountValue::TxLimitPayment(currency a_maxpmt)
 {
 // Subtract premium load from gross premium yielding net premium.
 
@@ -1288,9 +1287,7 @@ void AccountValue::TxLimitPayment(double a_maxpmt)
             gross_1035 = External1035Amount + Internal1035Amount;
             }
         currency gross_pmt_without_1035 = GrossPmts[Month] - gross_1035;
-        // CURRENCY !! support infinities?
-//      gross_pmt_without_1035 = std::min(gross_pmt_without_1035, a_maxpmt);
-        gross_pmt_without_1035 = 
round_gross_premium().c(std::min(dblize(gross_pmt_without_1035), a_maxpmt));
+        gross_pmt_without_1035 = std::min(gross_pmt_without_1035, a_maxpmt);
         // TODO ?? For now at least, reduce employee premium first.
         progressively_limit
             (EeGrossPmts[Month]