Skip Menu |
 

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

Report information
The Basics
Id: 62764
Status: resolved
Priority: 0/
Queue: Math-BigInt

People
Owner: Nobody in particular
Requestors: peter.john.acklam [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 1.76
  • 1.77
  • 1.78
  • 1.79
  • 1.80
  • 1.82
  • 1.83
  • 1.84
  • 1.85
  • 1.86
  • 1.87
  • 1.88
  • 1.89
  • 1.90
  • 1.91
  • 1.92
  • 1.93
  • 1.95
  • 1.96
Fixed in: (no value)



Subject: bcmp() fails for very large numbers
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 755
Download (untitled) / with headers
text/plain 755b
bcmp() fails for very large numbers. In the case below, $x and $y are different, yet bcmp() returns 1, as if they were equal. The bug was introduced in version 1.76. perl -MMath::BigFloat -wle ' $x = Math::BigFloat -> new("1e1234567890987654321"); $y = Math::BigFloat -> new("1e1234567890987654300"); print $x -> bcmp($y)' The bug is caused by a short-cut in bcmp() where the exponent is converted to a Perl scalar (with the _num() library function). This causes a loss of precision. It seems that this is done deliberately, since a comment in the code says "the numify somewhat limits our length, but makes it much faster". I vote for following the good rules in the "GOALS" file in the distribution, one of which says "Favour correctness over speed".
From jaleto [...] gmail.com Sat Nov 6 13: 59:59 2010
MIME-Version: 1.0
X-Spam-Status: No, score=-6.223 tagged_above=-99.9 required=10 tests=[AWL=-0.113, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, T_TO_NO_BRKTS_FREEMAIL=0.01] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-2358-1289034911-1645.62764-4-0 [...] rt.cpan.org>
X-Spam-Flag: NO
References: <RT-Ticket-62764 [...] rt.cpan.org> <rt-3.8.HEAD-2358-1289034911-1645.62764-4-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <AANLkTikxCU4pfGvktKV=KnicxZ3OpXDYYC+b--7KWoud [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.223
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.sender=jaleto [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id D7278240E93 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Sat, 6 Nov 2010 13:59:59 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+UfneNXBrrP for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Sat, 6 Nov 2010 13:59:58 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id D85C8240DB5 for <bug-Math-BigInt [...] rt.cpan.org>; Sat, 6 Nov 2010 13:59:57 -0400 (EDT)
Received: (qmail 7092 invoked by uid 103); 6 Nov 2010 18:00:07 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 6 Nov 2010 18:00:07 -0000
Received: from mail-qy0-f178.google.com (HELO mail-qy0-f178.google.com) (209.85.216.178) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Sat, 06 Nov 2010 11:00:05 -0700
Received: by qyk31 with SMTP id 31so619707qyk.9 for <bug-Math-BigInt [...] rt.cpan.org>; Sat, 06 Nov 2010 11:00:02 -0700 (PDT)
Received: by 10.224.46.5 with SMTP id h5mr2426183qaf.27.1289066402332; Sat, 06 Nov 2010 11:00:02 -0700 (PDT)
Received: by 10.220.191.201 with HTTP; Sat, 6 Nov 2010 10:59:47 -0700 (PDT)
Delivered-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #62764] bcmp() fails for very large numbers
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=EpC9f3r69L734P/4hKwMfBM1Fva836Gm2D+YxpcUkGq5qjwgz+XVgcsJCn9mUqZyEs i1h/dTWo5Qr8WgYA/C88l84HkGwZk3XrDnEpzdma9umfvnH6u3uXkxC4YIfitQBity+a s7Id7v9ySucAjXkeH03rFK1WE24wqejBRK4a0=
Return-Path: <jaleto [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=KAfeiB5NCphFN1I8/PW1IG7EpHm8bhkBWWdBGbVZLu0=; b=k64y1o7J2ydzRhc5OThkGOTC/e1+G9xdD9Op4E48SZWAnnuKSlOo4tHy1bVi0UV7FS 7bEYsPcsOjuDVKjfUYBOsGWvcmo4gdyXUauvWNv5+h5qx10SR/nvIOFwCtelmqw7Wa80 Ip1E2FfBsg0fKS3MjJp1eoPgGP7NOfzkLDHd4=
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-bigint
X-Google-Sender-Auth: H9XpFxLSSfj7b9tQAExw5mtwZUs
Sender: jaleto [...] gmail.com
Date: Sat, 6 Nov 2010 10:59:47 -0700
X-Spam-Level:
To: bug-Math-BigInt [...] rt.cpan.org
From: Jonathan Leto <jonathan [...] leto.net>
RT-Message-ID: <rt-3.8.HEAD-2357-1289066411-1299.62764-0-0 [...] rt.cpan.org>
Content-Length: 1174
Download (untitled) / with headers
text/plain 1.1k
Howdy, I am a big fan of "correctness over speed". Is their some heuristic by which we can decide whether to convert the exponent to a scalar? It would suck to slow down the 99% case of the exponent fitting in a Perl scalar. Also, did you fork the Math::BigFloat repo on github yet, so you can send pull requests? Duke Show quoted text
> bcmp() fails for very large numbers. In the case below, $x and $y are > different, yet bcmp() returns 1, as if they were equal. The bug was > introduced in version 1.76. > > perl -MMath::BigFloat -wle ' > $x = Math::BigFloat -> new("1e1234567890987654321"); > $y = Math::BigFloat -> new("1e1234567890987654300"); > print $x -> bcmp($y)' > > The bug is caused by a short-cut in bcmp() where the exponent is > converted to a Perl scalar (with the _num() library function). This > causes a loss of precision. > > It seems that this is done deliberately, since a comment in the code > says "the numify somewhat limits our length, but makes it much faster". > I vote for following the good rules in the "GOALS" file in the > distribution, one of which says "Favour correctness over speed". >
-- Jonathan "Duke" Leto jonathan@leto.net http://leto.net
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-2357-1289066411-1299.62764-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-62764 [...] rt.cpan.org> <rt-3.8.HEAD-2358-1289034911-1645.62764-4-0 [...] rt.cpan.org> <AANLkTikxCU4pfGvktKV=KnicxZ3OpXDYYC+b--7KWoud [...] mail.gmail.com> <rt-3.8.HEAD-2357-1289066411-1299.62764-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-2356-1289077176-690.62764-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
RT-Send-CC: jonathan [...] leto.net
Content-Length: 1093
On Sat Nov 06 14:00:11 2010, LETO wrote: Show quoted text
> Howdy,
Yo! :-) Show quoted text
> I am a big fan of "correctness over speed". Is their some > heuristic by which we can decide whether to convert the > exponent to a scalar? It would suck to slow down the 99% > case of the exponent fitting in a Perl scalar.
I haven't had time to really look into this yet, but I think it might be worth using _len() as a first comparison of the exponents. There is no need to compare the actual values of the exponents if they have different length. If the exponents have the same length, I'm not yet sure what to do. Perhaps use _str() and do a string comparison? Or use _acmp()? The worst thing is returning the wrong value silently, i.e., without a warning or error message. Show quoted text
> Also, did you fork the Math::BigFloat repo on github yet, so you can > send pull requests?
I have forked, cloned, branched, hacked, pushed, and sent 5 pull requests to Florian (rafl on github). They are my first pull requests, so I hope I did everything correctly. I am working on the bmodpow() and the blog() bugs, so more pull requests will come.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-2356-1289077176-690.62764-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-62764 [...] rt.cpan.org> <rt-3.8.HEAD-2358-1289034911-1645.62764-4-0 [...] rt.cpan.org> <AANLkTikxCU4pfGvktKV=KnicxZ3OpXDYYC+b--7KWoud [...] mail.gmail.com> <rt-3.8.HEAD-2357-1289066411-1299.62764-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-2356-1289077176-690.62764-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-19315-1293435506-1894.62764-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 78
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-19315-1293435506-1894.62764-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-62764 [...] rt.cpan.org> <rt-3.8.HEAD-2358-1289034911-1645.62764-4-0 [...] rt.cpan.org> <AANLkTikxCU4pfGvktKV=KnicxZ3OpXDYYC+b--7KWoud [...] mail.gmail.com> <rt-3.8.HEAD-2357-1289066411-1299.62764-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-2356-1289077176-690.62764-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-19315-1293435506-1894.62764-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-9644-1295548579-1243.62764-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 54
Status should be "patched" until a new release is out.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-7681-1296988922-1165.62764-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 644
Download (untitled) / with headers
text/plain 644b
The bug is indeed present, but the initial bug report is incorrect. In that report, bcmp() returns 1 because $x is larger than $y, which is correct. To see the bug, the exponents must be larger, although that depends on the support for 64 bit integers and long doubles. With "use64bitint" and "uselongdouble" disabled, the following perl -MMath::BigFloat -wle ' $x = Math::BigFloat -> new("1e123456789098765432101234"); $y = Math::BigFloat -> new("1e123456789098765432101233"); print $x -> bcmp($y)' prints 0, indicating that $x and $y are equal. The correct should be 1. Anyway, this is fixed in the Math-BigInt distribution version 1.991.


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.