From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Nearly finished (re)integrating GMP for bignums. Date: Wed, 12 Feb 2003 15:13:12 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <871y2dnqxj.fsf@raven.i.defaultvalue.org> References: <87heb9pjni.fsf@raven.i.defaultvalue.org> <87r8adihxe.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045084556 23953 80.91.224.249 (12 Feb 2003 21:15:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2003 21:15:56 +0000 (UTC) Cc: Marius Vollmer Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18j4BC-0005xr-00 for ; Wed, 12 Feb 2003 22:12:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j4CX-0007qe-02 for guile-devel@m.gmane.org; Wed, 12 Feb 2003 16:13:53 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18j4Bw-0007Qp-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 16:13:16 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18j4Bu-0007Mn-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 16:13:15 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18j4Bt-0007K0-00 for guile-devel@gnu.org; Wed, 12 Feb 2003 16:13:13 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 9F811F0FF; Wed, 12 Feb 2003 15:13:12 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id A0863B9F3C; Wed, 12 Feb 2003 15:13:12 -0600 (CST) Original-To: djurfeldt@nada.kth.se In-Reply-To: (Mikael Djurfeldt's message of "Wed, 12 Feb 2003 18:34:59 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: guile-devel@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1924 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1924 Mikael Djurfeldt writes: > Ideally, the bignum code would use the pluggable source of random bits > in random.c and the GMP generators would be provided as optional > plugins for random.c. Rob, is this possible? The main issue I have now is that in scm_c_random_bignum, the code directly manipulates the old bignum internals. So I'll need to convert that to GMP. i.e.: LONG32 *bits, mask, w; nd = SCM_NUMDIGS (m); /* calculate mask for most significant digit */ #if SIZEOF_INT == 4 /* 16 bit digits */ if (nd & 1) { /* fix most significant 16 bits */ unsigned short s = SCM_BDIGITS (m)[nd - 1]; To be sure have the details right -- SCM_NUMDIGS gives the number of elements in SCM_BDIGITS, where the last element is the most significant digit right? I'll need to figure out how this should map onto the available GMP operations. Right now I don't expose much from numbers.c "bignum-wise", but I'm thinking of adding some _i_ functions that map onto gmp operations, and would probably also be appropriate for any other bignum implementation, i.e.: void scm_i_bigadd_ui (SCM dest, SCM src, unsigned long n); void scm_i_bigsub_ui (SCM dest, SCM src, unsigned long n); void scm_i_bigneg (SCM dest); etc. These prototypes follow the GMP calling convention which can be convenient since it allows you to express both "in-place" modifications where dest == src, or copy operations where dest != src. The ability to do "in-place" operations can be important when dealing with large bignums because you don't necessarily want to have to allocate a new bignum for each operation. Alternately, I could just support in-place operations: void scm_i_bigadd_ui (SCM big, unsigned long n); or I could only support our more traditional "always copy on write" style operations: SCM scm_i_bigadd_ui (SCM big, unsigned long n); The whole point of the scm_i_big* functions would be for use by other parts of guile where the code needs to operate directly on bignums. The alternative is to just expect the other code use SCM_I_BIG_MPZ(x), to get hold of the mpz_t value and then manipulate that directly. The direct approach could be faster, and gives more flexibility, but of course it's less portable (presuming we ever change our bignum implementation again). In truth, ATM we don't have that much code outside numbers.c that manipulates bignums directly. Aside from the GC and eq, it's mostly random.c and socket.c so far. So it may not be a big deal either way. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel