Simulation of fixed point in c WITH DIFFERENT BIT-WIDTH

Simulation of fixed point in c WITH DIFFERENT BIT-WIDTH

[mnamky]

Hi all;

Consider the following exaple
y = x * b'

where x is 12-bit wordlength and 11-bit fraction
and b is 16-bit wordlength and 14-bit fraction

simulation of this code is rather easy im Matlab but how could we do a
full analysis of this code in C with a good precision?

Thank you

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

[Dmitry A. Kazakov]

On 30 Oct 2005 08:41:38 -0800, mnamky wrote:

> Consider the following exaple
> y = x * b'
> 
> where x is 12-bit wordlength and 11-bit fraction
> and b is 16-bit wordlength and 14-bit fraction

... and b' is a differential of b? (:-)) 
 
> simulation of this code

What does it mean to "simulate code"?

> is rather easy im Matlab but how could we do a
> full analysis of this code in C with a good precision?

"Precision of full code analysis" sounds like compiler writing. Are you
writing a compiler ... in MATLAB/Simulink? (:-))

AFAIK, MATLAB/Simulink generates C and Ada code, so you can take a look at
it.

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

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

[Gautier Write-only]

mnamky wrote:

> Hi all;
> 
> Consider the following exaple
> y = x * b'
> 
> where x is 12-bit wordlength and 11-bit fraction
> and b is 16-bit wordlength and 14-bit fraction
> 
> simulation of this code is rather easy im Matlab but how could we do a
> full analysis of this code in C with a good precision?
> 
> Thank you

It is also easy in Ada - something like...

procedure Fixed_12 is
  type F1 is delta 2.0**(-11) range -1.0 .. 1.0;
  type F2 is delta 2.0**(-14) range -2.0 .. 2.0;
  x  : F1;
  y,b: F2;
begin
  x:= 0.12345;
  b:= 1.23456;
  y:= x * b;
end;

The precision is guaranteed - better than good...

But you want to do this in C ?! By Jove!
Fortunately, your subconscient suggested you the right newsgroup.

BTW, something is wrong, either with your Shift key, or with your Caps Lock key - see the title.
I can only sympathize, after having a similar problem: some beer had found unexpectedly its way into my keyboard.
______________________________________________________________ 
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm 
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm 
TeXCAD      --     http://www.mysunrise.ch/users/gdm/texcad.htm 

NB: For a direct answer, e-mail address on the Web site!

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

[Steve]

"mnamky" <mnamky@hotmail.com> wrote in message 
news:1130690498.388857.225170@g49g2000cwa.googlegroups.com...
> Hi all;
>
> Consider the following exaple
> y = x * b'
>
> where x is 12-bit wordlength and 11-bit fraction
> and b is 16-bit wordlength and 14-bit fraction
>
> simulation of this code is rather easy im Matlab but how could we do a
> full analysis of this code in C with a good precision?
>
> Thank you
>

Silly question:
  Why is this quesiton posted to comp.lang.ada?

Steve
(The Duck)

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

[Colin Paul Gloster]

Mnamky did not say in 
news:1130690498.388857.225170@g49g2000cwa.googlegroups.com that the 
datatypes could take negative values, but anyway Gautier's
type F1 is delta 2.0**(-11) range -1.0 .. 1.0;
is a wasteful declaration which is bigger than Mnamky's "12-bit 
wordlength and 11-bit fraction".
A two's complement signed 1 bit integer can have as its lowest value -1 
and as its greatest value 0.
So
type F3 is delta 2.0**(-11) range -1.0 .. 1.0 - 2.0**(-11);
type F4 is delta 2.0**(-14) range -2.0 .. 2.0 - 2.0**(-14);
are more appropiate datatypes.

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

[Gautier Write-only]

