Skip Menu |

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

Report information
The Basics
Id: 131827
Status: open
Priority: 0/
Queue: Math-BigInt

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

Bug Information
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