[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: integer-decode-float usage question
- To: Sandra J Loosemore <firstname.lastname@example.org>
- Subject: Re: integer-decode-float usage question
- From: Barry Margolin <barmar@Think.COM>
- Date: Wed, 28 Oct 87 12:15 EST
- Cc: Jeff Mincy <mincy@Think.COM>, email@example.com
- In-reply-to: <8710280507.AA11702@orion.utah.edu>
Date: Tue, 27 Oct 87 22:07:23 MST
From: firstname.lastname@example.org (Sandra J Loosemore)
I guess the real problem I'm having is one of terminology: the "exponent"
returned by INTEGER-DECODE-FLOAT doesn't have the usual interpretation
as the power of 2 (or whatever the float radix is) that you multiply
the fractional part of the number by.
(integer-decode-float 1.0) => 8388608, -23, 1
(float-radix 1.0) => 2
(expt 2 -23) => 1/8388608
(* 8388608 1/8388608) => 1
So, what's your complaint? 1.0 = 8388608*2^(-23)
If you want the fraction to be as small as possible, you can write a
function that repeatedly shifts it until the least-significant bit is 1,
incrementing the exponent as it goes. In this case you'll end up with
1, 0, 1.
This is at least the third time I've had to do a conversion between one
floating point format and another. I've found myself wishing that, as
long as CL provides portable primitives for inquiring about the floating
point representations native to a particular implementation, it would
also provide a function like INTEGER-DECODE-FLOAT that lets you ask for
the same kinds of numbers but for some other float radix and precision.
Or at least some more specific documentation on how users can do this
themselves, given the existing primitives.
INTEGER-DECODE-FLOAT does one very simple thing: it unpacks a floating
point number. The numbers it returns are generally the exact same bit
patterns as were in the float to begin with (except for the sign).