Colin Paul Gloster wrote:
> 
> Mnamky did not say in
> news:1130690498.388857.225170@g49g2000cwa.googlegroups.com that the
> datatypes could take negative values, but anyway Gautier's
> type F1 is delta 2.0**(-11) range -1.0 .. 1.0;
> is a wasteful declaration which is bigger than Mnamky's "12-bit
> wordlength and 11-bit fraction".
> A two's complement signed 1 bit integer can have as its lowest value -1
> and as its greatest value 0.
> So
> type F3 is delta 2.0**(-11) range -1.0 .. 1.0 - 2.0**(-11);
> type F4 is delta 2.0**(-14) range -2.0 .. 2.0 - 2.0**(-14);
> are more appropiate datatypes.

Thank you for this precision.
Being sure that my approximation was quite rough, I had put the "something like" verbal precaution :-)
G.

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

[Simon Wright]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

> Mnamky did not say in 
> news:1130690498.388857.225170@g49g2000cwa.googlegroups.com that the 
> datatypes could take negative values, but anyway Gautier's
> type F1 is delta 2.0**(-11) range -1.0 .. 1.0;
> is a wasteful declaration which is bigger than Mnamky's "12-bit 
> wordlength and 11-bit fraction".
> A two's complement signed 1 bit integer can have as its lowest value -1 
> and as its greatest value 0.
> So
> type F3 is delta 2.0**(-11) range -1.0 .. 1.0 - 2.0**(-11);
> type F4 is delta 2.0**(-14) range -2.0 .. 2.0 - 2.0**(-14);
> are more appropiate datatypes.

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).

With GCC 4.0.0 on Darwin, this program

   with Ada.Text_IO; use Ada.Text_IO;

   procedure Gloster is

      type F1 is delta 2.0**(-11) range -1.0 .. 1.0;
      for F1'Size use 12;
      type F2 is delta 2.0**(-14) range -1.0 .. 1.0;
      for F2'Size use 15;
      type F3 is delta 2.0**(-11) range -1.0 .. 1.0 - 2.0**(-11);
      type F4 is delta 2.0**(-14) range -2.0 .. 2.0 - 2.0**(-14);

   begin
      Put_Line ("F1's size is" & Natural'Image (F1'Size));
      Put_Line ("F2's size is" & Natural'Image (F2'Size));
      Put_Line ("F3's size is" & Natural'Image (F3'Size));
      Put_Line ("F4's size is" & Natural'Image (F4'Size));
   end Gloster;

outputs

   $ ./gloster
   F1's size is 12
   F2's size is 15
   F3's size is 12
   F4's size is 16

Commenting out the representation clauses, the output is

   $ ./gloster
   F1's size is 13
   F2's size is 16
   F3's size is 12
   F4's size is 16

I'm not sure why F4's size is 16, though; is this a bug?

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

[Colin Paul Gloster]

Simon Wright posted at Thu, 03 Nov 2005 06:13:19 +0000:

"[..]

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)."

I was unaware of this.

Simon Wright posted at Thu, 03 Nov 2005 06:13:19 +0000:

"[..]
      type F3 is delta 2.0**(-11) range -1.0 .. 1.0 - 2.0**(-11);
      type F4 is delta 2.0**(-14) range -2.0 .. 2.0 - 2.0**(-14);
[..]
[..] the output is
[..]
   F3's size is 12
   F4's size is 16

I'm not sure why F4's size is 16, though; is this a bug?"

No, the size of F4 should be 16 bits. Note that the smallest number F4 
can have is -2.0 as opposed to -1.0.

Remember, on 30 Oct 2005 08:41:38 -0800, Mnamky posted:

"[..]

[..] x is 12-bit wordlength and 11-bit fraction
and b is 16-bit wordlength and 14-bit fraction

[..]"

P.S. I apologize for distorting the References field in 
news:dka579$8fc$1@hudsucker.umdac.umu.se . The second entry in that 
field should of course not have been a copy of the first, but 
news:43653F2C.B20F75B5@fakeaddress.nil instead.

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

