Re: FIXED bug in Medidian 4.1.1?

[telesoft!kst@uunet.uu.net (Keith Thompson @pulsar)]

The following is a slightly edited version of an e-mail message I sent
to Robert Dewar.  In his response, he agreed that I was right and
suggested I post a correction.

In article <dewar.736096726@schonberg> dewar@schonberg.NYU.EDU (Robert Dewar) w
rites:
...
> When you give a fixed point declaration where the end points are not model
> numbers, it is not only allowed but *required* that the end points be
> excluded from the representable range. It is thus not only allowable, but
> required behavior that use of the end point values in this situation will
> cause Constraint_Error.
> 
> The Meridian compiler is behaving according to the RM, and thus the subject
> heading in this thread is incorrect, and the answer to the question mark at
> the end of it is NO! I would suggest that people reserve the use of the
> word bug, until they find out what is going on -- "Query regarding fixed
> point" would have been a more appropriate title for the original posting.

The range of the model numbers for a fixed-point type are multiples of
the 'Small.  They range from Fixed'Small * (-2**Fixed'Mantissa + 1) to
Fixed'Small * (2**Fixed'Mantissa + 1).  For a type with no 'Small
clause and with declared bounds -1.0 .. 1.0, the upper bound will be
1.0 - Fixed'Small.  This is due to the phrase in LRM 3.5.9:6, "... each
bound of the specified range is either a model number or lies *at most*
small distant from a model number."  (This phrase happens to be one of
my pet peeves about the language, but that's another issue.)

I don't think the statement end points that are not model numbers are
*required* to be excluded from the representable range is correct.  The
exclusion of a end point from the set of model numbers applies only if
the end point is a power of two times the 'Small.  Also, the model
numbers don't necessarily match the representable range.  If a
fixed-point type doesn't fill an entire machine word, the remaining
bits can be used for either extra range or extra precision.  The extra
range may not be useful other than for intermediate results, though,
due to checks for Constraint_Error.

Also, based on the description in the original article, the Meridian
compiler doesn't seem to be behaving legally.  The declared fixed-point
type was

   type FLAKEY is delta 0.01 range 0.15 .. 3.0;

Note that the model numbers defined by this fixed-point are -3.9921875
.. +3.9921875 (-511/128 .. +511/128).  The range constraint imposes
bounds of Flakey'First .. 3.0 on the subtype, where Flakey'First is the
result of converting 0.15 to Flakey.  This can be either 0.1484375 or
0.15625, the nearest model numbers below and above 0.15 (or any value
between, if the implementation allocates extra bits for precision).
The error message implies that they're using 0.1484375.

The reported problem was that Fixed_IO.Get on values between 0.15
and 0.99 was causing the error "Value 0 out of range 19 .. 384".
The bounds given in the error message imply that, given the required
Flakey'Small of 1.0/128.0, the represented bounds are 0.1484375 ..  3.0.
The problem seems to be that Meridian's Fixed_IO is misinterpreting the
entered values as 0.0.

> Meanwhile, follow these simple suggestions for avoiding running into problems
> with fixed-point.
> 
>  1.  Always make the end point values a multiple of the declared delta value

A good idea, but even this won't always guarantee that the declared
bounds are representable.

>  2.  If the declared delta is not a power of 2, always put in a small
>      declaration, of the form:
> 	   for Fixed_Type'Small use 0.01;

Also a good idea in general.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com (kst@telesoft.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people!  We must stick them with quills -- it's the only way!"