float with 24-bit resolution

float with 24-bit resolution

[mailbox]

Hi,

I looked through the LRM and searched CLA but I could not find any
solution. Perhaps I've overlook somewhere.

I need a float with 24-bit resolution. My data needs to be encoded into
24 bits at a scaling of 720 degrees / 2^24 bits with the most
significant bit being the sign bit. This results in a value that ranges
from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
at increments of approximately 4.291534424e-5 degrees per bit.

The float and short_float have both 32-bit. I am using GCC3.3 that comes
with SuSE Linux 8.2 on Intel x86.

Is there a short_short_float for GCC 3.3?

How do I declare a float with 24-bit storage size?

Thanks in advance for your help.

--
Adrian Hoe
To email, remove "nospam" and "my"

Re: float with 24-bit resolution

[Jeffrey Creem]

<mailbox@adrianhoe.nospam.com.my> wrote in message
news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> Hi,
>
> I looked through the LRM and searched CLA but I could not find any
> solution. Perhaps I've overlook somewhere.
>
> I need a float with 24-bit resolution. My data needs to be encoded into
> 24 bits at a scaling of 720 degrees / 2^24 bits with the most
> significant bit being the sign bit. This results in a value that ranges
> from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
> at increments of approximately 4.291534424e-5 degrees per bit.

This does not sound anything like a float at all. It sounds much more like a
typical implementation of a fixed point type. Something along the lines of

package My_Pack is

The_Delta : constant := 4.291534424e-5;

  type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is delta
The_Delta range - 360.0 .. 359.9999571;
  for  Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Small use
The_Delta;
  for Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Size use
24;


end My_Pack;

There are all sorts of things you can get bitten by here...especially with
the 24 bit requirement but when looking for

a specific representation the details can be tricky.



What are you really trying to achieve at a higher level (e.g. talking to
some hardware, sending some message to a device, etc?)

Re: float with 24-bit resolution

[Adrian Hoe]

Jeffrey Creem wrote:
> <mailbox@adrianhoe.nospam.com.my> wrote in message
> news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> 
>>Hi,
>>
>>I looked through the LRM and searched CLA but I could not find any
>>solution. Perhaps I've overlook somewhere.
>>
>>I need a float with 24-bit resolution. My data needs to be encoded into
>>24 bits at a scaling of 720 degrees / 2^24 bits with the most
>>significant bit being the sign bit. This results in a value that ranges
>>from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
>>at increments of approximately 4.291534424e-5 degrees per bit.
> 
> 
> This does not sound anything like a float at all. It sounds much more like a
> typical implementation of a fixed point type. Something along the lines of
> 
> package My_Pack is
> 
> The_Delta : constant := 4.291534424e-5;
> 
>   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is delta
> The_Delta range - 360.0 .. 359.9999571;
>   for  Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Small use
> The_Delta;
>   for Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Size use
> 24;
> 
> 
> end My_Pack;
> 
> There are all sorts of things you can get bitten by here...especially with
> the 24 bit requirement but when looking for
> 
> a specific representation the details can be tricky.
> 
> 
> 
> What are you really trying to achieve at a higher level (e.g. talking to
> some hardware, sending some message to a device, etc?)
> 
> 
> 
> 


Consider I have another data type which is to be encoded into 24 bits at 
a scaling of 3600 degrees/sec / 2^24 bits with the most significant bit 
being the sign bit. This results in a value that ranges from 
+1799.999785 degrees per second (0x7FFFFF) to -1800.000 degrees per 
second (0x800000) at increments of approximately 2.14576721e-4 degrees 
per second per bit.

Can I declare just one 24-bit resolution float with a 24 bit storage 
size for both problems? How?

Thanks.

--
Adrian Hoe
To email, remove "nospam" and "my"

Re: float with 24-bit resolution

[Adrian Hoe]

Adrian Hoe wrote:
> Jeffrey Creem wrote:
> 
>> <mailbox@adrianhoe.nospam.com.my> wrote in message
>> news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
>>
>>> Hi,
>>>
>>> I looked through the LRM and searched CLA but I could not find any
>>> solution. Perhaps I've overlook somewhere.
>>>
>>> I need a float with 24-bit resolution. My data needs to be encoded into
>>> 24 bits at a scaling of 720 degrees / 2^24 bits with the most
>>> significant bit being the sign bit. This results in a value that ranges
>>> from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
>>> at increments of approximately 4.291534424e-5 degrees per bit.
>>
>>
>>
>> This does not sound anything like a float at all. It sounds much more 
>> like a
>> typical implementation of a fixed point type. Something along the 
>> lines of
>>
>> package My_Pack is
>>
>> The_Delta : constant := 4.291534424e-5;
>>
>>   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is 
>> delta
>> The_Delta range - 360.0 .. 359.9999571;
>>   for  
>> Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Small use
>> The_Delta;
>>   for Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Size 
>> use
>> 24;
>>
>>
>> end My_Pack;
>>
>> There are all sorts of things you can get bitten by here...especially 
>> with
>> the 24 bit requirement but when looking for
>>
>> a specific representation the details can be tricky.
>>
>>
>>
>> What are you really trying to achieve at a higher level (e.g. talking to
>> some hardware, sending some message to a device, etc?)
>>
>>
>>
>>
> 
> 
> Consider I have another data type which is to be encoded into 24 bits at 
> a scaling of 3600 degrees/sec / 2^24 bits with the most significant bit 
> being the sign bit. This results in a value that ranges from 
> +1799.999785 degrees per second (0x7FFFFF) to -1800.000 degrees per 
> second (0x800000) at increments of approximately 2.14576721e-4 degrees 
> per second per bit.
> 
> Can I declare just one 24-bit resolution float with a 24 bit storage 
> size for both problems? How?
> 
> Thanks.
> 
> -- 
> Adrian Hoe
> To email, remove "nospam" and "my"
> 


Sorry, I missed this.

Yes, I am trying to talk to some hardware.

--
Adrian Hoe
To email, remove "nospam" and "my"

Re: float with 24-bit resolution

[Mark Johnson]

Adrian Hoe wrote:
> 
> Jeffrey Creem wrote:
> > <mailbox@adrianhoe.nospam.com.my> wrote in message
> > news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> >
> >>Hi,
> >> [snip request for 24 bit +/- 360 degree values]
> > This does not sound anything like a float at all. It sounds much more like a
> > typical implementation of a fixed point type. Something along the lines of
> >
Let me second this comment - what you are asking for appears to be a
"fixed point" type and not a float. You may find it easier to search for
this kind of example when using "fixed point" instead of "float".

> > [snip - nice language lawyer type declaration]

> > What are you really trying to achieve at a higher level (e.g. talking to
> > some hardware, sending some message to a device, etc?)
> >
We can certainly give you better answers with this kind of information.

> Consider I have another data type which is to be encoded into 24 bits at
> a scaling of 3600 degrees/sec / 2^24 bits with the most significant bit
> being the sign bit. This results in a value that ranges from
> +1799.999785 degrees per second (0x7FFFFF) to -1800.000 degrees per
> second (0x800000) at increments of approximately 2.14576721e-4 degrees
> per second per bit.
> 
Ah. It appears you want to do some integration of speeds to get
position.

> Can I declare just one 24-bit resolution float with a 24 bit storage
> size for both problems? How?
> 
No.
First, as mentioned before, please refer to this as "fixed point".
Second, they are different data types. They happen to have a similar
underlying bit pattern but will be represented to the user in different
forms.
Third, let's say they are the same type - then you could say
  X := speed + distance;
