From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 3 May 93 13:50:16 GMT From: 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) Subject: Re: FIXED bug in Medidian 4.1.1? Message-ID: List-Id: In article 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