On Wed, Feb 24, 2010 at 1:13 AM, Luke <[email protected]> wrote: > On Tue, 23 Feb 2010, Bob Miller wrote: > > See David's message for a supposed fix, but as for what's going on...: > >> One of my clients has recently noticed a slight peculiarity in the >> percentage discount, and I have been able to verify it. >> For example, sell 252 items at $1.05 with a 15% discount. By my handy >> dandy calculator application, 252*1.05*.85=224.91. However, on the >> invoice, the total calculated is $224.28. It is a small difference, >> however, it grows when more items are sold. When we put on another > > Your math is not the math which the program does. It does > this: > 1.05 * 0.85 * 252. That would still be okay, until you show your work. > > 1.05 * 0.85 = 0.8925 > 0.8925 Internal round to 2 decimal places = 0.89 > 0.89 * 252 = 224.28 >
That's the way this is handled currently. > This has bugged me to no end. SL had a way to change the precision, but > LSMB dropped it for reasons I knew not, and provided no workaround for > this problem [until now]. > The dropping was a side-effect of moving to BigFloats and managing precision. This was necessary to avoid some of the rounding bugs we found in the code we inherited. Unfortunately I am not sure there is a straight-forward solution here due to the way precision is tracked. I am going to try to come up with a bug fix for it shortly, however. Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