to get some garbage value for X, when you really want something like
  new_distance := speed * delta_time + distance;
to get an updated distance. This would require:
 - three types (speed, distance, time)
 - arithmetic operators for "*"(speed, time) and similar operations
and some patience on your part. A quick review of "Dimensional Analysis"
may help as well.
Fourth, when dealing with fixed point arithmetic, it is often helpful to
consider factors such as
 - for intermediate calculations, having a double (or in your case -
perhaps just 32 bit) precision data type can help simplify arithmetic. 
 - when you multiply two numbers together, you get a double precision
result. Which part will you keep, the most or least significant portion?
It depends on your application which is more important.
 - when you divide two numbers (dp/sp) - you get a result and remainder.
If you want rounding, you must handle it yourself.
 - when you add two numbers, they must be "aligned" and of the same
type. You can certainly add two 24 bit values together (to get a 24 or
25 bit result) but if the bits are not aligned properly, you get a mess.
Using the two data types (speed, distance), the LSB is about 5x
different between them. You have to scale one or the other value before
you add to get a meaningful value. Which one you scale has an effect on
the result.

For example, on one system I simulated, a ship did not move until
reaching 5 knots because the result of (speed * delta_time) was less
than the LSB of the distance value. We had to use double precision for
location (X, Y) for most calculations and then use the MSB portion for
display on the screen.

Now - having said all of that, are you still interested in fixed point
arithmetic, and if so what is the real problem being solved so we can
suggest a complete answer?
  --Mark

Re: float with 24-bit resolution

[Jeffrey Creem]

"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f3cd84f$1_2@news.tm.net.my...
>
> Yes, I am trying to talk to some hardware.
>


Ok.... Certainly the fixed point definition I provided approaches a
solution. Complications that you need to think
about and or ignore/document, handle are:

1) Byte Order - The little endian/big endian thing. 24 bit types on little
endian machines talking to big edian H/W  (or vice versa)..
2) Getting the 24 bit type in the first place. How do you get the data from
the HW into memory to work with to start with. It is not
uncommon to have to do 32 bit or 16 bit transfers so you need a method for
getting the data to start with.
3) As another poster mentioned, there is the issue of what you do with the
data once you get it. These fixed point types might be good
as a starting point to get the data into a format that you can begin to work
with but once you start doing calculations on them you will
almost certainly need additional higher resolution fixed point types or
floating point of some precision to do you caculations.

There are more....This is not all that complicated but you do need to think
about this before you start coding.

Also, it may be CRITICAL (depending on what this is used for :) to
understand why we keep harping on the fact that fixed
point types are not floating point types and to understand the limitations
of each.

The basic difference is somewhat highlighted by the way one goes about
starting to declare each of these
types in Ada (although the differences themselves really have nothing at all
to do with Ada per se)

as a first order approximation of the difference, realize that (usually)
fixed point types are implemented using the integer math operations of the
processor while floating point is (usually) implemented using the floating
point unit.

Fixed point numbers always have the same precision (essentially) for all
values that they hold while floating point numbers
have a precision that varies (floats!) depending on the size of the number
involved.

It is best to visualize the underlying representation of these two types (a
working model for your mind, which may not
be exactly (ok..certainly is not the same as) how the compiler implements
it)  as


Fixed point

An Integer (which can vary) and a non-changing LSB that is always the same.
To figure out what value the
fixed point number represents at any given time, multiply (in your mind) the
Integer times the LSB and that is the value that the number
holds.


Floating Point

This can thought of as the computer storing part of the number in a fixed
length string and a separate exponent as a smaller
integer

The_Digits : '.' & String(1 .. 6); -- (Ok total pseudo code here, basically
saying that there is a decimal point followed by some numeric characters)
The_Exponent : Integer range -31 .. 31 (or something like that)

So, one way to store the number 122.1 would be to have "The_Digits" equal to

.1221000 and
The_Exponent = +3

So, as you can see, the float can hold really big or really small numbers
but as they get really big you eventually can  not even
represent digits to the right of the actual decimal point.



In reality (especially for floats) the actual representation and limitations
are much different and even more complicated but one thing you can quickly
see even with this working "model" is that one could easily end up with
floats where

A + B = A
Even when B was non-zero if the exponent of A is enough higher than B.

Re: float with 24-bit resolution

[Robert I. Eachus]

Mark Johnson wrote:

> For example, on one system I simulated, a ship did not move until
> reaching 5 knots because the result of (speed * delta_time) was less
> than the LSB of the distance value. We had to use double precision for
> location (X, Y) for most calculations and then use the MSB portion for
> display on the screen.

Hmmm.  I've solved the same problem by recalculating the predicted 
position whenever needed from the last known position and velocity.  But 
that was in a radar application, where I was doing data fusion, so 
running each location, velocity pair forward made more sense.

> Now - having said all of that, are you still interested in fixed point
> arithmetic, and if so what is the real problem being solved so we can
> suggest a complete answer?

I'll ask the same question a different way.  Using fixed-point 
arithmetic correctly is HARD.  Are you sure you are interested in the 
learning experience you will get?  In Ada, getting the declarations of 
fixed point types correct is not hard, and writing the code for a 
calculation may be very easy.  But you will find you need between ten 
minutes and a day or more to analyze whether the code you wrote does 
what you want.  This has little or nothing to do with Ada, and 
everything to do with error and bounds analysis for fixed-point 
arithmetic.  It is hard, but it is often worth it.  The only two 
operations that can introduce errors are division and type conversion. 
If you choose types correctly, you will often find you have no added 
error from your calculations.  (This is why almost all decent accounting 
packages use fixed-point arithmetic for most operations.)


-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Mark Johnson]

"Robert I. Eachus" wrote:
> 
> Mark Johnson wrote:
> 
> > For example, on one system I simulated, a ship did not move until
> > reaching 5 knots because the result of (speed * delta_time) was less
> > than the LSB of the distance value. We had to use double precision for
> > location (X, Y) for most calculations and then use the MSB portion for
> > display on the screen.
> 
> Hmmm.  I've solved the same problem by recalculating the predicted
> position whenever needed from the last known position and velocity.  But
> that was in a radar application, where I was doing data fusion, so
> running each location, velocity pair forward made more sense.
> 
I believe we are describing the same situation with a slightly different
emphasis. For example, in a a simulator, the user interface for the
instructor may be in terms of
  Ship A
  Speed 5 knots
  Bearing 220 degrees
followed by a command like
  Turn right 10 degrees
and we have to take that information plus the current location to
generate a new location at the iteration rate of the model (say 30 Hz).
The instructor is dealing with terms such as speed, bearing, and changes
in those values while the software inside must generate X / Y position
and do the appropriate conversions.
  --Mark

Re: float with 24-bit resolution

[Simon Wright]

"Jeffrey Creem" <jeff@thecreems.com> writes:

> package My_Pack is
> 
> The_Delta : constant := 4.291534424e-5;
>   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is delta
> The_Delta range - 360.0 .. 359.9999571;

You need to use the compiler's inbuilt infinite precision arithmetic here:

package Angles is

   Angle_Delta : constant := 360.0 / 2 ** 23;

   type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
   for Angle'Small use Angle_Delta;
   for Angle'Size use 24;
   
end Angles;

(this compiles, at least!)

Re: float with 24-bit resolution

