* Kurt Roeckx <[email protected]>, 2026-08-16 16:57:
Option 1 passes Majority. 5.000 (289/50) >= 1
...
The conclusion seems correct, but not the math.
This seems to be a bug with Math::BigInt in dvt-rslt. Compare:
$ perl -e 'use Math::BigInt ":constant"; print 1.0 * 289 / 50'
5
$ perl -e 'use Math::BigInt; print 1.0 * 289 / 50'
5.78
That's not quite what happens in dvt-rslt. The vote counts are actually
Math::BigFloat objects, which is bonkers already. But how come the
result is integer if all the operands are floating point?
I believe the culprit is this change in Math::BigInt 1.999825 (released
on 2021-09-28):
* When numeric constants are overloaded (with the ":constant" option) in
Math::BigInt, every numeric constant that represent an integer is converted
to an object regardless of how it is written. All finite non-integers are
converted to a NaN.
So now 1.0 is a BigInt; and apparently BigInt multiplied by BigFloat
is a BigInt, and then divided by a BigFloat is a BigInt again. Oops.
Getting rid of the 1.0 multiplication should fix the bug:
--- a/dvt-rslt
+++ b/dvt-rslt
@@ -354 +354 @@ EOM
- my $ratio = 1.0 * $Beat_Matrix[$i][$max_choices - 1] /
+ my $ratio = $Beat_Matrix[$i][$max_choices - 1] /
But in the long run, I'd recommend migrating away from Math::Big*
modules. Builtin Perl numbers are less likely to blow your feet off and
they seem good enough for devotee's purposes.
--
Jakub Wilk
