From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: SasQ Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 16:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 22567@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.145469005731215 (code B ref -1); Fri, 05 Feb 2016 16:35:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Feb 2016 16:34:17 +0000 Received: from localhost ([127.0.0.1]:34579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRjKq-00087P-J7 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 11:34:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48493) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRbEQ-0002W1-Ku for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRbEK-0004ze-K5 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEK-0004za-Gg for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEJ-0006bx-Nn for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:55:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRbEF-0004zC-Mr for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:54:59 -0500 Received: from mx1.tlen.pl ([193.222.135.140]:51674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEF-0004z1-Fu for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:54:55 -0500 Received: (wp-smtpd smtp.tlen.pl 29798 invoked from network); 5 Feb 2016 08:54:50 +0100 Received: from unknown (HELO [10.0.0.71]) (sasq1@o2.pl@[83.30.76.23]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with SMTP for ; 5 Feb 2016 08:54:50 +0100 Message-ID: <56B453A3.7050002@go2.pl> Date: Fri, 05 Feb 2016 08:47:47 +0100 From: SasQ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-WP-MailID: bdee27a0af224c958b38a121fbd746d8 X-WP-AV: skaner antywirusowy poczty Nowej Poczty X-WP-SPAM: NO 0000000 [0TM3] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Mailman-Approved-At: Fri, 05 Feb 2016 11:34:15 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) Hello. Looks like I found a bug in the `factor` command (version 8.21 on Gentoo Linux). For the following input: factor 99999999999999999999999999999999999999 it hangs, but for a longer number: factor 100000000000000000000000000000000000000 it works fine, factoring it as 38 "2"s and 38 "5"s. It also works fine for a number one less: factor 99999999999999999999999999999999999998 factoring it as: 2 7 277294097 25759138835390148450014993081 and it also works for the biggest 64-bit prime: factor 18446744073709551557 just returning itself. So the only problematic input is the string of 38 "9"s. P.S.: I'm curious though: How does it work that it is able to factor such big numbers in such a short time without large prime tables? -- SasQ From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 05 12:55:25 2016 Received: (at control) by debbugs.gnu.org; 5 Feb 2016 17:55:25 +0000 Received: from localhost ([127.0.0.1]:34647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkbN-0004qw-5L for submit@debbugs.gnu.org; Fri, 05 Feb 2016 12:55:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45400) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkbK-0004qa-Bn; Fri, 05 Feb 2016 12:55:23 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9967170D99; Fri, 5 Feb 2016 17:55:16 +0000 (UTC) Received: from [10.3.113.164] (ovpn-113-164.phx2.redhat.com [10.3.113.164]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u15HtFAj020868; Fri, 5 Feb 2016 12:55:16 -0500 Subject: Re: bug#22567: Factoring 38 nines To: SasQ , 22567-done@debbugs.gnu.org References: <56B453A3.7050002@go2.pl> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <56B4E203.8090708@redhat.com> Date: Fri, 5 Feb 2016 10:55:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B453A3.7050002@go2.pl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tag 22567 notabug thanks On 02/05/2016 12:47 AM, SasQ wrote: > Hello. > Looks like I found a bug in the `factor` command > (version 8.21 on Gentoo Linux). For the following input: > factor 99999999999999999999999999999999999999 > it hangs, but for a longer number: > factor 100000000000000000000000000000000000000 > it works fine, factoring it as 38 "2"s and 38 "5"s. > It also works fine for a number one less: > factor 99999999999999999999999999999999999998 > factoring it as: > 2 7 277294097 25759138835390148450014993081 > and it also works for the biggest 64-bit prime: > factor 18446744073709551557 > just returning itself. > So the only problematic input is the string of 38 "9"s. The program is not hanging, just spending a LONG time. Some numbers are inherently easier to factor than others, when using currently-known non-quantum algorithms. On my machine: $ time factor 99999999999999999999999999999999999999 99999999999999999999999999999999999999: 3 3 11 909090909090909091 1111111111111111111 real 0m45.630s user 0m45.684s sys 0m0.000s $ time factor 18446744073709551557 18446744073709551557: 18446744073709551557 real 0m0.001s user 0m0.000s sys 0m0.001s >=20 > P.S.: I'm curious though: How does it work that it is able to factor > such big numbers in such a short time without large prime tables?= The source code is there for you to peruse. The answer depends on part whether you built coreutils with gmp support (in which case, we defer the heavy lifting on to the numeric library writers), or if you are stuck with an implementation that may not be as fast. Lots of mathematical theory can be consulted on how to make factorization faster on certain numbers (and in fact, such work is directly competing with the use of large primes as the basis of cryptography), such as Miller-Rabin probability filtering. But for any given number, there's no obvious formula for determining if it will be easy or hard. (Of course, someday we may be find ourselves using quantum computers, where the rules of factoring are completely different, but that's a completely different topic). At any rate, although I'm marking this as not a bug, you may feel free to add further comments to the thread. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWtOIDAAoJEKeha0olJ0NqDLwH/RiSuL6+s87XjGMxdQO5R0/h uz2t9BUqs9Bpv6u/EepD8TtxtDH9z1MSXbVu24ZQ3YF+QxAvwq2EY4Hg18+T5uZo 6m6kk9/hnuyGvuRLRCPk913Ue5NBwfv13Gj2co+WUqwHTmHw99poJoSLt2zpTvTP RR54M3QU2qkYx2fnV7E+0YJVCkK0EBYmX3kZzI+XKPhCd1hKgrEjGUya4eCj3fO7 rReT1lL+pZScpZpJ1aPAsoPO9cJfNY0ENaRBnKmVQmg8GwL9J3WySXA2t8O+eJpX QWl2fL/vgwjB1Xn6zC4m2ZJMVqKlQp656ipVbyUQDYS+TwIvYLeEaXK5p1cCIbw= =3lcJ -----END PGP SIGNATURE----- --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE-- From unknown Sun Aug 17 22:10:07 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: SasQ Subject: bug#22567: closed (Re: bug#22567: Factoring 38 nines) Message-ID: References: <56B4E203.8090708@redhat.com> <56B453A3.7050002@go2.pl> X-Gnu-PR-Message: they-closed 22567 X-Gnu-PR-Package: coreutils X-Gnu-PR-Keywords: notabug Reply-To: 22567@debbugs.gnu.org Date: Fri, 05 Feb 2016 17:56:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1454694963-18719-1" This is a multi-part message in MIME format... ------------=_1454694963-18719-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #22567: Factoring 38 nines which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 22567@debbugs.gnu.org. --=20 22567: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D22567 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1454694963-18719-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 17:55:25 +0000 Received: from localhost ([127.0.0.1]:34645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkbM-0004qu-R8 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 12:55:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45400) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkbK-0004qa-Bn; Fri, 05 Feb 2016 12:55:23 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9967170D99; Fri, 5 Feb 2016 17:55:16 +0000 (UTC) Received: from [10.3.113.164] (ovpn-113-164.phx2.redhat.com [10.3.113.164]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u15HtFAj020868; Fri, 5 Feb 2016 12:55:16 -0500 Subject: Re: bug#22567: Factoring 38 nines To: SasQ , 22567-done@debbugs.gnu.org References: <56B453A3.7050002@go2.pl> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <56B4E203.8090708@redhat.com> Date: Fri, 5 Feb 2016 10:55:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B453A3.7050002@go2.pl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 22567-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tag 22567 notabug thanks On 02/05/2016 12:47 AM, SasQ wrote: > Hello. > Looks like I found a bug in the `factor` command > (version 8.21 on Gentoo Linux). For the following input: > factor 99999999999999999999999999999999999999 > it hangs, but for a longer number: > factor 100000000000000000000000000000000000000 > it works fine, factoring it as 38 "2"s and 38 "5"s. > It also works fine for a number one less: > factor 99999999999999999999999999999999999998 > factoring it as: > 2 7 277294097 25759138835390148450014993081 > and it also works for the biggest 64-bit prime: > factor 18446744073709551557 > just returning itself. > So the only problematic input is the string of 38 "9"s. The program is not hanging, just spending a LONG time. Some numbers are inherently easier to factor than others, when using currently-known non-quantum algorithms. On my machine: $ time factor 99999999999999999999999999999999999999 99999999999999999999999999999999999999: 3 3 11 909090909090909091 1111111111111111111 real 0m45.630s user 0m45.684s sys 0m0.000s $ time factor 18446744073709551557 18446744073709551557: 18446744073709551557 real 0m0.001s user 0m0.000s sys 0m0.001s >=20 > P.S.: I'm curious though: How does it work that it is able to factor > such big numbers in such a short time without large prime tables?= The source code is there for you to peruse. The answer depends on part whether you built coreutils with gmp support (in which case, we defer the heavy lifting on to the numeric library writers), or if you are stuck with an implementation that may not be as fast. Lots of mathematical theory can be consulted on how to make factorization faster on certain numbers (and in fact, such work is directly competing with the use of large primes as the basis of cryptography), such as Miller-Rabin probability filtering. But for any given number, there's no obvious formula for determining if it will be easy or hard. (Of course, someday we may be find ourselves using quantum computers, where the rules of factoring are completely different, but that's a completely different topic). At any rate, although I'm marking this as not a bug, you may feel free to add further comments to the thread. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWtOIDAAoJEKeha0olJ0NqDLwH/RiSuL6+s87XjGMxdQO5R0/h uz2t9BUqs9Bpv6u/EepD8TtxtDH9z1MSXbVu24ZQ3YF+QxAvwq2EY4Hg18+T5uZo 6m6kk9/hnuyGvuRLRCPk913Ue5NBwfv13Gj2co+WUqwHTmHw99poJoSLt2zpTvTP RR54M3QU2qkYx2fnV7E+0YJVCkK0EBYmX3kZzI+XKPhCd1hKgrEjGUya4eCj3fO7 rReT1lL+pZScpZpJ1aPAsoPO9cJfNY0ENaRBnKmVQmg8GwL9J3WySXA2t8O+eJpX QWl2fL/vgwjB1Xn6zC4m2ZJMVqKlQp656ipVbyUQDYS+TwIvYLeEaXK5p1cCIbw= =3lcJ -----END PGP SIGNATURE----- --PXh5hu6gj9615D9NWBEfRuDidL6oDjwcE-- ------------=_1454694963-18719-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Feb 2016 16:34:17 +0000 Received: from localhost ([127.0.0.1]:34579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRjKq-00087P-J7 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 11:34:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48493) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRbEQ-0002W1-Ku for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRbEK-0004ze-K5 for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:48655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEK-0004za-Gg for submit@debbugs.gnu.org; Fri, 05 Feb 2016 02:55:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEJ-0006bx-Nn for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:55:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRbEF-0004zC-Mr for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:54:59 -0500 Received: from mx1.tlen.pl ([193.222.135.140]:51674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRbEF-0004z1-Fu for bug-coreutils@gnu.org; Fri, 05 Feb 2016 02:54:55 -0500 Received: (wp-smtpd smtp.tlen.pl 29798 invoked from network); 5 Feb 2016 08:54:50 +0100 Received: from unknown (HELO [10.0.0.71]) (sasq1@o2.pl@[83.30.76.23]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with SMTP for ; 5 Feb 2016 08:54:50 +0100 Message-ID: <56B453A3.7050002@go2.pl> Date: Fri, 05 Feb 2016 08:47:47 +0100 From: SasQ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: Factoring 38 nines X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-WP-MailID: bdee27a0af224c958b38a121fbd746d8 X-WP-AV: skaner antywirusowy poczty Nowej Poczty X-WP-SPAM: NO 0000000 [0TM3] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 05 Feb 2016 11:34:15 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) Hello. Looks like I found a bug in the `factor` command (version 8.21 on Gentoo Linux). For the following input: factor 99999999999999999999999999999999999999 it hangs, but for a longer number: factor 100000000000000000000000000000000000000 it works fine, factoring it as 38 "2"s and 38 "5"s. It also works fine for a number one less: factor 99999999999999999999999999999999999998 factoring it as: 2 7 277294097 25759138835390148450014993081 and it also works for the biggest 64-bit prime: factor 18446744073709551557 just returning itself. So the only problematic input is the string of 38 "9"s. P.S.: I'm curious though: How does it work that it is able to factor such big numbers in such a short time without large prime tables? -- SasQ ------------=_1454694963-18719-1-- From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 18:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: SasQ , 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145469552125820 (code D ref 22567); Fri, 05 Feb 2016 18:06:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 18:05:21 +0000 Received: from localhost ([127.0.0.1]:34660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkkz-0006iO-Dx for submit@debbugs.gnu.org; Fri, 05 Feb 2016 13:05:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56299) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRkkx-0006iB-Q2 for 22567-done@debbugs.gnu.org; Fri, 05 Feb 2016 13:05:20 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 98AA6C0B2ED9; Fri, 5 Feb 2016 18:05:13 +0000 (UTC) Received: from [10.3.113.164] (ovpn-113-164.phx2.redhat.com [10.3.113.164]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u15I5Cjn025450; Fri, 5 Feb 2016 13:05:13 -0500 References: <56B453A3.7050002@go2.pl> <56B4E203.8090708@redhat.com> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <56B4E458.20302@redhat.com> Date: Fri, 5 Feb 2016 11:05:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B4E203.8090708@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qnPBJE1bCPO5VoGxNCKA3UCI0jwj1H2PA" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -5.4 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qnPBJE1bCPO5VoGxNCKA3UCI0jwj1H2PA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/05/2016 10:55 AM, Eric Blake wrote: A bit more commentary: >> Looks like I found a bug in the `factor` command >> (version 8.21 on Gentoo Linux). For the following input: >> factor 99999999999999999999999999999999999999 >> it hangs, but for a longer number: >> factor 100000000000000000000000000000000000000 >> it works fine, factoring it as 38 "2"s and 38 "5"s. This one is VERY easy to factor. Since the largest factor is 5, very little effort is expended, even by a grade-school algorithm. >> It also works fine for a number one less: >> factor 99999999999999999999999999999999999998 >> factoring it as: >> 2 7 277294097 25759138835390148450014993081 This one is a bit harder, but the fact that 277294097 is (relatively) small means that the first three factors can be found quickly; meanwhile 277294097 is large enough that you have knocked off several bits from the remaining value, and even with naive algorithms, every bit knocked off cuts the search time in half for deciding if the remaining value is prime. >> and it also works for the biggest 64-bit prime: >> factor 18446744073709551557 >> just returning itself. Again, the magic here is that this is one of the primes that quickly falls to algorithm tests. If we used ONLY a naive algorithm, it could potentially take much longer; but you'll still notice that this value is much smaller than 25759138835390148450014993081 so it still takes less search time in a naive algorithm than what you would spend factoring 99999999999999999999999999999999999998. >> So the only problematic input is the string of 38 "9"s. >=20 > The program is not hanging, just spending a LONG time. Some numbers ar= e > inherently easier to factor than others, when using currently-known > non-quantum algorithms. >=20 > On my machine: > $ time factor 99999999999999999999999999999999999999 > 99999999999999999999999999999999999999: 3 3 11 909090909090909091 > 1111111111111111111 Here, the two primes are fairly close in length, and both much larger in magnitude than the earlier examples. This means that it takes longer to even find 909090909090909091 as a factor and prove that it is a prime, and then the algorithm has to spend another length of time proving that 1111111111111111111 is prime. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --qnPBJE1bCPO5VoGxNCKA3UCI0jwj1H2PA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWtORYAAoJEKeha0olJ0Nqjc0H/2ARvRxEUIr08KzZTQwleufd wc6BM0lnSBfFAu0lahSaI0rLdK6GyIAWIhZ4hhjf4BlqxbJ9HWEbhgOHZRXVHdZE 9eDa8w1TCpmOCu8V1lfYZtzakmNgXCzSCmPxIIudexsdz0Wn7g71v/5VkEeHG5on XpI8ycfmo4QKxJ9DqixLxeBG3jYU0L5fwQtwvVM2TMbGYy24e4Q2V8oxpsCm4WIg vI/qdcOIYCjJyX/FKMkBwf5jOD0UXd7YHpqYucW7/ZkThnIut6RoukyLqJMr1qlg QlIVd9CH0oDzBMOkygVb6LrM9t3JhvqPmd9x0mwWMrgEimzDsis66FBA6LXhEnU= =NETF -----END PGP SIGNATURE----- --qnPBJE1bCPO5VoGxNCKA3UCI0jwj1H2PA-- From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: SasQ Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 19:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Eric Blake , 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145469920931312 (code D ref 22567); Fri, 05 Feb 2016 19:07:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 19:06:49 +0000 Received: from localhost ([127.0.0.1]:34691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRliT-00088y-8f for submit@debbugs.gnu.org; Fri, 05 Feb 2016 14:06:49 -0500 Received: from mx4.tlen.pl ([193.222.135.148]:42231 helo=smtp.tlen.pl) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRlG4-0007S0-QP for 22567-done@debbugs.gnu.org; Fri, 05 Feb 2016 13:37:29 -0500 Received: (wp-smtpd smtp.tlen.pl 31132 invoked from network); 5 Feb 2016 19:37:26 +0100 Received: from unknown (HELO [10.0.0.71]) (sasq1@o2.pl@[83.30.12.177]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with SMTP for ; 5 Feb 2016 19:37:26 +0100 Message-ID: <56B4EA3D.9060703@go2.pl> Date: Fri, 05 Feb 2016 19:30:21 +0100 From: SasQ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <56B453A3.7050002@go2.pl> <56B4E203.8090708@redhat.com> In-Reply-To: <56B4E203.8090708@redhat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-WP-MailID: c202d52bcdd6fa0cc55a43744101f946 X-WP-AV: skaner antywirusowy poczty Nowej Poczty X-WP-SPAM: NO 0000000 [cROU] X-Spam-Score: 1.8 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 2016.02.05 @ 18:55, Eric Blake wrote: > The program is not hanging, just spending a LONG time. Some numbers > are inherently easier to factor than others, when using > currently-known non-quantum algorithms. > > On my machine: $ time factor > 99999999999999999999999999999999999999 > 99999999999999999999999999999999999999: 3 3 11 909090909090909091 > 1111111111111111111 > > real 0m45.630s user 0m45.684s sys 0m0.000s [...] Content analysis details: (1.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3) [193.222.135.148 listed in bl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted X-Mailman-Approved-At: Fri, 05 Feb 2016 14:06:48 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.8 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 2016.02.05 @ 18:55, Eric Blake wrote: > The program is not hanging, just spending a LONG time. Some numbers > are inherently easier to factor than others, when using > currently-known non-quantum algorithms. > > On my machine: $ time factor > 99999999999999999999999999999999999999 > 99999999999999999999999999999999999999: 3 3 11 909090909090909091 > 1111111111111111111 > > real 0m45.630s user 0m45.684s sys 0m0.000s [...] Content analysis details: (1.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.8 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3) [193.222.135.148 listed in bl.mailspike.net] 0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted 2016.02.05 @ 18:55, Eric Blake wrote: > The program is not hanging, just spending a LONG time. Some numbers > are inherently easier to factor than others, when using > currently-known non-quantum algorithms. > > On my machine: $ time factor > 99999999999999999999999999999999999999 > 99999999999999999999999999999999999999: 3 3 11 909090909090909091 > 1111111111111111111 > > real 0m45.630s user 0m45.684s sys 0m0.000s OK, this convinces me this is not a bug. 4m30 on my machine. But it's definitely a user-interface fail ;) It should at least output some warning that the computations might take longer, or display some progress status / estimated time along the way. Because otherwise the user can think it simply hangs. > The source code is there for you to peruse. There sure is, but analyzing it just to figure out the algorithm takes much more time than refering the maual to see which particular factorization algorithm or its variation is in use. It took me a while to find the answer on StackOverflow: http://stackoverflow.com/questions/11155331/what-is-the-algorithm-behind-the-factor-command-in-linux so mentioning it in the man page wouldn't hurt. Anyway, thanks for your detailed explanations. -- SasQ From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 19:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: SasQ , 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.1454700603973 (code D ref 22567); Fri, 05 Feb 2016 19:31:02 +0000 Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 19:30:03 +0000 Received: from localhost ([127.0.0.1]:34723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRm4x-0000Fc-3x for submit@debbugs.gnu.org; Fri, 05 Feb 2016 14:30:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57884) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRm4v-0000Em-6J for 22567-done@debbugs.gnu.org; Fri, 05 Feb 2016 14:30:02 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6A98519CB92; Fri, 5 Feb 2016 19:30:00 +0000 (UTC) Received: from [10.3.113.164] (ovpn-113-164.phx2.redhat.com [10.3.113.164]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u15JU0BB009576; Fri, 5 Feb 2016 14:30:00 -0500 References: <56B453A3.7050002@go2.pl> <56B4E203.8090708@redhat.com> <56B4EA3D.9060703@go2.pl> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <56B4F837.6050405@redhat.com> Date: Fri, 5 Feb 2016 12:29:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B4EA3D.9060703@go2.pl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TrHg43iw8XLdu5wxu7cswEunfD0CFJAnu" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -5.4 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TrHg43iw8XLdu5wxu7cswEunfD0CFJAnu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/05/2016 11:30 AM, SasQ wrote: >=20 > OK, this convinces me this is not a bug. 4m30 on my machine. > But it's definitely a user-interface fail ;) > It should at least output some warning that the computations might > take longer, or display some progress status / estimated time along > the way. Estimated status is very hard to produce. I guess with trial division, you could output a progress indicator comparing what number you are trying in relation to the square root of the number being factored, as a rough estimate; but there's still the annoying problem that any estimate bar will not progress smoothly (once a factor is found, the time remaining changes). Progress indications should not be issued by default, unfortunately, because it might break expectations of applications that have grown used to no progress, so you'd have to make it a new command line option - but then, how will people know to use the new option? > Because otherwise the user can think it simply hangs. If a user is naive enough to think it is hanging on large input, how can we expect them to also be aware that they can turn on an option to track progress? And how will we explain that the progress meter may have no bearing on the real amount of time required? >=20 >> The source code is there for you to peruse. >=20 > There sure is, but analyzing it just to figure out the algorithm takes > much more time than refering the maual to see which particular > factorization algorithm or its variation is in use. >=20 > It took me a while to find the answer on StackOverflow: > http://stackoverflow.com/questions/11155331/what-is-the-algorithm-behin= d-the-factor-command-in-linux > so mentioning it in the man page wouldn't hurt. Well, it IS mentioned in the documentation (the info page, as the preferred documentation for a GNU project); and the point of the man page is to be a terse summary, not the full documentation. But maybe you have a valid point that adding a one-line blurb mentioning the Pollar Rho algorithm in 'factor --help' (which in turn feeds the man page) might be a useful change. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --TrHg43iw8XLdu5wxu7cswEunfD0CFJAnu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWtPg3AAoJEKeha0olJ0NquWkH/R1cztE4Tth0h1Csz5USIjch /3d+VxAYkAytxH3oSs4LPp8rEIdfTPS/4+/ymDKEyM7kpS11Hq/OhG2DaoBMFjpu PdsIdblbe/pu8Zl6gzFDHSJ0Empd3JVP34fKIKCjiSN1JFY4A8JMKX9sFlXwq9rW 4CDapxx1FjZztWlja0DrjIhLnmMqRe0LVAQr+OBj8lYLfL4cgGXRLQbEYQ7dYjWf SOnD1qyZ3MGxWJailB+x3pRAgwx+MGYkz+j0BBzXLc5Qz54JrX89Ae0niYbSifO3 OaKjtytLCoS0iYvb+8F84y9hm+2UASJDj3Nf1klG41kgDGyUj1hazMVVgzpypSg= =qSa9 -----END PGP SIGNATURE----- --TrHg43iw8XLdu5wxu7cswEunfD0CFJAnu-- From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Jim Meyering Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 20:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Eric Blake Cc: SasQ , 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145470455014538 (code D ref 22567); Fri, 05 Feb 2016 20:36:02 +0000 Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 20:35:50 +0000 Received: from localhost ([127.0.0.1]:34782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRn6b-0003mQ-KV for submit@debbugs.gnu.org; Fri, 05 Feb 2016 15:35:49 -0500 Received: from mail-oi0-f53.google.com ([209.85.218.53]:34068) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRn6a-0003mE-7w for 22567-done@debbugs.gnu.org; Fri, 05 Feb 2016 15:35:48 -0500 Received: by mail-oi0-f53.google.com with SMTP id w5so48373839oie.1 for <22567-done@debbugs.gnu.org>; Fri, 05 Feb 2016 12:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QUx4z8pYOB5lRXZnErgWA4KtVjTE7mhe3FNZj6YZawc=; b=mltvl8oCPa6vfYJHbnCdOKealg5KvAWOjSCiDRN2o4pPVY0W02lltM4r0HhB2i4kJa M/ZAbiEdQjDcBeihV9ekEmkY/8aKrB+SVoJPBmAT5+FtQuE1vKAuj8qedgaa/gca0cPB Ye3g8TLMRXy/M12ZOjHjo/oQr93q0s75UbYKzfRWU/MiwEhAHJWDaewpld/Ei/blh1MW nNrXyLw72n6BwO5mae6aKWIhgp/FUHqIUfjamvoO9gsxtC7F5ELA4xgJrPgGEFnFvmC8 xMXDYGpvOuyvvXmqs6wpgUSj7INeGIjG8mSznimOt88fAWXJXtFz0vUIKWO6SrnsogSH mptQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=QUx4z8pYOB5lRXZnErgWA4KtVjTE7mhe3FNZj6YZawc=; b=IGikufMkNM2dpvUTUhOZcdjXBz346nHEKkmJjoDEPNn9Uoj5hQnrBg7FM3iVs+fNam fgaJ7LfnuDbrR8nm1LyKJs0ee3nGsa8bxzfFSUsBTzwRp6dc8GoCJJhgALzfuGVyW984 LiFtYb4Axi5KJLcyt7X9CdQr7oi33WXbWm8AIMbJ045z8t2dBuHStXsjqHyfg+pceVq5 yMmLQWReAgrMR1Lx5QJhCoSjau18PtTRqxZla44hMOCkzYzL8fV9O5FH+D30EEIEl3tY QABj8piXSENtiYkqRuJU9ZoJV7P7P2lanzn32NQwakKiqyO4vfjYP2ZTyjGp2E8l1GoN c9fA== X-Gm-Message-State: AG10YOSXr7vKVWpOoSR+2JbQisF288lf+/kDeWn25mrosBH+ufnHXqGU97AwaHIYvDSoaJeNGEh0DTxNe95nVg== X-Received: by 10.202.191.7 with SMTP id p7mr9974742oif.64.1454704542661; Fri, 05 Feb 2016 12:35:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.64.134 with HTTP; Fri, 5 Feb 2016 12:35:22 -0800 (PST) In-Reply-To: <56B4F837.6050405@redhat.com> References: <56B453A3.7050002@go2.pl> <56B4E203.8090708@redhat.com> <56B4EA3D.9060703@go2.pl> <56B4F837.6050405@redhat.com> From: Jim Meyering Date: Fri, 5 Feb 2016 12:35:22 -0800 X-Google-Sender-Auth: 7TICNXUpVICRwo_Qgo8nCwoQuMw Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Fri, Feb 5, 2016 at 11:29 AM, Eric Blake wrote: > On 02/05/2016 11:30 AM, SasQ wrote: > >> >> OK, this convinces me this is not a bug. 4m30 on my machine. >> But it's definitely a user-interface fail ;) >> It should at least output some warning that the computations might >> take longer, or display some progress status / estimated time along >> the way. > > Estimated status is very hard to produce. I guess with trial division, > you could output a progress indicator comparing what number you are > trying in relation to the square root of the number being factored, as a > rough estimate; but there's still the annoying problem that any estimate > bar will not progress smoothly (once a factor is found, the time > remaining changes). Progress indications should not be issued by > default, unfortunately, because it might break expectations of > applications that have grown used to no progress, so you'd have to make > it a new command line option - but then, how will people know to use the > new option? > >> Because otherwise the user can think it simply hangs. > > If a user is naive enough to think it is hanging on large input, how can > we expect them to also be aware that they can turn on an option to track > progress? And how will we explain that the progress meter may have no > bearing on the real amount of time required? > >> >>> The source code is there for you to peruse. >> >> There sure is, but analyzing it just to figure out the algorithm takes >> much more time than refering the maual to see which particular >> factorization algorithm or its variation is in use. >> >> It took me a while to find the answer on StackOverflow: >> http://stackoverflow.com/questions/11155331/what-is-the-algorithm-behind-the-factor-command-in-linux >> so mentioning it in the man page wouldn't hurt. > > Well, it IS mentioned in the documentation (the info page, as the > preferred documentation for a GNU project); and the point of the man > page is to be a terse summary, not the full documentation. But maybe > you have a valid point that adding a one-line blurb mentioning the > Pollar Rho algorithm in 'factor --help' (which in turn feeds the man > page) might be a useful change. There is a deliberately hidden, three-hyphen ---debug option that does provide a minimal progress indicator (albeit still feels inadequate). This shows that it took GNU factor 15 minutes to factor the 46-digit product of two pretty large primes, M9 and M10: $ M9=$(echo 2^61-1|bc) M10=$(echo 2^89-1|bc) $ n=$(echo "$M9 * $M10" | bc) $ env time -f '%U' factor ---debug $n [using arbitrary-precision arithmetic] [trial division] [is number prime?] [pollard-rho (1)] [trial division] [is number prime?] [trial division] [is number prime?] [trial division] [is number prime?] 1427247692705959880439315947500961989719490561: 2305843009213693951 618970019642690137449562111 899.28 From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Leslie S Satenstein Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 05 Feb 2016 21:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Eric Blake , SasQ , "22567-done@debbugs.gnu.org" <22567-done@debbugs.gnu.org> Reply-To: Leslie S Satenstein Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145470717318269 (code D ref 22567); Fri, 05 Feb 2016 21:20:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 5 Feb 2016 21:19:33 +0000 Received: from localhost ([127.0.0.1]:34791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRnmr-0004kV-6d for submit@debbugs.gnu.org; Fri, 05 Feb 2016 16:19:33 -0500 Received: from nm36-vm2.bullet.mail.bf1.yahoo.com ([72.30.238.138]:55279) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRnmo-0004kH-Dr for 22567-done@debbugs.gnu.org; Fri, 05 Feb 2016 16:19:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1454707160; bh=TuDYQNfIB8sxC6sm8xZjy0KTV6DijIvGCE2lSI/G2uo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=iwtHSVR0Btabs5JqKzJvE0clCh7Hgg5nYCDeJYmBIkmFqJh2l5UfdTGXX//RxYteaV1XceoPpu/7Y5ByZmRbbJwwoMfV/IS/cDW4Y8AUrlmNqojfcCavxkJ/KNvDtJlwD7jpBjFEAsTr8xXx0SRVU320w5WWiWOkBWIAwAhlkZ6opsLFGEJq+8dmh8O9Icrf8Zih9e/9gI3tEp2fIWNOmNl5sWZlik33U+89RAGKvZoL94c7oRYJoxVtH+hwe08l3geW6rgGxKHj9dENxQCZ2DtJxPE+3IoAc1RIBlV9k/j52iXIL2JMx6INRYLQ2RFuL2GimWCbOGGdc3jlDLuCAg== Received: from [98.139.214.32] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2016 21:19:20 -0000 Received: from [98.139.215.230] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2016 21:19:20 -0000 Received: from [127.0.0.1] by omp1070.mail.bf1.yahoo.com with NNFMP; 05 Feb 2016 21:19:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 933585.88032.bm@omp1070.mail.bf1.yahoo.com X-YMail-OSG: XY_koXYVM1n2YDFZRLB2itsRxOUV3LgAdXr5UbecpJBOLHCR5rg1H5Agco2hBcH mgM3Q1pbcVYugY2p6Jxwi8yYUv1yQljpBhGEMbIld2hAmvwhNUwvtnE1I_OOQhafp7EW4sDnUnPK zJp1aOlaLilZZVAbFsKUnlZbrcGxFeJnmFeig0YRy2woonSAuDCk1DkDqYKprUzOQd6HYTxKAkrJ vszcrc0vyHNDknfyGh2VibbAb3glUAxqyIJ7tG5x0F5xXV8nt91gYAANp8lN_O3Q7IxGGcNRRK4C v5vjzk6nJ4fGB7VvwJv7t4R_GiJ6Mph.0p2vehgD2rgHHMIcIzeJwjdDNWUB6T_UtZ1SQFBrRXjl vycUTRG0VtLnoC4S.g6_wNBR2ONPmLRuhKrbfwLeA_lnoortbWbCMTQdTO5WrR6G9dBs6A.BN0EA JG4FB0HPuxBtX2dsekpbr0RqBSeAD8ADkbUG_E7bDKXhJb5NUfvkZeMilUvGm4EE9uRwVCzumPhZ 3fpAP_EG3rfw- Received: by 76.13.27.34; Fri, 05 Feb 2016 21:19:20 +0000 Date: Fri, 5 Feb 2016 21:19:19 +0000 (UTC) From: Leslie S Satenstein Message-ID: <821981855.746727.1454707159939.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <56B4F837.6050405@redhat.com> References: <56B4F837.6050405@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_746726_1516054584.1454707159933" Content-Length: 9445 X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) ------=_Part_746726_1516054584.1454707159933 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me, but it took a long time=C2=A0=20 =C2=A0Regards=20 =C2=A0Leslie Mr. Leslie Satenstein Montr=C3=A9al Qu=C3=A9bec, Canada =20 From: Eric Blake To: SasQ ; 22567-done@debbugs.gnu.org=20 Sent: Friday, February 5, 2016 2:29 PM Subject: bug#22567: Factoring 38 nines =20 On 02/05/2016 11:30 AM, SasQ wrote: >=20 > OK, this convinces me this is not a bug. 4m30 on my machine. > But it's definitely a user-interface fail ;) > It should at least output some warning that the computations might > take longer, or display some progress status / estimated time along > the way. Estimated status is very hard to produce. I guess with trial division, you could output a progress indicator comparing what number you are trying in relation to the square root of the number being factored, as a rough estimate; but there's still the annoying problem that any estimate bar will not progress smoothly (once a factor is found, the time remaining changes).=C2=A0 Progress indications should not be issued by default, unfortunately, because it might break expectations of applications that have grown used to no progress, so you'd have to make it a new command line option - but then, how will people know to use the new option? > Because otherwise the user can think it simply hangs. If a user is naive enough to think it is hanging on large input, how can we expect them to also be aware that they can turn on an option to track progress? And how will we explain that the progress meter may have no bearing on the real amount of time required? >=20 >> The source code is there for you to peruse. >=20 > There sure is, but analyzing it just to figure out the algorithm takes > much more time than refering the maual to see which particular > factorization algorithm or its variation is in use. >=20 > It took me a while to find the answer on StackOverflow: > http://stackoverflow.com/questions/11155331/what-is-the-algorithm-behind-= the-factor-command-in-linux > so mentioning it in the man page wouldn't hurt. Well, it IS mentioned in the documentation (the info page, as the preferred documentation for a GNU project); and the point of the man page is to be a terse summary, not the full documentation.=C2=A0 But maybe you have a valid point that adding a one-line blurb mentioning the Pollar Rho algorithm in 'factor --help' (which in turn feeds the man page) might be a useful change. --=20 Eric Blake=C2=A0 eblake redhat com=C2=A0 =C2=A0 +1-919-301-3266 Libvirt virtualization library http://libvirt.org =20 ------=_Part_746726_1516054584.1454707159933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Works for me, but it= took a long time 
 
<= div id=3D"yui_3_16_0_1_1454706957461_8270">
Regards

 Leslie
Mr. Leslie Satenstein
Montr=C3=A9al Qu=C3=A9bec, Canada



From: Eric Blake <eblake@redhat.com>
To: SasQ <sasq1@go2.pl>; 22567-done@debbugs.gnu= .org
Sent: Friday, Fe= bruary 5, 2016 2:29 PM
Subject: bug#22567: Factoring 38 nines

On 02/05/2016 11:= 30 AM, SasQ wrote:

>
> OK, this convinces me this is not a bug. 4m30 on my machine.
> But it's definitely a user-interface fail ;)
> It should at least output some warning that the computations mi= ght
> take longer, or display some progress status / e= stimated time along
> the way.

Estimated status is very hard to produce. I guess with trial = division,
you could output a progress indicator comparing= what number you are
trying in relation to the square roo= t of the number being factored, as a
rough estimate; but = there's still the annoying problem that any estimate
bar = will not progress smoothly (once a factor is found, the time
remaining changes).  Progress indications should not be issued by<= br clear=3D"none">default, unfortunately, because it might break expectatio= ns of
applications that have grown used to no progress, s= o you'd have to make
it a new command line option - but t= hen, how will people know to use the
new option?

> Because otherwise the user can think it s= imply hangs.

If a user is naive enough= to think it is hanging on large input, how can
we expect= them to also be aware that they can turn on an option to track
progress? And how will we explain that the progress meter may have n= o
bearing on the real amount of time required?


= >
>> The source code is there for you to peruse= .
>
> There sure is, but analyzi= ng it just to figure out the algorithm takes
> much mo= re time than refering the maual to see which particular
&= gt; factorization algorithm or its variation is in use.
&= gt;
> It took me a while to find the answer on StackO= verflow:
> http://s= tackoverflow.com/questions/11155331/what-is-the-algorithm-behind-the-factor= -command-in-linux
> so mentioning it in the man pa= ge wouldn't hurt.


Well, it IS me= ntioned in the documentation (the info page, as the
prefe= rred documentation for a GNU project); and the point of the man
page is to be a terse summary, not the full documentation.  But= maybe
you have a valid point that adding a one-line blur= b mentioning the
Pollar Rho algorithm in 'factor --help' = (which in turn feeds the man
page) might be a useful chan= ge.

--
Eric Blake&n= bsp; eblake redhat com    +1-919-301-3266
Libv= irt virtualization library http://libvirt.org



------=_Part_746726_1516054584.1454707159933-- From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Linda Walsh Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 08 Feb 2016 00:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: Jim Meyering Cc: SasQ , Eric Blake , 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145489106630576 (code D ref 22567); Mon, 08 Feb 2016 00:25:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 8 Feb 2016 00:24:26 +0000 Received: from localhost ([127.0.0.1]:37740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSZcw-0007x6-35 for submit@debbugs.gnu.org; Sun, 07 Feb 2016 19:24:26 -0500 Received: from ishtar.tlinx.org ([173.164.175.65]:54441 helo=Ishtar.sc.tlinx.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSZct-0007ww-KY for 22567-done@debbugs.gnu.org; Sun, 07 Feb 2016 19:24:24 -0500 Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id u180OG4I050323; Sun, 7 Feb 2016 16:24:19 -0800 Message-ID: <56B7E030.4060800@tlinx.org> Date: Sun, 07 Feb 2016 16:24:16 -0800 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 References: <56B453A3.7050002@go2.pl> <56B4E203.8090708@redhat.com> <56B4EA3D.9060703@go2.pl> <56B4F837.6050405@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) Jim Meyering wrote: > On Fri, Feb 5, 2016 at 11:29 AM, Eric Blake wrote: > >> On 02/05/2016 11:30 AM, SasQ wrote: >> >> >>> OK, this convinces me this is not a bug. 4m30 on my machine. >>> But it's definitely a user-interface fail ;) >>> It should at least output some warning that the computations might >>> take longer, or display some progress status / estimated time along >>> the way. >>> --- I thought factoring was something that was able to be made faster with parallel processing? I notice on linux and cygwin, only 1 cpu being used. If someone **really** wanted to speed things up, I think using video cards that support much larger parallelism, would likely be a big boost... but that would be even more likely to be a _little used feature_. From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines References: <56B453A3.7050002@go2.pl> Resent-From: f0rhum@free.fr Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 08 Feb 2016 09:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: 22567-done@debbugs.gnu.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.145492544311746 (code D ref 22567); Mon, 08 Feb 2016 09:58:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 8 Feb 2016 09:57:23 +0000 Received: from localhost ([127.0.0.1]:37992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSiZP-00033O-E4 for submit@debbugs.gnu.org; Mon, 08 Feb 2016 04:57:23 -0500 Received: from smtp6-g21.free.fr ([212.27.42.6]:30956) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSiZN-00033G-OZ for 22567-done@debbugs.gnu.org; Mon, 08 Feb 2016 04:57:22 -0500 Received: from zimbra62-e11.priv.proxad.net (unknown [172.20.243.212]) by smtp6-g21.free.fr (Postfix) with ESMTP id E7C3C822D8 for <22567-done@debbugs.gnu.org>; Mon, 8 Feb 2016 10:55:21 +0100 (CET) Date: Mon, 8 Feb 2016 10:57:19 +0100 (CET) From: f0rhum@free.fr Message-ID: <1324357435.77584271.1454925439041.JavaMail.root@zimbra62-e11.priv.proxad.net> In-Reply-To: <56B7E030.4060800@tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [88.170.160.103] X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Linux)/7.2.0-GA2598) X-Authenticated-User: f0rhum@free.fr X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Discovering this command, I submit a small mis-translation for french: "factor --version factor (GNU coreutils) 8.21 Copyright =C2=A9 2013 Free Software Foundation, Inc. License GPLv3+=C2=A0: GNU GPL version=C2=A03 ou ult=C3=A9rieure C'est logiciel libre..." Should be "C'est ***un*** logiciel libre..." or "Ceci est ***un*** logiciel= libre..." From unknown Sun Aug 17 22:10:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22567: Factoring 38 nines Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 08 Feb 2016 13:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22567 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: notabug To: f0rhum@free.fr, 22567-done@debbugs.gnu.org, traduc@traduc.org Received: via spool by 22567-done@debbugs.gnu.org id=D22567.14549379754107 (code D ref 22567); Mon, 08 Feb 2016 13:27:01 +0000 Received: (at 22567-done) by debbugs.gnu.org; 8 Feb 2016 13:26:15 +0000 Received: from localhost ([127.0.0.1]:38122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSlpW-00014B-Qw for submit@debbugs.gnu.org; Mon, 08 Feb 2016 08:26:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41033) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSlpV-000143-5d for 22567-done@debbugs.gnu.org; Mon, 08 Feb 2016 08:26:13 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 65D5C7AE80; Mon, 8 Feb 2016 13:26:12 +0000 (UTC) Received: from [10.3.113.142] (ovpn-113-142.phx2.redhat.com [10.3.113.142]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u18DQBiG025399; Mon, 8 Feb 2016 08:26:11 -0500 References: <56B453A3.7050002@go2.pl> <1324357435.77584271.1454925439041.JavaMail.root@zimbra62-e11.priv.proxad.net> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <56B89762.6030007@redhat.com> Date: Mon, 8 Feb 2016 06:25:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1324357435.77584271.1454925439041.JavaMail.root@zimbra62-e11.priv.proxad.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vubBBM3Ni5j007mOaEtn9rfjDcMHaHXvr" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -5.3 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vubBBM3Ni5j007mOaEtn9rfjDcMHaHXvr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/08/2016 02:57 AM, f0rhum@free.fr wrote: > Discovering this command, I submit a small mis-translation for french: Thanks, but translation errors should be submitted to the appropriate translation team, as mentioned in the --help output (and added in cc): $ LC_ALL=3Dfr_FR.UTF-8 factor --help | tail Afficher les facteurs premiers de chaque NOMBRE entier indiqu=C3=A9. Sans argument fourni, les nombres sont lus depuis l'entr=C3=A9e standard.= --help afficher l'aide et quitter --version afficher des informations de version et quitter Aide en ligne de GNU coreutils : = Signalez les probl=C3=A8mes de traduction de =C2=AB factor =C2=BB =C3=A0 = : Full documentation at: or available locally via: info '(coreutils) factor invocation' Hmm, it also looks like there's a missing translation bug in the --help output, at least in my build of coreutils (8.24, from Fedora 23). > "factor --version > factor (GNU coreutils) 8.21 > Copyright =C2=A9 2013 Free Software Foundation, Inc. > License GPLv3+ : GNU GPL version 3 ou ult=C3=A9rieure > > C'est logiciel libre..." >=20 > Should be "C'est ***un*** logiciel libre..." or "Ceci est ***un*** logi= ciel libre..." >=20 >=20 >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --vubBBM3Ni5j007mOaEtn9rfjDcMHaHXvr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWuJdzAAoJEKeha0olJ0NqGpkIAJZxhU0gpi9ZLPDZ6M0IJr/J bBkRGIx8lcMFmu2IrnBfpGrSFt4qpiM2Ty2xtbF2AmQcGXpKfrX7QpV3AvtvVXIW Zb2W5n42VHi87RXnk2sjO5KC7AnsOf3kHzdmELeokd4C2gn0PXizfSetBGTbqNZ6 KFtRStBvbZqovAgABDxmRPfor+zTt5CNPYHP7PJevWn86cTXfjsGe2iETMQ8hn0L 64qyp3LUDsyZiF/MfQvDog9nQ1DksRL7xSCw7GZcg1uLv44Kscz932KwPVnrumSa Fk4Pr4xeYPsD9kqnpNwX12XbDHHLFkCeSb8oe3BgYHI3GvWByM9EFI1mpJ2em8s= =pHbo -----END PGP SIGNATURE----- --vubBBM3Ni5j007mOaEtn9rfjDcMHaHXvr--