Re: FIXED bug in Medidian 4.1.1?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!noc.n ear.net!inmet!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft)]

In article <A9YCBYKQ@math.fu-berlin.de> 
  dww@math.fu-berlin.de (Debora Weber-Wulff) writes:

>I've been having lots of trouble with FIXED for Meridian 4.1.1 (DOS),
>and have been told that it is complicated, but this is downright
>silly:
>
>If I define two types like this
>
>type OKAY is delta 0.01 range 0.0 .. 3.0;
>type FLAKEY is delta 0.01 range 0.15 .. 3.0;
>
>and instantiate put and get procedures from FIXED_IO I can
>get any OKAY value without trouble. Trying to get any FLAKEY
>value between 0.15 and 0.99 results in the error
>Value 0 out of range 19 .. 384
>I can enter any value between 1.0 and 3.0 of type FLAKEY without
>trouble. It seems that the leading 0 causes problems if 0
>is not in the defined range.

I hate to disagree with my esteemed colleague Prof. Dewar, but
this *is* a bug as far as I am concerned, and I would predict that
the cause of the problem is traceable to an attempt to implement
the generic package Fixed_IO in Ada itself.  This is difficult to do
(see below).

The easiest work-around, I suspect, is to separate out the specification
of the subrange of interest from the type declaration:

    type Flakey_Base is delta 0.01 range -10.0 .. 10.0;
    subtype Flakey is Flakey_Base range 0.15 .. 3.0;

and then instantiate Fixed_IO with Flakey_Base instead of
Flakey.  

The problem stems from the nature of fixed-point in Ada -- there
is no easily accessible "most accurate" fixed point type on
which to fall back for the Ada implementation of a generic package like 
Fixed_IO.  

For floating-point, it is relatively straightforward (if sometimes inefficient)
to implement Float_IO in Ada, by using the most accurate
floating point type, with a final conversion.
It turns out that for most targets, this same strategy works
well enough for Fixed_IO -- namely use the most accurate floating-point
type, and then convert to the user's fixed-point (sub)type at the end.

However, the more obvious implementation approach is to try to use the user's
fixed-point (sub)type directly in the implementation of Fixed_IO.  Since the
first-named subtype of your fixed-point type doesn't include 0, this makes
it very difficult to accumulate up the result in an object of such a (sub)type.

I suspect that is the "bug" in the implementation of Fixed_IO 
you are using.  The bottom line is that it is not easy to implement the
generic Fixed_IO in "pure" Ada.  Try it yourself, and perhaps
you will have a little more sympathy for the implementor.
But don't have so much sympathy that you fail to file the bug
report.  I am sure that Meridian will be interested in "fixing" (;-)
the problem.  Since fixed-point is used so rarely in the typical
Ada compiler, it is not surprising to me that they never had an
occasion to test it with a fixed-point type whose first-named
subtype does not include 0.0.

In Ada 9X, the 'Base attribute could be used to overcome this particular
problem in the implementation of the generic, but that attribute is
not allowed in a (sub)type-mark in Ada 83, making the implementation of
generics like Fixed_IO that much harder.

>The LRM is no help - what am I missing? Or is this a known
>bug? We just expanded our ranges to include 0.0, but that's
>not exactly the point of using Ada :-(

As mentioned above, you can work around this bug
by expanding the range of the first-named subtype to include 0.0, 
while still having the range of some other named subtype be smaller.

>Thanks for any help,
>
>Debora Weber-Wulff
>
>-- 
>Debora Weber-Wulff, Professorin fuer Softwaretechnik
>snail: Technische Fachhochschule Berlin, FB Informatik, 
>       Luxemburgerstr. 10, 1000 Berlin 65
>email: dww@informatik.tfh-berlin.dbp.de 

S. Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138