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: Re: redoing SCM representation in 2.2 Date: Tue, 17 May 2011 14:59:50 -0400 Message-ID: <87oc31p2zd.fsf@netris.org> References: <2932B3D9-7CE6-46B9-8A1E-51702E417D53@raeburn.org> <72BFF702-0847-45A6-A433-4BAC00F5950B@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1305658829 11959 80.91.229.12 (17 May 2011 19:00:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 May 2011 19:00:29 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Ken Raeburn Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 17 21:00:25 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QMPVI-0005m4-Ep for guile-devel@m.gmane.org; Tue, 17 May 2011 21:00:24 +0200 Original-Received: from localhost ([::1]:40405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMPVI-0003C3-1U for guile-devel@m.gmane.org; Tue, 17 May 2011 15:00:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMPVG-0003Bu-9f for guile-devel@gnu.org; Tue, 17 May 2011 15:00:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMPVF-0000po-BQ for guile-devel@gnu.org; Tue, 17 May 2011 15:00:22 -0400 Original-Received: from world.peace.net ([96.39.62.75]:52533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMPVF-0000i0-8k for guile-devel@gnu.org; Tue, 17 May 2011 15:00:21 -0400 Original-Received: from 209-6-41-222.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.41.222] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1QMPUs-0001av-Fq; Tue, 17 May 2011 14:59:58 -0400 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1QMPUk-0003up-VB; Tue, 17 May 2011 14:59:50 -0400 In-Reply-To: <72BFF702-0847-45A6-A433-4BAC00F5950B@raeburn.org> (Ken Raeburn's message of "Sun, 15 May 2011 16:43:26 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12501 Archived-At: Ken Raeburn writes: > On May 15, 2011, at 11:47, Andy Wingo wrote: >> No, but the nice thing about doubles is that it's a closed set. Any >> operation on a double produces a double. Subsets do not have that >> property. > > Well, I think it's also a subset of "long double", but if you define > the operations as overflowing rather than giving results in the long > double range, then you've defined it as a closed set, sure. > > But the question I was after was, even if we want to use the full > range of the values, do we need the entire set to be representable *in > immediate form*? I doubt the very largest and smallest values are > used often, so making just those values use heap storage probably > wouldn't be too costly in space. In principle, I agree with you that it might be reasonable to cut the exponent range of immediate doubles in half in order to gain an extra bit of tagging information. Unfortunately, it seems to me that the details of the IEEE 754 floating-point formats would make the required checks rather expensive. The exponent field of an IEEE 754 binary floating-point number is not stored in twos-complement format, but is instead "biased", meaning that a constant is added to the true exponent of two, such that 1 represents the smallest representable exponent, and 2^EXPBITS-2 represents the largest representable exponent. The worse problem is that a 0 in the exponent field means that the number is a (signed) zero, and 2^EXPBITS-1 means that the number is either infinity of a NaN. Given this, I don't see an obvious way to steal a bit or two from the exponent field without making the associated checks too expensive to be worth the benefits. I think at least two conditional branches would be required. Do you see a clever way around this? If so, can you please post the details? Best, Mark