[Robert I. Eachus]

Mark Johnson wrote:

> and we have to take that information plus the current location to
> generate a new location at the iteration rate of the model (say 30 Hz).
> The instructor is dealing with terms such as speed, bearing, and changes
> in those values while the software inside must generate X / Y position
> and do the appropriate conversions.

Right, my only point was that since the LSB difference in distances was 
small in any one time interval, errors would build up if you did:

for t in 1..n loop -- t in milliseconds
   X := X + Vx;
   Y := Y + Vy;
end loop;

instead of:

for t in 1..n loop
   X := X0 + t*Vx;
   Y := Y0 + t*Vy;
end loop;

(Of course, you are actually doing this for a set of tracks and looking 
for matches.)  I actually had to explain why the first formulation was 
not "more efficient."  (Or maybe it was more efficient, just wrong.  My 
attitude has always been that I don't care how fast you can calculate a 
wrong answer.)

-- 
                                            Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Robert I. Eachus]

Jeffrey Creem wrote:
> <mailbox@adrianhoe.nospam.com.my> wrote in message
> news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> 
>>Hi,
>>
>>I looked through the LRM and searched CLA but I could not find any
>>solution. Perhaps I've overlook somewhere.
>>
>>I need a float with 24-bit resolution. My data needs to be encoded into
>>24 bits at a scaling of 720 degrees / 2^24 bits with the most
>>significant bit being the sign bit. This results in a value that ranges
>>from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
>>at increments of approximately 4.291534424e-5 degrees per bit.
> 
> 
> This does not sound anything like a float at all. It sounds much more like a
> typical implementation of a fixed point type. Something along the lines of
> 
> package My_Pack is
> 
> The_Delta : constant := 4.291534424e-5;
> 
>   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is delta
> The_Delta range - 360.0 .. 359.9999571;
>   for  Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Small use
> The_Delta;
>   for Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type'Size use
> 24;

Okay, I'll complain. ;-)  You can declare the type as

   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is 

          delta The_Delta range - 360.0 .. 360.0;

but if you don't want to, you are much more likely to get exactly what 
you want, and have the users understand it as well, if you say:

   The_Delta : constant := 720.0/2**24;

   type Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type is
          delta The_Delta range - 360.0 .. 360.0 - The_Delta;
   for Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type'Size
          use 24;



--
                                              Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Adrian Hoe]

Simon Wright wrote:
> "Jeffrey Creem" <jeff@thecreems.com> writes:
> 
> 
>>package My_Pack is
>>
>>The_Delta : constant := 4.291534424e-5;
>>  type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is delta
>>The_Delta range - 360.0 .. 359.9999571;
> 
> 
> You need to use the compiler's inbuilt infinite precision arithmetic here:
> 
> package Angles is
> 
>    Angle_Delta : constant := 360.0 / 2 ** 23;
> 
>    type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
>    for Angle'Small use Angle_Delta;
>    for Angle'Size use 24;
>    
> end Angles;
> 
> (this compiles, at least!)




OK, I just reply to all the responses in one single reply.

My first description of the requirement is to read and write position 
value of azimuth and elevation to an external device and the second 
description of the requirement describes the data read and written of 
the velocity of azimuth and elevation. The device has an accuracy of 
+-0.0014 degrees or +-25urad.

These values (position and velocity) will be read from the device and 
some calculation will take place and new values (position and velocity) 
will then be sent to the device.

After a brief analysis based on the solution by Simon, that solve the 
mapping problem for a while.

This implementation gives the following values:

Angle'first => -360.00000
Angle'last  => 359.99996

I did a quick and dirty interface and have the maximum position read. My 
Ada code spills 359.99996 but the device demo software which is written 
in C spills 359.9999571 which conforms to my first requirement description.

I then send a position data with 359.99996 back to the device and have 
the position read by the device demo software, it reads 359.9999611. I 
don't understand why 359.9999611 instead of 359.99996? (Scratching head :)

How do I have Angle to give me precision of 7 decimal?

I don't have the source code for the C library and the C demo software.

My quick and dirty interface in Ada like this:

-----------------------------------------------------------------------
procedure Dirty is

    Angle_Delta : constant := 360.0 / 2 ** 23;
    type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
    for Angle'Small use Angle_Delta;
    for Angle'Size use 24;

    Position : Angle;
begin

    Position_Read (Position); -- Call an Ada procedure which interface 
to C library function

    put_line (Angle'Image (Position));

    Position_Write (Position); -- Call an Ada procedure which interface 
to C library function
-------------------------------------------------------------------------


end Dirty;

Re: float with 24-bit resolution

[Jeffrey Creem]

Everyting is working fine...But when you use 'image you don't have control
over # of digits that are displayed

with Text_Io;

procedure It_Really_Works is



Angle_Delta : constant := 360.0 / 2 ** 23;

type Angle is delta Angle_Delta range - 360.0 .. 360.0 - Angle_Delta;

for Angle'Small use Angle_Delta;

for Angle'Size use 24;

package Angle_Io is new Text_Io.Fixed_Io(Angle);

begin

Angle_Io.Put(Item => Angle'Last, Fore => 4, Aft => 12);

Text_Io.New_Line;



end It_Really_Works;


The above prints this.....Note that I suspect that the Ada code will be
capable of printing far more digits than the C code if you would like.

 359.999957084656

Re: float with 24-bit resolution

[Matthew Heaney]

<mailbox@adrianhoe.nospam.com.my> wrote in message
news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> Hi,
>
> I looked through the LRM and searched CLA but I could not find any
> solution. Perhaps I've overlook somewhere.
>
> I need a float with 24-bit resolution. My data needs to be encoded into
> 24 bits at a scaling of 720 degrees / 2^24 bits with the most
> significant bit being the sign bit. This results in a value that ranges
> from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
> at increments of approximately 4.291534424e-5 degrees per bit.

You're not asking for a floating point type at all -- you're asking for a
fixed point type.

This type has the properties you specified:

   Degrees_Type_Delta : constant := 360.0 / 2**23;

   type Degrees_Type is
      delta Degrees_Type_Delta
     range -360.0 .. 360.0;

   for Degrees_Type'Small use Degrees_Type_Delta;

   for Degrees_Type'Size use 24;


Here is a test program, that dumps the bits of various values of
Degrees_Type:

with Ada.Text_IO;  use Ada.Text_IO;
with Ada.Unchecked_Conversion;

procedure Test_Fixed is

   Degrees_Type_Delta : constant := 360.0 / 2**23;

   type Degrees_Type is
      delta Degrees_Type_Delta
     range -360.0 .. 360.0;

   for Degrees_Type'Small use Degrees_Type_Delta;

   for Degrees_Type'Size use 24;

   type I24_Type is range -2**23 .. 2**23 - 1;
   for I24_Type'Size use 24;

   function To_I24 is
     new Ada.Unchecked_Conversion
     (Degrees_Type,
      I24_Type);

   package I24_IO is
     new Ada.Text_IO.Integer_IO (I24_Type);

   use I24_IO;

   package Degrees_IO is
     new Ada.Text_IO.Fixed_IO (Degrees_Type);

   use Degrees_IO;

   F : Degrees_Type;
   I : I24_Type;

begin

   F := 45.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := 90.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := 135.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := 180.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := 225.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := 270.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := Degrees_Type'Last;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   --negative values:

   F := -45.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := -90.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := -135.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := -180.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := -225.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := -270.0;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

   F := Degrees_Type'First;
   I := To_I24 (F);

   Put (F);  Put (' '); Put (I, Base => 16); New_Line;

end Test_Fixed;

Re: float with 24-bit resolution

[Matthew Heaney]

"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f3cd7f4$1_2@news.tm.net.my...
>
> Consider I have another data type which is to be encoded into 24 bits at
> a scaling of 3600 degrees/sec / 2^24 bits with the most significant bit
> being the sign bit. This results in a value that ranges from
> +1799.999785 degrees per second (0x7FFFFF) to -1800.000 degrees per
> second (0x800000) at increments of approximately 2.14576721e-4 degrees
> per second per bit.
>
> Can I declare just one 24-bit resolution float with a 24 bit storage
> size for both problems? How?

Again, just declare a fixed point type:

T_Delta : constant := 3600.0 / 2**23;

type T is
   delta T_Delta
   range -3600.0 .. 3600.0;

for T'Small use T_Delta;
for T'Size use 24;

Re: float with 24-bit resolution

[Matthew Heaney]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:qB6%a.119963$Oz4.25059@rwcrnsc54...
>
> "Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
> news:3f3cd84f$1_2@news.tm.net.my...
> >
>
> 1) Byte Order - The little endian/big endian thing. 24 bit types on little
> endian machines talking to big edian H/W  (or vice versa)..
> 2) Getting the 24 bit type in the first place. How do you get the data
from
> the HW into memory to work with to start with. It is not
> uncommon to have to do 32 bit or 16 bit transfers so you need a method for
> getting the data to start with.

It doesn't matter: just specify the same T'Small but set T'Size = 32.

(In general you should always specify T'Small for fixed point types.)

> 3) As another poster mentioned, there is the issue of what you do with the
> data once you get it. These fixed point types might be good
> as a starting point to get the data into a format that you can begin to
work
> with but once you start doing calculations on them you will
> almost certainly need additional higher resolution fixed point types or
> floating point of some precision to do you caculations.

Fine: just convert it from the fixed point type to whatever type you desire.

Re: float with 24-bit resolution

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F3D10B7.9080707@attbi.com...
>
> I'll ask the same question a different way.  Using fixed-point
> arithmetic correctly is HARD.  Are you sure you are interested in the
> learning experience you will get?  In Ada, getting the declarations of
> fixed point types correct is not hard, and writing the code for a
> calculation may be very easy.

The immediate problem of the OP is to get the data off of the hardware
interface.  To do that you need a fixed point type.

After you have the value, then yes, you need to understand the arithmetic
model, but as you say this is a problem no matter what the programming
language.

Re: float with 24-bit resolution

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vy8xuu235.fsf@smaug.pushface.org...
> "Jeffrey Creem" <jeff@thecreems.com> writes:
>
> You need to use the compiler's inbuilt infinite precision arithmetic here:
>
> package Angles is
>
>    Angle_Delta : constant := 360.0 / 2 ** 23;
>
>    type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
>    for Angle'Small use Angle_Delta;
>    for Angle'Size use 24;
>
> end Angles;

This is correct, except that you don't need to subtract the value of
Angle_Delta when specifying the Angle'Last.  The following declaration is
perfectly correct:

Angle_Delta : constant := 360.0 / 2 ** 23;
type Angle is delta Angle_Delta range -360.0 .. 360.0;  --360, not
360-T'Small
for Angle'Small use Angle_Delta;
for Angle'Size use 24;

Re: float with 24-bit resolution

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F3DA81B.2070701@attbi.com...
>
> Okay, I'll complain. ;-)  You can declare the type as
>
>    type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is
>
>           delta The_Delta range - 360.0 .. 360.0;
>
> but if you don't want to, you are much more likely to get exactly what
> you want, and have the users understand it as well, if you say:
>
>    The_Delta : constant := 720.0/2**24;
>
>    type Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type is
>           delta The_Delta range - 360.0 .. 360.0 - The_Delta;
>    for Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type'Size
>           use 24;

You didn't specify a value for T'Small.

And why on earth did you say 360 - The_Delta for T'Last???  360 should work
fine...

Re: float with 24-bit resolution

[Robert I. Eachus]

Matthew Heaney wrote:
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
> news:3F3DA81B.2070701@attbi.com...
> 
>>Okay, I'll complain. ;-)  You can declare the type as
>>
>>   type Probably_Gonna_Work_But_Language_Lawyers_Will_Complain_Type is
>>
>>          delta The_Delta range - 360.0 .. 360.0;
>>
>>but if you don't want to, you are much more likely to get exactly what
>>you want, and have the users understand it as well, if you say:
>>
>>   The_Delta : constant := 720.0/2**24;
>>
>>   type Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type is
>>          delta The_Delta range - 360.0 .. 360.0 - The_Delta;
>>   for Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type'Size
>>          use 24;
> 
> 
> You didn't specify a value for T'Small.

Oops!

for Gonna_Work_And_Language_Lawyers_Will_Not_Complain_Type'Small
        use The_Delta;

Soright?

> And why on earth did you say 360 - The_Delta for T'Last???  360 should work
> fine...

Because I was trying to show that, if you do subtract it off as a style 
issue, you should use the named number rather than a decimal approximation.




-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Simon Wright]

"Matthew Heaney" <matthewjheaney@earthlink.net> writes:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vy8xuu235.fsf@smaug.pushface.org...
> > "Jeffrey Creem" <jeff@thecreems.com> writes:
> >
> > You need to use the compiler's inbuilt infinite precision arithmetic here:
> >
> > package Angles is
> >
> >    Angle_Delta : constant := 360.0 / 2 ** 23;
> >
> >    type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
> >    for Angle'Small use Angle_Delta;
> >    for Angle'Size use 24;
> >
> > end Angles;
> 
> This is correct, except that you don't need to subtract the value of
> Angle_Delta when specifying the Angle'Last.  The following declaration is
> perfectly correct:
> 
> Angle_Delta : constant := 360.0 / 2 ** 23;
> type Angle is delta Angle_Delta range -360.0 .. 360.0;  --360, not
> 360-T'Small
> for Angle'Small use Angle_Delta;
> for Angle'Size use 24;

I suppose this is some sort of convenience offered by the compiler? or
is it the ARM? or an AI? because clearly there is no binary
representation of +360.0.

Re: float with 24-bit resolution

[Simon Wright]

"Matthew Heaney" <matthewjheaney@earthlink.net> writes:

> <mailbox@adrianhoe.nospam.com.my> wrote in message
> news:3F3CCB0F.543478AF@adrianhoe.nospam.com.my...
> > Hi,
> >
> > I looked through the LRM and searched CLA but I could not find any
> > solution. Perhaps I've overlook somewhere.
> >
> > I need a float with 24-bit resolution. My data needs to be encoded into
> > 24 bits at a scaling of 720 degrees / 2^24 bits with the most
> > significant bit being the sign bit. This results in a value that ranges
> > from +359.9999571 degrees (0x7FFFFF) to -360.0000000 degrees (0x800000)
> > at increments of approximately 4.291534424e-5 degrees per bit.
> 
> You're not asking for a floating point type at all -- you're asking for a
> fixed point type.

to OP: in Ada, there are *real* numbers (which can have non-integer
values): the way in which real numbers can be represented is either in
floating-point or fixed-point. floating-point format has a mantissa
and an exponent, and corresponds to C float or double; fixed-point has
no exponent, and no C analog either, it's just 'int where the least
significant bit represents (in your case) 2**-24'.