[Robert A Duff]

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.  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.

- Bob

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

[Dmitry A. Kazakov]

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

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

[Jeffrey R. Carter]

So many replies to an obvious and OT troll.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

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

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 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).

When dealing with legacy software/hardware, which is the only reason
I'd expect to use fixed point, one really does mean 2.0/(2.0**16)!

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

[Colin Paul Gloster]

Mnamky posted to news:comp.lang.ada :

"Hi all;

Consider the following exaple
y = x * b'

where x is 12-bit wordlength and 11-bit fraction
and b is 16-bit wordlength and 14-bit fraction

simulation of this code is rather easy im Matlab but how could we do a
full analysis of this code in C with a good precision?"

I fail to see the relevance of this to Ada. In C, you could use ints and 
interpret some bits as an integer and some bits as a vulgar fraction, as 
in computer games books for 386s and 486s (before Pentiums which had 
faster floating point support than integer support) in the 1990s, such 
as "Building a 3D Engine in C++" and La Mothe; Ratcliff; et al., 
"Tricks of the Game Programming Gurus", SAMS Publishing.

A worse way would be to use bitfields.

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

[Martin Krischik]

Am 02.11.2005, 12:57 Uhr, schrieb Colin Paul Gloster  
<Colin_Paul_Gloster@ACM.org>:

> Mnamky posted to news:comp.lang.ada :
>
> "Hi all;
>
> Consider the following exaple
> y = x * b'
>
> where x is 12-bit wordlength and 11-bit fraction
> and b is 16-bit wordlength and 14-bit fraction
>
> simulation of this code is rather easy im Matlab but how could we do a
> full analysis of this code in C with a good precision?"
>
> I fail to see the relevance of this to Ada. In C, you could use ints and
> interpret some bits as an integer and some bits as a vulgar fraction, as
> in computer games books for 386s and 486s (before Pentiums which had
> faster floating point support than integer support) in the 1990s, such
> as "Building a 3D Engine in C++" and La Mothe; Ratcliff; et al.,
> "Tricks of the Game Programming Gurus", SAMS Publishing.
>
> A worse way would be to use bitfields.

Well sounds to me you want a fixed poind type:

http://en.wikibooks.org/wiki/Ada_Programming/Types/delta

Tricky part is all the bit fideling you wish for. In Ada you usualy ask  
for a needed precision and prehaps a overall bit size and then let Ada  
sort out the rest.

Martin

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

[Gautier Write-only]

Colin Paul Gloster:

> Mnamky posted to news:comp.lang.ada :
> 
> "Hi all;
> 
> Consider the following exaple
> y = x * b'
> 
> where x is 12-bit wordlength and 11-bit fraction
> and b is 16-bit wordlength and 14-bit fraction
> 
> simulation of this code is rather easy im Matlab but how could we do a
> full analysis of this code in C with a good precision?"
> 
> I fail to see the relevance of this to Ada. In C, you could use ints and
> interpret some bits as an integer and some bits as a vulgar fraction, as
> in computer games books for 386s and 486s (before Pentiums which had
> faster floating point support than integer support) in the 1990s, such
> as "Building a 3D Engine in C++" and La Mothe; Ratcliff; et al.,
> "Tricks of the Game Programming Gurus", SAMS Publishing.

Some people were perverse enough to do it even in Ada, e.g.:

  http://homepage.sunrise.ch/mysunrise/gdm/e3d_html/svgaeffe__adb.htm#258_13

Shocking, isn't it ?

The method was also useful for a short time with Pentiums, but before the 3D graphics cards, since you can make the FPU and the CPU work simultaneously. For grabbing "manually" (i.e. withouth 3D hardware) single pixels on a texture map, you also gain time by not using the FPU for each pixel: otherwise, you would have each time one FPU division, plus a conversion to an array index, which must be slower than a single integer addition for the same index.

G.