This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id:
131827
Status:
open
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
pjacklam [...] gmail.com
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
1.999818
Fixed in:
(no value)



Subject: Mixing accuracy and precision creates NaN
Mixing operand where one has accuracy set and the other has precision set, returns NaN: use strict; use warnings; use Math::BigFloat; my $x = Math::BigFloat -> new(6); $x -> accuracy(5); my $y = Math::BigFloat -> new(4); $y -> precision(-3); my $zadd = $x + $y; # = NaN my $zmul = $x * $y; # = NaN my $zsub = $x - $y; # = NaN my $zdiv = $x / $y; # = NaN my $zpow = $x ** $y; # = NaN The actual code that creates the NaN is in Math::BigInt::round(), where a comment says "set A and set P is an fatal error". It should be possible to get a meaningful result, even when both accuracy and precision is set. I consider the current behaviour to be a bug. If I remember correctly, IEEE 754-2008 states that the rounding parameters are determined by the first operand.
Subject: Re: [rt.cpan.org #131827] Mixing accuracy and precision creates NaN
Date: Fri, 21 Feb 2020 19:52:19 +0100
To: bug-Math-BigInt@rt.cpan.org
From: Te <nospam-abuse@bloodgate.com>
Moin Peter, On 2020-02-16 14:18, Peter John Acklam via RT wrote:
Show quoted text
> Sun Feb 16 08:18:23 2020: Request 131827 was acted upon. > Transaction: Ticket created by pjacklam > Queue: Math-BigInt > Subject: Mixing accuracy and precision creates NaN > Broken in: 1.999818 > Severity: (no value) > Owner: Nobody > Requestors: pjacklam@gmail.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=131827 > > > > Mixing operand where one has accuracy set and the other has precision > set, returns NaN: > > use strict; > use warnings; > use Math::BigFloat; > > my $x = Math::BigFloat -> new(6); > $x -> accuracy(5); > > my $y = Math::BigFloat -> new(4); > $y -> precision(-3); > > my $zadd = $x + $y; # = NaN > my $zmul = $x * $y; # = NaN > my $zsub = $x - $y; # = NaN > my $zdiv = $x / $y; # = NaN > my $zpow = $x ** $y; # = NaN > > The actual code that creates the NaN is in Math::BigInt::round(), > where a comment says "set A and set P is an fatal error". > > It should be possible to get a meaningful result, even when both > accuracy and precision is set. I consider the current behaviour to be > a bug. > > If I remember correctly, IEEE 754-2008 states that the rounding > parameters are determined by the first operand.
When I wrote that code, mixing A and P did not make sense to me, so the design decision was taken. It looks it never made it into the documentation, tho. I'm not opposed to a change here, though. There are of course multiple ways: * follow the first operand (as you propose) * follow the operand with the higher (or lower) accuracy? * always use the operand which has A (or P) set? For instance, both "3 + 3.5" and "3.5 + 3 " create "6.5" under bignum, not 6, as a "follow first operand" would indicate. So care must be taken to create meaningful operations and results. Having "$a + $b" be the same as "$b + $a" can be useful. So, what should the following example: $ perl -MMath::BigFloat -wle '$y = Math::BigFloat->new(14); $y->precision(-3); print $y," ",$y+1.5," ",$y+Math::BigFloat->new(1,5)," ",Math::BigFloat->new(1,5)+$y' 4.000 5.500 NaN NaN print as the last two strings? Best regards, Tels
I don't have a solution yet, but the current implementation makes it difficult to use higher accuracy for intermediate computations. Creating temporary objects with a higher accuracy doesn't help, since the lowest accuracy will always be chosen anyway. The current implementation gets around this problem by undefining the accuracy globally, performing the computation, and re-assigning the global values. This works, but using global variables is not good OO practice, and the code is not thread safe.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.