[cl-json-devel] Encoding DOUBLE-FLOAT

[Robert Goldman]

On 6/23/11 Jun 23 -5:15 PM, Boris Smilga wrote:
> On Thu, Jun 23, 2011 at 2:47 PM, Robert Goldman <rpgoldman at sift.info> wrote:
>> On 6/23/11 Jun 23 -7:05 AM, Boris Smilga wrote:
.....
> 
>> I think in principle we should try to detect the relationship between
>> the different float subtypes.  Presumably we can do this using
>> MOST-POSITIVE-SHORT-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, etc.., etc.,
>> etc., and that would be portable...  If I get a chance, I will try to do
>> that: looks like it will be a little cumbersome.
> 
> Hmmm... I'm afraid I don't really get your idea.  The relationship
> between different float types is laid down quite explicitly in the
> Standard (should it be called ‘the Most Holy and Exalted Standard’?).
> Checking the limits won't give us anything, as the format of the
> number is orthogonal to its magnitude: 3.0D0 is a double, not a single
> float (in implementations which have distinct double and single
> floats), even though its numeric value falls inside the interval
> between least-positive-single-float and most-positive-single-float,
> and can be represented by a single float (without loss of precision).
> Pray, what exactly are you trying to accomplish here?

I was going to compare, e.g., MOST-POSITIVE-SHORT-FLOAT,
LEAST-NEGATIVE-SHORT-FLOAT and MOST-POSITIVE-SINGLE-FLOAT,
LEAST-NEGATIVE-SINGLE-FLOAT (at compile time) to attempt to determine if
SHORT-FLOAT and SINGLE-FLOAT are the same on the current implementation
and possibly conditionally-compile away the SINGLE-FLOAT type, and
similarly for DOUBLE- and LONG-....

I would not be checking the numeric values of the number at run-time,
but the bounds on the types at compile time.  Would that not work?

Thanks for the help,
r