Re: float with 24-bit resolution

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vlltso6ld.fsf@smaug.pushface.org...
> "Matthew Heaney" <matthewjheaney@earthlink.net> writes:
>
> > This is correct, except that you don't need to subtract the value of
> > Angle_Delta when specifying the Angle'Last.  The following declaration
is
> > perfectly correct:
> >
> > Angle_Delta : constant := 360.0 / 2 ** 23;
> > type Angle is delta Angle_Delta range -360.0 .. 360.0;  --360, not
> > 360-T'Small
> > for Angle'Small use Angle_Delta;
> > for Angle'Size use 24;
>
> I suppose this is some sort of convenience offered by the compiler? or
> is it the ARM? or an AI? because clearly there is no binary
> representation of +360.0.

You are correct that the value 360.0 is not in the range, but as a
convenience the language allows you to declare it that way.  This has been
the language rule since Ada83.  See RM95 3.5.9 (13-14 and in particular
22-24, 27).

Re: float with 24-bit resolution

[Adrian Hoe]

Matthew Heaney wrote:
> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vy8xuu235.fsf@smaug.pushface.org...
> 
>>"Jeffrey Creem" <jeff@thecreems.com> writes:
>>
>>You need to use the compiler's inbuilt infinite precision arithmetic here:
>>
>>package Angles is
>>
>>   Angle_Delta : constant := 360.0 / 2 ** 23;
>>
>>   type Angle is delta Angle_Delta range -360.0 .. 360.0 - Angle_Delta;
>>   for Angle'Small use Angle_Delta;
>>   for Angle'Size use 24;
>>
>>end Angles;
> 
> 
> This is correct, except that you don't need to subtract the value of
> Angle_Delta when specifying the Angle'Last.  The following declaration is
> perfectly correct:
> 
> Angle_Delta : constant := 360.0 / 2 ** 23;
> type Angle is delta Angle_Delta range -360.0 .. 360.0;  --360, not
> 360-T'Small
> for Angle'Small use Angle_Delta;
> for Angle'Size use 24;
> 
> 
> 


But subtracting the value of Angle_Delta makes the code more 
understandable, doesn't it? That translates to -360.0000000 .. +359.9999571.

Re: float with 24-bit resolution

[Martin Dowie]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vfzk0o6am.fsf@smaug.pushface.org...
[snip]
> to OP: in Ada, there are *real* numbers (which can have non-integer
> values): the way in which real numbers can be represented is either in
> floating-point or fixed-point. floating-point format has a mantissa
> and an exponent, and corresponds to C float or double; fixed-point has
> no exponent, and no C analog either, it's just 'int where the least
> significant bit represents (in your case) 2**-24'.

Don't forget that 'fixed-point' is itself sub-divided into 2 categories:
'ordinary'
and 'decimal', though I've never found a need for the 'decimal' flavour
myself :-)

Re: float with 24-bit resolution

[Matthew Heaney]

"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f405ef4$1_1@news.tm.net.my...
>
> But subtracting the value of Angle_Delta makes the code more
> understandable, doesn't it? That translates to -360.0000000 ..
+359.9999571.

No, it does not.  The practice of subtracting off T'Small from the upper
bound in the type declaration is distracting, and only adds unecesssary
noise.  The language is the way it is, so don't fight it.

Re: float with 24-bit resolution

[Mark Johnson]

"Robert I. Eachus" wrote:
> 
> Right, my only point was that since the LSB difference in distances was
> small in any one time interval, errors would build up if you did:
> 
> for t in 1..n loop -- t in milliseconds
>    X := X + Vx;
>    Y := Y + Vy;
> end loop;
> 
> instead of:
> 
> for t in 1..n loop
>    X := X0 + t*Vx;
>    Y := Y0 + t*Vy;
> end loop;
> 
I clearly understand the issue with truncation errors [hence the need
for better accuracy] but this appears to be getting well away from the
OP's problem area. Please also note that your solution assumes a
constant velocity vector (which is not the case in the example I
provided).

> (Of course, you are actually doing this for a set of tracks and looking
> for matches.)
Only the first part is true, the last half does not apply.

>  I actually had to explain why the first formulation was
> not "more efficient."  (Or maybe it was more efficient, just wrong.  My
> attitude has always been that I don't care how fast you can calculate a
> wrong answer.)
> 
What is "right" and "wrong" depends on the application domain so what
may be "better" for your application may actually introduce other errors
in another.
  --Mark

Re: float with 24-bit resolution

[Adrian Hoe]

Matthew Heaney wrote:
> "Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
> news:3f405ef4$1_1@news.tm.net.my...
> 
>>But subtracting the value of Angle_Delta makes the code more
>>understandable, doesn't it? That translates to -360.0000000 ..
> 
> +359.9999571.
> 
> No, it does not.  The practice of subtracting off T'Small from the upper
> bound in the type declaration is distracting, and only adds unecesssary
> noise.  The language is the way it is, so don't fight it.


Is it in the LRM? I could not find it or I may have overlook it. Please 
give me a pointer.

Re: float with 24-bit resolution

[Matthew Heaney]

"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f419536$1_1@news.tm.net.my...
>
> Is it in the LRM? I could not find it or I may have overlook it. Please
> give me a pointer.

RM95 3.5.9 (13-14 and in particular the examples in 22-24, 27).

Re: float with 24-bit resolution

[Robert I. Eachus]

Martin Dowie wrote:

> Don't forget that 'fixed-point' is itself sub-divided into 2 categories:
> 'ordinary'
> and 'decimal', though I've never found a need for the 'decimal' flavour
> myself :-)

It is more of a convenience in declaring decimal fixed point types than 
any inherent difference once the types are created.

type Dollars is digits 9 delta 0.01;

on most machines should produce exactly the same type as:

type Dollars is delta 0.01 range -2.0**31/100..2.0**31/100;
for Dollars'Small use 0.01;

But if you are doing financial work it is much clearer.  (It says I want 
a type that corresponds to Cobol +9999999.99.
-- 
                                       Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Robert I. Eachus]

Mark Johnson wrote:

> I clearly understand the issue with truncation errors [hence the need
> for better accuracy] but this appears to be getting well away from the
> OP's problem area. Please also note that your solution assumes a
> constant velocity vector (which is not the case in the example I
> provided).
> 
(I said:)
>>(Of course, you are actually doing this for a set of tracks and looking
>>for matches.)

Mark again:
> Only the first part is true, the last half does not apply.

Actually, it is part of the magic.  If you have two tracks at times t1 
and t2, and they have different velocity vectors, they may be the same 
target.  If when you project the first track ahead to t3, in between t1 
and t2 and project track two back in time to t3, the tracks intersect, 
that is a pretty good guess.

What really happens is that the aircraft may be constantly changing 
heading, but the interpolation is imprecise enough to allow the course 
to be represented by two line segments.  So yes, my method does require 
an assumption of constant velocity vectors, but it is using that 
assumption to actually detect headings that are changing.

But this (data fusion algoritms) is really getting off topic in this 
thread. ;-)

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: float with 24-bit resolution

