lmi-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi-commits] [lmi] master f9b937f 5/7: Round increments and decrements


From: Greg Chicares
Subject: [lmi-commits] [lmi] master f9b937f 5/7: Round increments and decrements better
Date: Wed, 27 Jan 2021 20:57:46 -0500 (EST)

branch: master
commit f9b937fefb85f8af96e00dbeae8eee5338e3b46c
Author: Gregory W. Chicares <gchicares@sbcglobal.net>
Commit: Gregory W. Chicares <gchicares@sbcglobal.net>

    Round increments and decrements better
    
    Increments and decrements to real-world accounts are whole cents only.
    That ideal is not achievable with floating-point fractional dollars
    (it will be with whole cents). In the meantime, this commit approaches
    closer to the ideal. For instance, examining "AcctVal" in a realistic
    (proprietary) testcase that /opt/lmi/test/regressions.tsv identifies
    as the one having the greatest differences, the values in the first
    three years are:
    
    new 8994.02999999999883585
    old 8994.03000000000247383
    new 18632.3600000000005821
    old 18632.3600000000005821
    new 29144.3100000000013097
    old 29144.3100000000049477
    
    In the first pair, ...988 is off by 12, but ...024 is off by 24, so
    the "new" result (this commit) is better than the "old" (previously).
    In the second pair (for the second year), the values are the same: both
    are the closest floating-point value to 18632.36 . In the third year,
    the difference is larger, and it's obvious which is more accurate.
    
    Later, in the fifty-eighth year, values are off by a full cent:
    
    new 11272352.3300000000745
    old 11272352.3399999793619
    
    which accumulates to fifteen cents by the eightieth year.
    
    If lmi were going to continue representing values as floating-point
    dollars, this refinement would seem too precious to bother with.
    However, it's soon going to switch to integral cents instead (which
    matters much more in other cases than this), so this commit improves
    precision as much as it can in order to minimize regressions when that
    switch is made.
---
 ihs_avmly.cpp | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/ihs_avmly.cpp b/ihs_avmly.cpp
index 7d9b3c8..5b32d63 100644
--- a/ihs_avmly.cpp
+++ b/ihs_avmly.cpp
@@ -347,6 +347,10 @@ void AccountValue::IncrementAVProportionally(currency 
increment)
     currency genacct_increment = round_minutiae().c(increment * 
GenAcctPaymentAllocation);
     AVGenAcct += genacct_increment;
     AVSepAcct += increment - genacct_increment;
+#if !defined CURRENCY_UNIT_IS_CENTS
+    AVSepAcct = round_minutiae().c(dblize(AVSepAcct));
+    if(0.0 == dblize(AVSepAcct)) AVSepAcct = C0; // Negate negative zeroes.
+#endif // !defined CURRENCY_UNIT_IS_CENTS
 }
 
 //============================================================================
@@ -477,6 +481,10 @@ void AccountValue::DecrementAVProportionally(currency 
decrement)
     currency genacct_decrement = round_minutiae().c(decrement * 
general_account_proportion);
     AVGenAcct -= genacct_decrement;
     AVSepAcct -= decrement - genacct_decrement;
+#if !defined CURRENCY_UNIT_IS_CENTS
+    AVSepAcct = round_minutiae().c(dblize(AVSepAcct));
+    if(0.0 == dblize(AVSepAcct)) AVSepAcct = C0; // Negate negative zeroes.
+#endif // !defined CURRENCY_UNIT_IS_CENTS
 }
 
 /// Apportion decrements to account value between separate- and



reply via email to

[Prev in Thread] Current Thread [Next in Thread]