Re: Results for Debian Project Leader 2026 Election

* 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.