From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: RFC: Arbitrary-precision floats for Guile Date: Tue, 01 Feb 2011 08:57:32 -0500 Message-ID: <878vxzx3g3.fsf@yeeloong.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296568669 14760 80.91.229.12 (1 Feb 2011 13:57:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 13:57:49 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 01 14:57:45 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PkGjp-0004rR-Jz for guile-devel@m.gmane.org; Tue, 01 Feb 2011 14:57:45 +0100 Original-Received: from localhost ([127.0.0.1]:50533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkGjo-0000tn-JG for guile-devel@m.gmane.org; Tue, 01 Feb 2011 08:57:44 -0500 Original-Received: from [140.186.70.92] (port=41798 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkGjl-0000tM-4I for guile-devel@gnu.org; Tue, 01 Feb 2011 08:57:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkGjj-00088p-UB for guile-devel@gnu.org; Tue, 01 Feb 2011 08:57:41 -0500 Original-Received: from world.peace.net ([216.204.32.208]:37719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkGjj-00088W-QR for guile-devel@gnu.org; Tue, 01 Feb 2011 08:57:39 -0500 Original-Received: from ip68-9-118-38.ri.ri.cox.net ([68.9.118.38] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1PkGje-0006Ki-7r; Tue, 01 Feb 2011 08:57:34 -0500 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1PkGjd-0007qK-0q; Tue, 01 Feb 2011 08:57:33 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 216.204.32.208 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11484 Archived-At: Hello all, I want to add arbitrary-precision floats to Guile. I'd use the mpf_t type from GNU MP. There would be a fluid whose value would determine the minimum precision to use for inexact operators. A value of #f (the default) would mean that normal floats would be used unless one of the operands was a bigfloat. Procedures that produce inexact numbers (including read and exact->inexact) would use the precision of the most precise inexact operand contributing to the result, or the value of the fluid, whichever is greater. There would also be a procedure to reduce the precision of an inexact number to some specified value. The syntax for inexact numbers would allow an optional suffix to specify the precision. One complication is that we'd have to implement the transcendental functions. However, I already have code to do that, as part of a bigfloat library I wrote a while back. I'd also like to add another more general representation of complex numbers whose real and imaginary parts are each of type SCM, like the way fractions are represented. The primary motivation would be to support arbitrary-precision complex numbers, but as an added bonus, would be able to support exact Gaussian integers. The existing complex representation would still be supported in the interests of efficiency. scm_make_rectangular would automatically choose the right representation: if the imaginary part was an exact zero, it would simply return the specified real part. If both parts were normal floats it would return the existing fast complex numbers, otherwise it would return the new more general complex number type. Now I know we have a release coming soon. I don't necessarily expect to get these changes merged before then, although I'm willing and able to implement all of this in the next week. However, I was hoping that I could at least get enough of it into 2.0 so that it could be part of 2.1 without breaking ABI compatibility. Do you think this is feasible? If not, would it be possible to delay the release a week or two? What do you think of this? Am I crazy? :) Best, Mark