[Ludovic Brenta]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> Martin Dowie wrote:
> 
> > Don't forget that 'fixed-point' is itself sub-divided into 2 categories:
> > 'ordinary'
> > and 'decimal', though I've never found a need for the 'decimal' flavour
> > myself :-)
> 
> It is more of a convenience in declaring decimal fixed point types
> than any inherent difference once the types are created.
> 
> type Dollars is digits 9 delta 0.01;
> 
> on most machines should produce exactly the same type as:
> 
> type Dollars is delta 0.01 range -2.0**31/100..2.0**31/100;
> for Dollars'Small use 0.01;
> 
> But if you are doing financial work it is much clearer.  (It says I
> want a type that corresponds to Cobol +9999999.99.

More important than being clearer, decimal types avoid some rounding
errors that only occur in binary representations.  Some decimal
numbers do not have a finite representation in base 2.  For example,
the number 0.42 (in base 10) becomes 0.01101011100001010001... in base
2.  This is one number that would require an infinite number of bits
to represent exactly, so any calculations made with it would involve
some rounding and loss of precision.  The financial sector is one
particular industry where calculations must be absolutely exact to
some number of decimal, not binary, places.  It is common, there, to
use packed-decimal representations where 4 bits correspond to exactly
1 decimal place.  In packed decimal, 0.42 would become 0.01000010,
requiring a finite number of bits.

-- 
Ludovic Brenta.

Re: float with 24-bit resolution

[Mark Johnson]

"Robert I. Eachus" wrote:
> 
> Mark Johnson wrote:
> 
> (I said:)
> >>(Of course, you are actually doing this for a set of tracks and looking
> >>for matches.)
> 
> Mark again:
> > Only the first part is true, the last half does not apply.
> 
> Actually, it is part of the magic.  [snip - long explanation of
> tracking aircraft / data fusion]
Sorry, but my statement stands. I was not talking about data fusion. Yes
- we have tracks [to display to the instructor], but we don't "look for
matches" in the simulator example I provided. If you want to discuss
this further, I suggest a private email exchange.
  --Mark

Re: float with 24-bit resolution

[Mark Johnson]

Ludovic Brenta wrote:
> 
> [snip - use of decimal fixed point types]
> 
> More important than being clearer, decimal types avoid some rounding
> errors that only occur in binary representations.  Some decimal
> numbers do not have a finite representation in base 2.  For example,
> the number 0.42 (in base 10) becomes 0.01101011100001010001... in base
> 2.  This is one number that would require an infinite number of bits
> to represent exactly, so any calculations made with it would involve
> some rounding and loss of precision.  The financial sector is one
> particular industry where calculations must be absolutely exact to
> some number of decimal, not binary, places.  It is common, there, to
> use packed-decimal representations where 4 bits correspond to exactly
> 1 decimal place.  In packed decimal, 0.42 would become 0.01000010,
> requiring a finite number of bits.

Actually, if you look at it carefully, binary can be an acceptable
alternative - but you must use it in a different manner. For example,
representing a number with two decimal digits of precision as an integer
can be done where
  042 (a value in memory / register)
is interpreted as
  0.42
in calculations and for display to the user. We generated data of that
type (ages ago) on a machine that had no packed decimal types (nor
floating point). That machine then sent the data to a "display computer"
where a software divide by 10 routine (no hardware divide) was used to
generate the values to display to the user. That method did a few more
calculations to conserve scarce I/O resources.

For machines where packed decimal is supported, what you say is true,
but it is not the only alternative. This other way of looking at fixed
types in general is simply to treat like integers - with a specified
value as the LSB (not one). In the example above, the LSB is 0.01. The
compiler still has to work out all the arithmetic operations and side
effects, but it is feasible. 
  --Mark

Re: float with 24-bit resolution

[Ludovic Brenta]

Mark Johnson <mark_h_johnson@raytheon.com> writes:
> Actually, if you look at it carefully, binary can be an acceptable
> alternative - but you must use it in a different manner. For example,
> representing a number with two decimal digits of precision as an integer
> can be done where
>   042 (a value in memory / register)
> is interpreted as
>   0.42
> in calculations and for display to the user. We generated data of that
> type (ages ago) on a machine that had no packed decimal types (nor
> floating point). That machine then sent the data to a "display computer"
> where a software divide by 10 routine (no hardware divide) was used to
> generate the values to display to the user. That method did a few more
> calculations to conserve scarce I/O resources.
> 
> For machines where packed decimal is supported, what you say is true,
> but it is not the only alternative. This other way of looking at fixed
> types in general is simply to treat like integers - with a specified
> value as the LSB (not one). In the example above, the LSB is 0.01. The
> compiler still has to work out all the arithmetic operations and side
> effects, but it is feasible. 

What you describe is a second-best solution, and by your own accord
you only used it because the target hardware did not support
packed-decimal representations.  Your divide-by-10 routine was the
weak point; 10 happens not to be a power of two, and therefore any
division of a binary number by 10 is bound to introduce rounding and
imprecision.  You may minimise the impact of that by doing the
division as late as possible, e.g. for display purposes; this is
probably what made the solution acceptable to you.  However, if your
program must write to a text file that serves as input to another
program (and then another, etc.), then the loss of precision quickly
becomes unacceptable.

Well, all of this is off-topic; here's a nice way to come back to Ada:

ARM B.4(13), package Interfaces.COBOL:

type Decimal_Element  is mod implementation-defined;
type Packed_Decimal is
   array (Positive range <>) of Decimal_Element;
pragma Pack(Packed_Decimal);

:)

-- 
Ludovic Brenta.

Re: float with 24-bit resolution

[Mark Johnson]

Ludovic Brenta wrote:
> 
> Mark Johnson <mark_h_johnson@raytheon.com> writes:
> > [snip explanation of integer based fixed point decimal values]
> 
> What you describe is a second-best solution, and by your own accord
> you only used it because the target hardware did not support
> packed-decimal representations.  Your divide-by-10 routine was the
> weak point; 10 happens not to be a power of two, and therefore any
> division of a binary number by 10 is bound to introduce rounding and
> imprecision.  
Perhaps you don't understand the solution I proposed. Using the example
I provided, to get the digits for display of 0.42, you would:
 - divide 42 by 10, getting result 4 and remainder 2 (last digit)
 - note that 4<10, getting result 0 and remainder 4 (second digit)
 - generate the decimal point
 - generate the zero
and display the value 0.42. No round off errors or any imprecision. This
approach can be generalized to any fixed point decimal type. Depending
on the range of values / precision required, it may require the
occasional use of double precision values and integer division that
produces both the result and remainder.

As I mentioned before, you certainly have to do the "right thing" when
it comes to doing arithmetic and conversions to other forms, but fixed
point decimal arithmetic without packed decimal data types can be done
without introducing any errors.

> You may minimise the impact of that by doing the
> division as late as possible, e.g. for display purposes; this is
> probably what made the solution acceptable to you.  However, if your
> program must write to a text file that serves as input to another
> program (and then another, etc.), then the loss of precision quickly
> becomes unacceptable.
Once you understand how to generate the correct values w/o any error,
you will find that this statement does not apply.
  --Mark

Re: float with 24-bit resolution

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]


"Mark Johnson" <mark_h_johnson@raytheon.com> a �crit dans le message de news:3F4623A7.6718B8C0@raytheon.com...
[...]

> As I mentioned before, you certainly have to do the "right thing" when
> it comes to doing arithmetic and conversions to other forms, but fixed
> point decimal arithmetic without packed decimal data types can be done
> without introducing any errors.
>
True. What you are doing is simply doing by hand what the compiler
would do, with a higher probability of introducing errors (fixed points
are tricky, believe me!).

