Re: FIXED bug in Medidian 4.1.1?

Re: FIXED bug in Medidian 4.1.1?

[Ron Sercely]

In article <A9YCBYKQ@math.fu-berlin.de> dww@math.fu-berlin.de (Debora Weber-Wul
ff) 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.
>
>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 

I don't know "chapter and verse" on Meridian or fixed point numbers, but
suspect that you are seeing the following problem.

Fixed point numbers are internally represented with a delta this is a power of
2, unless a representation clause length clause is used to specify _small_.
What this means in your case, is that the internally generated delta is
0.0078125. (Which is 2**(-7), which is the largest power of 2 less than your
specified delta of 0.01).  Note also that 3/0.0078125=384, which your are
seeing in your error message.  The value 0.15 is not a model number,
specifically it is 19*0.0078125 + 0.0015625.  

I _suspect_ that the range is being converted to a range of the _model numbers_
which would mean that the minimum representable value is 0.15625.  Since
0.15 is less than that, the get is failing.  This is, I believe a bug.

Just to narrow things down, try things like:
 change the range,
 make both bounds model numbers,
 use the 'small attribute to set small to 0.01 and see if it helps.

I would warn you, fixed_io is often buggy with this kind of stuff.  Hope
this post helps.

Ron Sercely

Re: FIXED bug in Medidian 4.1.1?

[Robert Dewar]

Well I am not sure that this kind of tutorial is an appropriate use of
comp.lang.ada bandwidth (this sort of question about fixed point should be
dealt with in the FAQ, and then people referred there when they ask about it)
However, since there was a follow-up which was incorrect, it needs correcting.

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.

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

       
    2.  If the declared delta is not a power of 2, always put in a small
    2.
	declaration, of the form:


	   for Fixed_Type'Small use 0.01;

	      

        where the value is the same as the declared delta value. Your compiler

	may reject this representation clause, in which case it just can't

	handle this choice of delta. If it accepts it, then everything should

	work as expected. Put the Small declaration right after the fixed

	point declaration (this avoids some other curiosities that I don't

	want to describe in detail)

Re: FIXED bug in Medidian 4.1.1?

[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!"

Re: FIXED bug in Medidian 4.1.1?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!ira.u]

dewar@schonberg.NYU.EDU (Robert Dewar) writes:

>Well I am not sure that this kind of tutorial is an appropriate use of
>comp.lang.ada bandwidth (this sort of question about fixed point should be
>dealt with in the FAQ, and then people referred there when they ask about it)

That would be great to include this sort of question there, as there are
many confusing corners in Ada.
>
>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.

Can you please quote chapter and verse on that? I have tried *often*
to make sense of 3.5.9 - which paragraph encodes this requirement?
>
>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 th
e
>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.

Well, it *is* a bug, because when I use a length clause, I get
sensible answers, i.e. reading in 1.99 returns 1.99 and not 1.98,
but I still get a data_error "value 0 out of range 15..300" when
I enter any value from 0.15 (the lower bound) upto and including 0.99.
Any range that does not include 0.0 will raise this "error" upon
reading in a value with 0 before the decimal point. If I include
0.0, the construct works as expected. If this is not a bug, *please*
explain!
>
>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 valu
e

Well, we did. The delta was 0.01, and 0.15 is 15 times 0.01. 
>
>    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;

Okay, will do. What was the logic behind this - to make it easier to
use or to make it easier to compile?

As I mentioned in a private correspondence with you on this, Richard,
I'm just an old COBOL hacker that uses decimal representations for
many things. My students and I have been trying to program about
the height of a person in meters (thus the 0.15 .. 3.00, although
2.72 suffices, according to Guinness) and about interest calculation
in DM and pf. I'd been advised before to avoid FIXED if I don't
understand it, but I'm just pig-headed :-), if it's there I want
to use it and I want it to make sense :-) :-)

Anyway, thanks to all for the assistance provided.

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

Re: FIXED bug in Medidian 4.1.1?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!noc.n]

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

Re: FIXED bug in Medidian 4.1.1?

[Robert Dewar]

Tucker Taft shouldn't apologize for disagreeing with me when I am wrong!
I think his analysis is probably exactly correct, and it does indeed appear
that there is a bug.

Also, when I said that a compiler was required to excluded end-points that
are declared in some declarations, I didn't mean all declarations, just that
the rules do require such exclusion in some cases. This remains a mighty
peculiar feature to many programmers, who find it mysterious to get
a constraint error when they write:

	type x is delta x range y .. z;
	vx : x := y; -- ce raised here

We thought about trying to fix this in 9X, but decided against it (at least
according to my current understanding), because it would have introduced
subtle incompatibities, and not than many people use fixed point. The new
information systems annex *does* provide the necessary facilities, based on
use of a specialized form of fixed-point, for financial calculations.