Re: Simulation of fixed point in c WITH DIFFERENT BIT-WIDTH

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 03 Nov 2005 08:47:24 -0500, Robert A Duff wrote:

> Simon Wright <simon@pushface.org> writes:
> 
>> I'm not sure what is actually required for portability here. AARM95
>> 3.5.9(22-24) says
>> 
>>    The base range of an ordinary fixed point type need not include the
>>    specified bounds themselves so that the range specification can be
>>    given in a natural way, such as:
>> 
>>    type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;
>> 
>>    With 2's complement hardware, such a type could have a signed
>>    16-bit representation, using 1 bit for the sign and 15 bits for
>>    fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15).
> 
> This is a language design flaw, in my opinion.  "T'Last in T" and
> "T'Last in T'Base" should both always be true.

Yes it is painful. It forces to use T'Last instead of 1.0. Then conversions
to and back from float (for internal FP computations) become tricky,
because T(Float'(1.0)) may raise Constraint_Error.

>  If you want 16 bits, you
> should say "-1.0 .. 1.0-2.0**(-15)."  After all, we don't play these
> games with integers -- if you say "range -2**15..2**15", you get at
> least 17 bits (probably 32 bits).
> 
> The "need not" in the above wording means that the implementation has a
> choice.  It can include 1.0 in the base range of Fraction, or not.
> Some implementations will include the upper bound if and only if it
> does not require extra bits.  I think that kind of non-portability
> is unhelpful to programmers.

The abstraction many people mean is actually:

   type Fraction is delta <> range -1.0 .. 1.0;
   for Fraction'Size use 16*8; -- Give me as much as you can

So delta isn't exactly 2.0**(-15), it is 2.0/(2.0**16 + 1.0).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de