guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redoing SCM representation in 2.2


From: Mark H Weaver
Subject: Re: redoing SCM representation in 2.2
Date: Tue, 17 May 2011 14:59:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Ken Raeburn <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]