Post by sl75 on Apr 5, 2016 18:55:43 GMT
Checking my statement just now, I noticed a transaction for EXACTLY £1, to 40 decimal places. It just happened that this was a loan of a precisely round amount where this would have been expected anyway... but had piqued my interest enough to look further.
Scrolling further back, I see that all transactions today, even the ones for discounted loan parts, appear to have decimal expansions ending in 00000000000000, including those for purchases of odd amounts at a discount.
Curious, I taught excel to do long division of numbers beyond its normal processing capability, and found one of the odd amounts to be a precise multiple of 10-28 of the size of the loan. I then checked another (where the outstanding capital of the entire loan was less "round"), and found it to be a precise multiple of 10-24 of the loan.
This would appear to be a subtle internal system change to reduce the amount of excess precision (or "number of shares") stored for each loan.
In previous discussions with chris, I'd advocated splitting the loans into no more than 1018 "shares" in order to make all the accounting exact to 20 decimals, and that 1040 as previously implemented was far too many, due to the rounding errors when the internal systems cannot represent things that precisely.
As we've now got rid of the nonsense where rounding errors can result in transactions ending in long series of 9999 or 0000 followed by some "random" digits from rounding anomalies, we're at least in a position where the transaction amount is being precisely represented in some part of the system (as far as the statement is generated).
I hope that this will allow diagnostics of any other issues to be easier to comprehend by those trying to debug AC's systems (chris and others in his team).
Whilst my personal preference would remain for "shares" of a meaningful fraction of a penny, I'd like to publicly thank AC for this step towards making the system more comprehensible.
Scrolling further back, I see that all transactions today, even the ones for discounted loan parts, appear to have decimal expansions ending in 00000000000000, including those for purchases of odd amounts at a discount.
Curious, I taught excel to do long division of numbers beyond its normal processing capability, and found one of the odd amounts to be a precise multiple of 10-28 of the size of the loan. I then checked another (where the outstanding capital of the entire loan was less "round"), and found it to be a precise multiple of 10-24 of the loan.
This would appear to be a subtle internal system change to reduce the amount of excess precision (or "number of shares") stored for each loan.
In previous discussions with chris, I'd advocated splitting the loans into no more than 1018 "shares" in order to make all the accounting exact to 20 decimals, and that 1040 as previously implemented was far too many, due to the rounding errors when the internal systems cannot represent things that precisely.
As we've now got rid of the nonsense where rounding errors can result in transactions ending in long series of 9999 or 0000 followed by some "random" digits from rounding anomalies, we're at least in a position where the transaction amount is being precisely represented in some part of the system (as far as the statement is generated).
I hope that this will allow diagnostics of any other issues to be easier to comprehend by those trying to debug AC's systems (chris and others in his team).
Whilst my personal preference would remain for "shares" of a meaningful fraction of a penny, I'd like to publicly thank AC for this step towards making the system more comprehensible.
