From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,509f8e43dc081fde
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!newsread.com!news-xfer.newsread.com!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!194.25.134.62.MISMATCH!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Simulation of fixed point in c WITH DIFFERENT BIT-WIDTH
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.14.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <1130690498.388857.225170@g49g2000cwa.googlegroups.com>
 <1130690498.388857.225170@g49g2000cwa.googlegroups.com>
 <dka579$8fc$1@hudsucker.umdac.umu.se> <m2veza9s3k.fsf@grendel.local>
 <wccu0etyhar.fsf@shell01.TheWorld.com>
Date: Thu, 3 Nov 2005 15:33:54 +0100
Message-ID: <hbojdi82rqii$.1jkm8bqzmm7ik$.dlg@40tude.net>
NNTP-Posting-Date: 03 Nov 2005 15:33:58 MET
NNTP-Posting-Host: 4811b0e7.newsread2.arcor-online.net
X-Trace: 
 DXC=<Q^nU5g[dNW\ODPOkW97AZQ5U85hF6f;TjW\KbG]kaMXQ>n?D9BSA]\F;a<XDk=HIR[6LHn;2LCV^7enW;^6ZC`T<=9bOTW=MN^
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:6143
Date: 2005-11-03T15:33:58+01:00
List-Id: <comp.lang.ada>

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