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
Download (untitled) / with headers
text/plain 834b
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>
Download (untitled) / with headers
text/plain 2.2k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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