It's OK if your language has no decimal fixed points. Otherwise,
it's more work without any benefit.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: float with 24-bit resolution

[Randy Brukardt]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:bj40b.59$yQ3.11@newsread1.news.atl.earthlink.net...
>
> "Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
> news:3f405ef4$1_1@news.tm.net.my...
> >
> > But subtracting the value of Angle_Delta makes the code more
> > understandable, doesn't it? That translates to -360.0000000 ..
> +359.9999571.
>
> No, it does not.  The practice of subtracting off T'Small from the upper
> bound in the type declaration is distracting, and only adds unecesssary
> noise.  The language is the way it is, so don't fight it.

Bull. :-)

The phony declaration of the upper bound is confusing to the reader; users
should not take advantage of this "convinience". Consider:

    Limit : constant := 360.0;
    The_Small : constant := Limit / 2.0**23;
    type Matts_Type is delta The_Small range -Limit .. Limit;
    Obj : Matts_Type;
    if Matts_Type'Last /= Limit then
        Put_Line ("Yep, the specified limit wasn't used");
    end if;
    Obj := Limit; -- Raises Constraint_Error!

The last is likely to be mysterious during maintenance, even to be
knowledgable user.

    type Randys_Type is delta The_Small range -Limit+The_Small ..
Limit-The_Small;

does not suffer from that confusion, and is hardly any harder to read. (Note
that this "convinence" applies to both bounds of the fixed point type, and
fixed point types don't get the most negative value that integer types do.)

                        Randy.

Re: float with 24-bit resolution

[Adrian Hoe]

Randy Brukardt wrote:
> "Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
> news:bj40b.59$yQ3.11@newsread1.news.atl.earthlink.net...
> 
>>"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
>>news:3f405ef4$1_1@news.tm.net.my...
>>
>>>But subtracting the value of Angle_Delta makes the code more
>>>understandable, doesn't it? That translates to -360.0000000 ..
>>
>>+359.9999571.
>>
>>No, it does not.  The practice of subtracting off T'Small from the upper
>>bound in the type declaration is distracting, and only adds unecesssary
>>noise.  The language is the way it is, so don't fight it.
> 
> 
> Bull. :-)
> 
> The phony declaration of the upper bound is confusing to the reader; users
> should not take advantage of this "convinience". Consider:
> 
>     Limit : constant := 360.0;
>     The_Small : constant := Limit / 2.0**23;
>     type Matts_Type is delta The_Small range -Limit .. Limit;
>     Obj : Matts_Type;
>     if Matts_Type'Last /= Limit then
>         Put_Line ("Yep, the specified limit wasn't used");
>     end if;
>     Obj := Limit; -- Raises Constraint_Error!
> 
> The last is likely to be mysterious during maintenance, even to be
> knowledgable user.
> 
>     type Randys_Type is delta The_Small range -Limit+The_Small ..
> Limit-The_Small;

"-Limit+The_Small .. Limit-The_Small" does not comply to my requirement 
which the angle must be in -360.0000000 to +359.9999571.

> does not suffer from that confusion, and is hardly any harder to read. (Note
> that this "convinence" applies to both bounds of the fixed point type, and
> fixed point types don't get the most negative value that integer types do.)
> 
>                         Randy.
> 
> 
> 
> 
> 

Re: float with 24-bit resolution

[Matthew Heaney]

Adrian Hoe <mailbox@adrianhoe.nospam.com.my> writes:

> Randy Brukardt wrote:
> > 
> >     type Randys_Type is delta The_Small range -Limit+The_Small ..
> > Limit-The_Small;
> 
> "-Limit+The_Small .. Limit-The_Small" does not comply to my requirement 
> which the angle must be in -360.0000000 to +359.9999571.

I didn't understand Randy's comment.  As far as I know, the correction
for T'Small is only necessary for the upper bound, not the lower bound
(unless this is a 1's complement machine).

Randy and I disagree about who should make the correction: the compiler
or the developer.  I argue that the compiler should do it, but Randy
finds this confusing.  YMMV.

Either of the angle types defined in my post and in Simon Wright's post
should work fine.  Both include -360 in the range of the subtype.

This issue is not unlike another convention some programmers use for
initializing access objects to null:

declare
   type T is access all Integer;

   Null_Object : T; 
   --vs--
   Null_Object : T := null;
begin

I prefer the former to the latter, because the former emphasizes that
the compiler is doing some work for me.

I find the latter convention confusing, because it suggests that if the
initialization part were omitted, then the object wouldn't be
initialized.  But that would be incorrect.

Re: float with 24-bit resolution

[Simon Wright]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

>    Null_Object : T := null;

> I find the latter convention confusing, because it suggests that if
> the initialization part were omitted, then the object wouldn't be
> initialized.  But that would be incorrect.

What it says to me is that the programmer isn't all that used to the
language; so I go on newbie alert (painful)

Re: float with 24-bit resolution

[Randy Brukardt]

> Matthew Heaney <matthewjheaney@earthlink.net> writes:
>
> >    Null_Object : T := null;
>
> > I find the latter convention confusing, because it suggests that if
> > the initialization part were omitted, then the object wouldn't be
> > initialized.  But that would be incorrect.

*I* find
     Null_Object : T;
confusing. A maintenance programmer probably doesn't know the class of
object that T represents, and the lack of an initialization looks like a
bug. You could "fix" that with a comment, but an explicit initializer works
just as well. (The lack of "constant" is also suspicious here; if the object
is a variable, it probably shouldn't be named "Null anything", because it
could change.)

After all, I often have:
    Null_Object : constant T := ...;
in my programs, where T could be any type.

If the object is a variable, it probably ought to be initialized with
something useful.

But I suspect being consistent is more important than any particular rule.

                   Randy.

Re: float with 24-bit resolution

[Randy Brukardt]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uwucq4kdz.fsf@earthlink.net...
> Adrian Hoe <mailbox@adrianhoe.nospam.com.my> writes:
>
> > Randy Brukardt wrote:
> > >
> > >     type Randys_Type is delta The_Small range -Limit+The_Small ..
> > > Limit-The_Small;
> >
> > "-Limit+The_Small .. Limit-The_Small" does not comply to my requirement
> > which the angle must be in -360.0000000 to +359.9999571.
>
> I didn't understand Randy's comment.  As far as I know, the correction
> for T'Small is only necessary for the upper bound, not the lower bound
> (unless this is a 1's complement machine).

You're right. That was an Ada 83 failing which was corrected in Ada 95 (see
3.5.9(12). It's interesting that the AARM doesn't mention the change from
Ada 83. Perhaps it was an Ada 83 AI; I know we had to modify our compiler to
use a symetric range in order to pass validation.).

                 Randy.

Re: float with 24-bit resolution

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]


"Randy Brukardt" <randy@rrsoftware.com> a �crit dans le message de news:vld62odqnfei2d@corp.supernews.com...
> > Matthew Heaney <matthewjheaney@earthlink.net> writes:
> >
> > >    Null_Object : T := null;
> >
> > > I find the latter convention confusing, because it suggests that if
> > > the initialization part were omitted, then the object wouldn't be
> > > initialized.  But that would be incorrect.
>
> *I* find
>      Null_Object : T;
> confusing. A maintenance programmer probably doesn't know the class of
> object that T represents,

I understand that concern, but it vanishes with reasonable identifiers:

Null_Object : String_Pointer;

OK for you?
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: float with 24-bit resolution

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:6u27jb.6e.ln@skymaster...
>
> "Randy Brukardt" <randy@rrsoftware.com> a �crit dans le message de
news:vld62odqnfei2d@corp.supernews.com...
> > > Matthew Heaney <matthewjheaney@earthlink.net> writes:
> > >
> > > >    Null_Object : T := null;
> > >
> > > > I find the latter convention confusing, because it suggests that if
> > > > the initialization part were omitted, then the object wouldn't be
> > > > initialized.  But that would be incorrect.
> >
> > *I* find
> >      Null_Object : T;
> > confusing. A maintenance programmer probably doesn't know the class of
> > object that T represents,
>
> I understand that concern, but it vanishes with reasonable identifiers:
>
> Null_Object : String_Pointer;
>
> OK for you?

Not really, unless your organization has very strong naming conventions. (We
don't; I tried to enforce some naming conventions with Claw, but that was
only partially successful.)

Certainly, I have some "virtual pointer" types that are really integers or
private types, and these need to be initialized. (Even if a private type is
implemented as an access type, you still ought to explicitly initialize it,
because otherwise you're depending on the private definition, which may
change.)

If Ada had a way to specify a default value for a (sub)type, I would be
happy to omit the initializer. (Or if flow shows that it is certain to be
initialized.) But, given the current language, that is often not a good
idea.

                         Randy.

Re: float with 24-bit resolution

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

>>Matthew Heaney <matthewjheaney@earthlink.net> writes:
>>
>>>   Null_Object : T := null;
>>
>>>I find the latter convention confusing, because it suggests that if
>>>the initialization part were omitted, then the object wouldn't be
>>>initialized.  But that would be incorrect.
> 
> *I* find
>      Null_Object : T;
> confusing. A maintenance programmer probably doesn't know the class of
> object that T represents, and the lack of an initialization looks like a
> bug. 

IMHO, if this is in fact a tagged "object", and it lacks
the necessary "Initialize" primitive, then you deserve
what you get. ;-) Granted, there can always be exceptions
to any rule. 8-)

