Skip Menu |
 

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

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

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

Bug Information
Severity: Important
Broken in: 1.997
Fixed in: 1.999714



From calvin.schwenzfeier [...] gmail.com Tue Sep 7 13: 38:39 2010
MIME-Version: 1.0
X-Spam-Status: No, score=-9.912 tagged_above=-99.9 required=10 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SPF_NEUTRAL=0.686] autolearn=ham
X-Spam-Flag: NO
X-Virus-Checked: Checked by ClamAV on 16.mx.develooper.com
Content-Type: multipart/mixed; boundary=0016367d5bd892a663048faee7db
Message-ID: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Spam-Score: -9.912
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 3B715240C22 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Tue, 7 Sep 2010 13:38:39 -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 ErWw29+WpMzM for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Tue, 7 Sep 2010 13:38:37 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 4390F240BDA for <bug-Math-BigInt [...] rt.cpan.org>; Tue, 7 Sep 2010 13:38:36 -0400 (EDT)
Received: (qmail 17018 invoked by uid 103); 7 Sep 2010 17:41:23 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 7 Sep 2010 17:41:23 -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; Tue, 07 Sep 2010 10:41:22 -0700
Received: by qyk36 with SMTP id 36so5595121qyk.9 for <bug-Math-BigInt [...] rt.cpan.org>; Tue, 07 Sep 2010 10:41:19 -0700 (PDT)
Received: by 10.229.1.163 with SMTP id 35mr3646336qcf.299.1283881279071; Tue, 07 Sep 2010 10:41:19 -0700 (PDT)
Received: by 10.229.20.7 with HTTP; Tue, 7 Sep 2010 10:41:19 -0700 (PDT)
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Authentication-Results: hipster.bestpractical.com (amavisd-new); domainkeys=pass header.from=calvin.schwenzfeier [...] gmail.com
Delivered-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
Subject: Bug in Math::BigFloat ->batan() method.
Return-Path: <calvin.schwenzfeier [...] gmail.com>
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eGxzAPrQthXlVb6PnDurqux3EAN/y/eqcfZuNdZ8kPSNMisLI8zt4u6+uow+hXUU+B n0fVGjtGB7ncvsNxNENc9rXRVSesKUH8RMSkSeXOk5O/aKnhJ921fp3NjpNZMebDIvPz NlZfhaJimw2nt1uWSP833yh1ycGhESBvpeztA=
X-RT-Mail-Extension: math-bigint
X-Original-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
X-Spam-Check-BY: 16.mx.develooper.com
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=WzdvewqBNosY5QWonref71xNgN/YU70HqUJFDO9FAQo=; b=Jc126JGQsa3O/npAQhugtoj01j45ODUyZvhl8qdW1vnQPYvru8hc37sxSO4tp+4o6w K3n1QtHrQ63qJ2vuEHQqKkQS3TED0m8fzXEBMXtftXIAZ18YNYHlLeLAgKh/aYviyxjL O0P6JUglRN8bIXi0t13K6ZdvR8PRc9Qo4Zk18=
Date: Tue, 7 Sep 2010 11:41:19 -0600
X-Spam-Level:
To: bug-Math-BigInt [...] rt.cpan.org
From: Calvin Schwenzfeier <calvin.schwenzfeier [...] gmail.com>
Content-Length: 0
Content-Type: multipart/alternative; boundary=0016367d5bd892a65f048faee7d9
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 887
Download (untitled) / with headers
text/plain 887b
Greetings, Attached is a test file which tickles a bug in the Math::BigFloat ->batan() method. Specifically, the bug manifests when the value (*n*) you are trying to find the arc-tangent of is outside the range -1 ≤ *n* ≤ 1 , but only if the value (*n*) is not an integer (that is, finding the arc-tangent of 2 works; but 2.1 and 1.9 both go off in infinite loops). Looking at the source, it appears there is code to map numbers into the above range and then map them back after the arc-tangent series computation. My guess is one or both of the mapping operations are wrong (haven't taken the time to figure out which). ~Cal P.S.: The values used in the test file came from Wolfram|Alpha (i.e., http://www.wolframalpha.com/input/?i=atan%282.5%29), then rounded to approximately the correct precision. So if values are not exactly matching up, check the last few digits.
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 1023
Download (untitled) / with headers
text/html 1023b
X-Attachment-ID: f_gdt0xbrp0
content-type: application/x-troff; name="bigflt_atan.t"
content-disposition: attachment; filename="bigflt_atan.t"
Content-Transfer-Encoding: base64
Content-Length: 18014
Download bigflt_atan.t
text/x-perl 17.5k

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
In-Reply-To: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-20976-1341856647-1531.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 85
The test seems to stall at #157 on my Win32 laptop, so this might still be a problem.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-20976-1341856647-1531.61139-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com> <rt-3.8.HEAD-20976-1341856647-1531.61139-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-8056-1342715217-15.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 16835
Download (untitled) / with headers
text/plain 16.4k

Message body is not shown because it is too large.

MIME-Version: 1.0
In-Reply-To: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 364
Download (untitled) / with headers
text/plain 364b
This bug needs to be retitled --- it doesn't let me do so. If it can't be retitled, it needs to be refiled under a more descriptive name. Need title: "Infinite loop in atan function (Math::BigFloat->batan() method)" current title is too vague to describe what is going on or to get attention of a maintainer... Could be worse, might say 'bad thing happens'? ;-)
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com> <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-8056-1342715909-46.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 425
Download (untitled) / with headers
text/plain 425b
Sorta kills my ability to use my calc prog for this to get any result. Only workaround is to set do bigfloat in a separate process or maybe thread -- and set a timer. If it doesn't come back in 2-3 seconds, kill it and tell user CPAN module for Math is to buggy to come up with a reply in a reasonable amount of time, so calculation was terminated. Makes it a real pain to even try to do calculations with this lib...
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com> <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-22807-1342907822-1546.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 898
Download (untitled) / with headers
text/plain 898b
On Thu Jul 19 12:34:34 2012, LAWALSH wrote: Show quoted text
> > current title is too vague to describe what is going on or to get > attention of a maintainer...
I don't know about the other maintaners, but all bugs in this distribution have my attention. The main problem, as I see it, are all the fundamental design flaws in the distributions Math-BigInt, Math-BigRat, Math-BigFloat, and bignum. All basic OO design rules have been thrown overboard for the sake of speed. The distributions are woven together in a terrible mess. Fix one thing, and something else breaks somewhere unexpected. This mess makes it very difficult to fix things properly. Before I start fixing the bugs in this distribution, I want to redesign the internals of the four mentioned distributions to ordinary OO-style programming, so that bugs can be fixed more easily. This is a work in progress that I have not finished yet.
MIME-Version: 1.0
Subject: Math::BigFloat ->batan() infinite loop and accuracy
In-Reply-To: <rt-3.8.HEAD-8056-1342715909-46.61139-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com> <rt-3.8.HEAD-5091-1342715674-1412.61139-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-8056-1342715909-46.61139-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.16-19333-1382570511-1106.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1140
Download (untitled) / with headers
text/plain 1.1k
See a fix for the infinite loop issue in: https://rt.cpan.org/Ticket/Display.html?id=88293#txn-1278395 though it does not fix the accuracy issues here or in 84953. Also, a simple idea from Brent 2006 gives a big speedup (about 30x with Calc, about 100x with GMP). right after the 1/x loop and before the 'no strict 'refs'': my $fmul = 8; $x->bdiv($x->copy->bmul($x)->binc->bsqrt($scale+4)->binc, $scale+4); $x->bdiv($x->copy->bmul($x)->binc->bsqrt($scale+4)->binc, $scale+4); $x->bdiv($x->copy->bmul($x)->binc->bsqrt($scale+4)->binc, $scale+4); then immediately after the 'while (3 < 5)' loop: $x->bmul($fmul); For a more dynamic solution, replace the first part with: my $fmul = 1; foreach my $k (0 .. int($scale/20)) { $fmul *= 2; $x->bdiv($x->copy->bmul($x)->binc->bsqrt($scale+4)->binc,$scale+4); } which gives even more speedup on the example test (with the GMP backend it completes in under 2.5s, with Calc in about 10s, vs. 10 minutes+ without the speedup). I've found the exp reduction works quite well also ( exp(x) = (exp(x/2)^2 ), where we can just accumulate the final exponent as a bigint.
MIME-Version: 1.0
In-Reply-To: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16225-1383252244-806.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1059
The bigflt_atan.t file included in the original report now works for me with these changes. (1) The values -2.5 to -1.6 and 1.6 to 2.5 have an extra digit so need to be rounded to match the desired accuracy. The value for -1.9 and 1.9 should end with "...1942" rather than ...1943. Use PARI/GP, set \p to 200 or so, call atan and check results when in doubt. (2) In the PI/2 calculation, use "$scale - 2" instead of "$scale - 3". This will fix the incorrect last digit in -1.1 and 1.1, while still passing the full test suite. (3) This part is entirely optional and is really another issue. To finish in a reasonable time, I used this performance change right after the PI/2 and before no strict refs: my $fmul = 1; my $escale = int($scale/20); foreach my $k (1 .. $escale) { $fmul *= 2; $x->bdiv($x->copy->bmul($x)->binc->bsqrt($scale+$escale+2)->binc,$scale+$escale+2); } then after the while (3 < 5) loop: $x->bmul($fmul) if $fmul > 1; This makes the whole test suite (including bigflt_atan.t) reduce from 690s to 17s for me.
MIME-Version: 1.0
In-Reply-To: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <AANLkTim-B_scLNUL46KPfsbBkB1033rZrP55Gd6okfzB [...] mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-3504-1451994476-1608.61139-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 236
Download (untitled) / with headers
text/plain 236b
Fixed in Math-BigInt v1.999714. Thanks to DANAJ (Dana Jacobsen) for the fix and for the suggestions for speeding up the code. The batan2() method was almost completely rewritten. If it returned a result, the result was often incorrect.


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.