https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6419
--- Comment #8 from Kevin A. McGrail <[email protected]> 2010-05-30 18:25:36 EDT --- (In reply to comment #7) > +0.1 > > I don't mind the proposed change. I'm just rather skeptical > on this entire rounding business - the deeper these tricks go > and the more complex they become, the more difficult it is > to explain how this all works. Like opening a can of worms. > If it were my code, I'd ditch the whole rounding magic and > just let the sprintf %f do its rounding job to whatever format > is required in each presentation text. Users should realize > by now (during the last 50 years) how this floating point > arithmetics works. Mark, I don't disagree but bug 2607 was the original bug. All this patch is doing is using the same code everywhere that was previously implemented. The previous implementation missed code in spamc/spamd that has been overlooked until now. And I think for me, a major change would be to report to 5 decimal places. Because this really isn't a floating point arithmetic issue. This is a rounding up for the reporting but using the real number for the is_spam flag. Regards, KAM -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