Even for just record types, you can have implicit
initialization already specified for the members of
that record anyway. So you don't always want to undo
that with an explicit initialization.

So IMHO, saying that any object is better with explicit
initialization is saying that implicit initialization is
a part of the language which shouldn't be used.

Maybe, I am over reacting 8-)

> You could "fix" that with a comment, but an explicit initializer works
> just as well. 

But this also increases the maintenance cost if you change
the nature or number of members of that object. It also
creates a maintenance nightmare if the initialization
defaults are changed (in the spec) but the explicit
initialization undoes what is "correct" for it initially
(ie. the worst case is when it compiles, but fails to
work correctly because the incorrect initialization
value remains, even though the spec has been corrected).

> But I suspect being consistent is more important than any particular rule.
> 
>                    Randy.

But I guess this is what makes I.T. so interesting -- a
different set of strokes for many of us ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: float with 24-bit resolution

[Randy Brukardt]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:_x36b.22730$su.613585@news20.bellglobal.com...
> Randy Brukardt wrote:
> > You could "fix" that with a comment, but an explicit initializer works
> > just as well.
>
> But this also increases the maintenance cost if you change
> the nature or number of members of that object. It also
> creates a maintenance nightmare if the initialization
> defaults are changed (in the spec) but the explicit
> initialization undoes what is "correct" for it initially
> (ie. the worst case is when it compiles, but fails to
> work correctly because the incorrect initialization
> value remains, even though the spec has been corrected).

If your project has "visible" (i.e. non-private) record types where the
components can change, it has maintenance problems to begin with.
Initializers are the least of your problems. Inside the package,
initialization should always be done with aggregates (exactly so that missed
changes cause compile-time errors).

The problem here is the inconsistence of the language. Some types can be
implicitly initialized, and others cannot. That makes problems for private
types (because if you assume that they are implicitly initialized, you are
breaking privateness and/or significantly restricting the implementation (to
records and access types only). On the other hand, limited types can only be
initialized implicitly (that probably will change in Ada 200Y). Thus, it is
impossible for any rule to be completely consistent.

I do use implicit initializers in some cases (especially for limited types,
where nothing else is possible). But I prefer to make it explicit when
possible (generally reserving implicit initialization to marking an object
as "not valid").

                       Randy.

Re: float with 24-bit resolution

[Warren W. Gay VE3WWG]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vlhpbhsvhh5564@corp.supernews.com...
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:_x36b.22730$su.613585@news20.bellglobal.com...
> > Randy Brukardt wrote:
> > > You could "fix" that with a comment, but an explicit initializer works
> > > just as well.
> >
> > But this also increases the maintenance cost if you change
> > the nature or number of members of that object. It also
> > creates a maintenance nightmare if the initialization
> > defaults are changed (in the spec) but the explicit
> > initialization undoes what is "correct" for it initially
> > (ie. the worst case is when it compiles, but fails to
> > work correctly because the incorrect initialization
> > value remains, even though the spec has been corrected).
>
> If your project has "visible" (i.e. non-private) record types where the
> components can change, it has maintenance problems to begin with.
> Initializers are the least of your problems. Inside the package,
> initialization should always be done with aggregates (exactly so that missed
> changes cause compile-time errors).

Well, I suppose when I use tagged types, the internals are usually
private, so I generally don't run into this. However, I would suggest
IMHO, that even the public components are much better initialized
(at least by default) based upon the designer's original intent
(ie. in the spec.)  OTOH, if the members are public, then it
is open to some question about how the members should be used 8-)

In my mind it comes down to the simple engineering practice that
you centralize things that are subject to change. This is why
things like an error code are generally defined in one place.
Sure I could define that same constant everywhere else, and
make it the same initially, but it is a maintenance nightmare
later when that value changes. Even worse if it can change, but
still compile and go unnoticed until something fatal happens.
The same principle holds for record member initialization.

So I maintain that unless you have a good reason to override
the default initialization, it is better left alone.

> The problem here is the inconsistence of the language. Some types can be
> implicitly initialized, and others cannot. That makes problems for private
> types (because if you assume that they are implicitly initialized, you are
> breaking privateness and/or significantly restricting the implementation (to
> records and access types only). On the other hand, limited types can only be
> initialized implicitly (that probably will change in Ada 200Y). Thus, it is
> impossible for any rule to be completely consistent.
>
> I do use implicit initializers in some cases (especially for limited types,
> where nothing else is possible). But I prefer to make it explicit when
> possible (generally reserving implicit initialization to marking an object
> as "not valid").
>
>                        Randy.

Explicit initialization is similar in principle to a non-normalized
database. You have duplication of information, when the initialized
values are the same. Normalized database designs are preferred (though
not always achieved in practice).

Conversely, normalization of data means that your data is centralized.
This centralizes your "maintenance" and ensures that if you change that
value that you have got it correct everywhere else that it is needed.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: float with 24-bit resolution

[Dmitry A. Kazakov]

On Fri, 5 Sep 2003 14:37:12 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>The problem here is the inconsistence of the language. Some types can be
>implicitly initialized, and others cannot.

I think that the language should not allow implicitly uninitialized
objects. Things like:

X : Integer;

should be made illegal. There should be some syntax sugar to state
that the above is exactly what the programmer wants:

X : Integer := <>; -- OK, that's your problem now

With implicit initialization of some types, code readers have a
puzzle:

X : Foo; -- is that initialized or not?

Should he read specifications to figure out?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de