[Koha-bugs] [Bug 17138] UpdateFine() modyfies existing fine records even when there is no need

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Aug 25 11:38:48 CEST 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17138

--- Comment #5 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
(In reply to Marcel de Rooy from comment #4)
> + if ( $data->{'amount'} ne sprintf('%.6f', $amount) ) {

> Or would rounding with Math::Round::nearest be better than sprintf ?

Quite possibly; sprintf('%.6f', ...) is not ideal, theoretically this
comparison may still fail (but less often then currently) for some borderline
cases, because mysql is supposedly using slightly different kind of rounding
for internal decimal(x,y) arithmetic then sprintf (sprintf: half to even aka
bankers rounding, mysql - half away from zero, commercial rounding).

If someone is having numbers like 1.1212125 (more then 6 fractional digits, and
the 7th digit is 5) in circulation & fine rules, calculated fine amount may get
rounded differently. In such case though, fines.pl being not always as fast as
humanly possible would be the least of his/her problems ;)

> Why not force them both to sprintf and get rid of the hardcoded 6 ?

I guess this can be done in other ways like

   abs($amount1 - $amount2) < 0.000001

but IMO that specific .6 precision is kind of important?

>     my $info = $schema->source('Accountline')->column_info('amount');
>     my $scale = $info->{size}->[1];

This (and adding a new module for more predictable rounding etc.) would be a
good start for solving all prices / fines rounding problems in Koha, once and
for all.. I'm just not entirely happy with starting such monumental task right
in this report, looks like a bit of an overkill to me.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list