comp.lang.ada
 help / color / mirror / Atom feed
From: Keith Thompson <kst-u@mib.org>
Subject: Re: How unchecked conversion works?
Date: Fri, 14 Jan 2005 22:27:39 GMT
Date: 2005-01-14T22:27:39+00:00	[thread overview]
Message-ID: <lnbrbrejdw.fsf@nuthaus.mib.org> (raw)
In-Reply-To: 0NSFd.2$Lz6.0@dfw-service2.ext.ray.com

Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> None wrote:
>
>> well, I try to explain. I have those types for example
>> type fixed is delta 0.03 range -90.0..90.0
>> for fixed'size use 16
>> and
>> type inte is range -32768..32767
>> for inte'size use 16
>> and a new function that renames unchecked_conversion to come from
>> fixed to inte (probably an inefficient way, but I have to do this
>> way), so I'd like to predict on paper which value of inte type
>> corresponds to 89.09 for example: what kind of calculus should I do?
>> This depends on something else? Thanks again!

There's no reason to expect that Unchecked_Conversion would be
inefficient.  It's generally implemented as a no-op that overrides
type checking.

> The specific answer will likely be compiler specific so you may need
> to write a test application to verify the result. Let me see if I can
> explain why...
>
> One choice - the compiler chooses to represent value as 1 == your
> delta value (0.03) and scale everything appropriately. Then 90.0 is
> represented by 3000 (decimal) since
>    3000 * 0.03 == 90.0
> So you have a range of values +/- 3000 when you do the unchecked
> conversion. Pretty straight forward implementation for your problem.
>
> Another choice - the compiler chooses to make 'Small of your datatype
> not equal to 'Delta of your data type (this IS allowed in ARM
> 3.5.9). Since you did not request a decimal fixed point value, 'Small
> will be a power of two smaller than 'Delta. If my arithmetic is
> correct, that could be something like 1/64 (0.015625) or even smaller
> (e.g., 1/256). In this case, the value could be mapped as follows:
>   Siiiiiiiffffffff
> where S is  the sign bit, iiiiiii is the 7 bit integer value and
> ffffffff is the 8 bit fraction. I assume you can do the appropriate
> arithmetic to interpret this form of fixed point value.

Actually, the language specifies that the "small" value for type fixed
will *not* be 0.03.  RM95 3.5.9p8 (with underscores to denote italics)
says:

    The set of values of a fixed point type comprise the integral
    multiples of a number called the _small_ of the type. For a type
    defined by an ordinary_fixed_point_definition (an _ordinary_ fixed
    point type), the _small_ may be specified by an
    attribute_definition_clause (see 13.3); if so specified, it shall
    be no greater than the _delta_ of the type. If not specified, the
    _small_ of an ordinary fixed point type is an
    implementation-defined power of two less than or equal to the
    _delta_.

So Fixed'Small is guaranteed to be a power of two no larger than 0.03.
The most likely value is probably 1.0/64.0 (0.015625) (since 1.0/32.0
is too large).

The "delta" is the precision you ask for; the "small" is the precision
you get.

You can find out what the actual "small" is by printing the value of
Fixed'Small.

If you really want Fixed'Small to be 0.03, you can specify it:

    for Fixed'Small use 0.03;

Assuming Fixed'Small = 1.0/64.0, the value 89.09 can't be represented
exactly.  You'll get either 89.078125 (5701.0/64.0) or 89.093750
(5702.0/64.0).  Doing an Unchecked_Conversion of that value to Inte
should give you either 5701 or 5702.

You may be able to achieve the same affect by dividing by Fixed'Small:

    F : constant Fixed := 89.09;
    I : constant Inte  := Inte(F / Fixed'Small);

A quick experiment shows that this works, but I'm not sure that it's
guaranteed.  There may be some rounding and/or overflow issues.  (It's
been a while; I don't remember the details.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.



  reply	other threads:[~2005-01-14 22:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 18:54 How unchecked conversion works? None
2005-01-13 21:22 ` Frank J. Lhota
2005-01-13 22:28 ` Keith Thompson
2005-01-14  0:17   ` Larry Kilgallen
2005-01-14 15:23 ` None
2005-01-14 15:55   ` Marius Amado Alves
2005-01-14 22:29     ` Keith Thompson
2005-01-14 23:15       ` Marius Amado Alves
2005-01-15  1:27         ` Keith Thompson
2005-01-15  2:15         ` Larry Kilgallen
2005-01-15 10:24           ` Marius Amado Alves
2005-01-15 12:02             ` Larry Kilgallen
2005-01-15 16:54               ` Nick Roberts
2005-01-16 16:14                 ` Larry Kilgallen
2005-01-16 16:41                   ` Jeffrey Carter
2005-01-16 20:52                     ` TCSEC security levels [was: How unchecked conversion works?] Nick Roberts
2005-01-17 15:57                       ` Larry Kilgallen
2005-01-17  0:34                     ` How unchecked conversion works? Larry Kilgallen
2005-01-17  1:29                       ` Jeffrey Carter
2005-01-17  4:20                         ` Larry Kilgallen
2005-01-15 18:24             ` Jeffrey Carter
2005-01-14 16:52   ` Mark H Johnson
2005-01-14 22:27     ` Keith Thompson [this message]
2005-01-14 22:49   ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox