Version 1.4 of ais/ai-00125.txt

Unformatted version of ais/ai-00125.txt version 1.4
Other versions for file ais/ai-00125.txt

!standard 13.03 (55)          00-07-12 AI95-00125/04
!class confirmation 96-04-04
!status Response 2000 00-01-25
!status WG9 approved (8-0-0) 97-07-04
!status ARG approved (6-0-1) 97-04-11
!status work item 96-04-04
!status received 96-04-04
!priority Medium
!difficulty Medium
!qualifier Clarification
!subject Order of Size and Small clauses for fixed point types
!summary
A Size clause does not determine the values of an ordinary fixed point type. The values are determined either by the implementation, or by a Small clause; the legality of a Size clause is determined in part by the values chosen.
!question
Consider:
type Two_Bits_Spare is delta 4*System.Fine_Delta range -1.0..+1.0; for Two_Bits_Spare'Size use Size_For_Fine_Delta - 2; -- Legal? (Maybe.)
where Size_For_Fine_Delta is the number of bits needed for a type whose delta is Fine_Delta. Does the Size clause force the implementation to choose the small of the type such that only Size_For_Fine_Delta - 2 bits are needed? (No.)
13.3(55) says that 'Size should/must be "the number of bits needed to represent each value belonging to the subtype ..." and that an implementation should/must support a specified 'Size for a first subtype that reflects this representation.
3.5.9(8) says "the set of values of a fixed-point type comprise[s] the integral multiples of a number called the small of the type" which if not specified "is an implementation-defined power of two ..."
!response
A Size clause does not determine the values of an ordinary fixed point type. The values are determined either by the implementation, or by a Small clause; the legality of a Size clause is determined in part by the values chosen.
Since there is no Small clause in the above example, 3.5.9(8) allows the implementation to choose among various powers of two as the small, and the small determines what the values of the type are. A Size clause is required to specify enough bits to represent all those values. Thus, the Size clause in the above example is legal if the implementation chooses small to be 4*System.Fine_Delta, but is illegal if the implementation chooses small to be System.Fine_Delta.
!ACATS test
Since the example in question does not determine any behavior, no useful ACATS test can be written.
!appendix

!section 13.3(55)
!subject Fixed-point'Size
!reference RM95-13.3(55)
!reference RM95-3.5.9(8)
!from Dan Lehman 96-02-26
!keywords values
!reference 96-5431.a Dan Lehman 96-2-26>>
!discussion

There is a chicken-&-egg problem with the 'Size of a fixed-point subtype
(that is a first subtype):

     13.3(55) says that 'Size should/must be "the number of bits
     needed to represent each value belonging to the subtype ..."
     and that an implementation should/must support a specified 'Size
     for a first subtype that reflects this representation;
  but
     3.5.9(8) says "the set of values of a fixed-point type comprise[s]
     the integral multiples of a number called the small of the type"
     which if not specified "is an implementation-defined power of two ..."

Must a user specify 'Small before specifying 'Size for a fixed-point type?

---Dan
------- *

****************************************************************

!section 13.3(55)
!subject AI-125/00: Order of Size and Small Clauses for Fixed Point Types
!reference RM95-13.3(55)
!reference RM95-3.5.9(8)
!from Dan Lehman 96-08-21
!keywords values
!reference 96-5632.a Dan Lehman 96-8-20>>

In AI-125/00, the response that is written--to wit:

  !response 96-04-04

  The Size clause and Small clause must both specify static values (see
  13.3(41), 3.5.10(2)).  Therefore, the compiler should have no trouble
  checking that they are consistent with each other, no matter which order
  they appear in.

misses the point of my question in this AI, which is How may 'Size be
specified (in general) for a fixed-point type, since the 'Size must allow
for all *values of the type* and these are determined by the implementation
(according to the 'Small it selects)?  (In the case where both attributes
are specified, the user should know what to expect.)

The implication of the !response is that the 'Size clause determines the
values of the fixed-point type (though nothing in the RM about this clause
gives the impression that it has such power).  Consider the declarations:

  type Two_bits_spare is delta 4*System.Fine_Delta range -1.0..+1.0;
   for Two_bits_spare'Size use <Fine_Delta-implied 'size> - 2;

By 3.5.9(8) the implementation may chose Fine_Delta to be the 'small of the
type, which requires the full "<Fine_Delta-implied 'size>", of course, and so
would make the 'Size clause illegal.  But I presume that this is really not
an intended consequence!?  Thus, 13.3(55) carries a strong Ada83 presumption
of *coarsest-small* values.

---Dan Lehman
-------------- *

****************************************************************

!section 13.3(55)
!subject AI-125/00: Order of Size and Small Clauses for Fixed Point Types
!reference RM95-13.3(55)
!reference RM95-3.5.9(8)
!reference 96-5632.a Dan Lehman 96-8-20
!from Bob Duff
!reference 96-5657.a Robert A Duff 96-8-27>>
!discussion

> In AI-125/00, the response that is written--to wit:
>
>   !response 96-04-04
>
>   The Size clause and Small clause must both specify static values (see
>   13.3(41), 3.5.10(2)).  Therefore, the compiler should have no trouble
>   checking that they are consistent with each other, no matter which order
>   they appear in.
>
> misses the point of my question in this AI,

Yes.  I wrote that draft response, and I agree that I missed your point.

>...which is How may 'Size be
> specified (in general) for a fixed-point type, since the 'Size must allow
> for all *values of the type* and these are determined by the implementation
> (according to the 'Small it selects)?  (In the case where both attributes
> are specified, the user should know what to expect.)
>
> The implication of the !response is that the 'Size clause determines the
> values of the fixed-point type (though nothing in the RM about this clause
> gives the impression that it has such power).

The !response just says you can give both a Size clause and a Small
clause, and if you do, you can give them in either order.  I think
that's true, and should be true (although it wasn't exactly what you
were asking).

It seems to me that a Size clause should not affect the values of the
type.  I'm not sure how the current draft implies otherwise, but ...

>...  Consider the declarations:
>
>   type Two_bits_spare is delta 4*System.Fine_Delta range -1.0..+1.0;
>    for Two_bits_spare'Size use <Fine_Delta-implied 'size> - 2;
>
> By 3.5.9(8) the implementation may chose Fine_Delta to be the 'small of the
> type, which requires the full "<Fine_Delta-implied 'size>", of course, and so
> would make the 'Size clause illegal.

Right.  It seems to me that in this case, it is implementation-defined
whether or not the Size clause is legal.  Since there is no Small
clause, the implementation is free to choose various powers of two,
which means that the Size clause might be enough for all the values, or
it might not.

If there were a Small clause, then that would determine the set of
values, and the above Size clause would be legal or illegal accordingly.
In this case, it doesn't matter which rep clause comes first, since the
expressions involved are static.

This implies that if you want a portable Size clause, you have to write
a Small clause also.

>...  But I presume that this is really not
> an intended consequence!?

Well, ..., what's the problem with it?  Yes, it makes Size clauses less
portable, but that doesn't seem so harmful.  It seems less harmful than
saying Size clauses affect the values of the type.  It's bad enough that
Small clauses affect the values of the type (while pretending to merely
affect "representation").

>...  Thus, 13.3(55) carries a strong Ada83 presumption
> of *coarsest-small* values.

NOTE: During the language design I argued against including fixed point
types in 13.3(55), on the grounds that fixed point just isn't important
enough of a feature to be placing extra requirements on it, that never
appeared in RM83.  Tucker argued that fixed point is represented in
essentially the same way as integers, and so the same rules should
apply.

Anyway, is what I said above acceptable?  If so, I'll produce a new
draft version of the AI that says so.  And unless somebody complains,
I'll leave the priority "medium", since I think the number of users
affected is *small*.

- Bob

****************************************************************

Questions? Ask the ACAA Technical Agent