!standard 04.05.05(20) 03-12-04 AI95-00364/00

!class amendment 03-12-04

!status received 03-09-29

!priority Medium

!difficulty Hard

!subject Fixed-point multiple/divide

!class amendment 03-12-04

!status received 03-09-29

!priority Medium

!difficulty Hard

!subject Fixed-point multiple/divide

!summary

!problem

!proposal

!wording

!discussion

!example

--!corrigendum

!ACATS test

ACATS test(s) should be constructed to check these changes.

!appendix

From: Tucker Taft Sent: Monday, September 29, 2003 10:53 PM I indicated I had a solution for the ada 95/ada 83 incompatibility relating to fixed-point multiply/divide, where user-defined multiply are not usable because of the "pervasive" visibility of the universal-fixed multiply/divide operations. After taking a shot at defining the universal-access equality operators in standard, it became obvious that there is a simple fix for the universal-fixed incompatibility. Just have a name-resolution rule which forbids use of the universal-fixed operations if both operand types have at least one primitive user-defined multiply operator, in the case of the univ-fixed multiply op, or both have at least one primitive user-defined divide operator in the case of the univ-fixed divide op. This doesn't have any beaujolais effects, because it isn't a preference rule. Just certain fixed-point type combinations can't be used with the universal-fixed multiply/divide operators, based strictly on whether they both have their own primitive multiply/divide operators. [I phrased the suggested rule as requiring "both" to have a user-defined primitive operator, but it could be phrased as "either." ] By the way, this isn't totally hypothetical. At one point we definitely dealt with a customer who was trying to figure out how to get their old Ada 83 fixed-point code to work, and the answer was not pretty. Basically they had to use non-operator functions like "mul" and "div", and live with the fact that they couldn't prevent misuse of the predefined univ-fixed operators. **************************************************************** From: Robert Dewar Sent: Monday, September 29, 2003 10:55 PM We have run into similar situations. I like this fix. I think it is worth while. In fact I would suggest allowing Ada 95 compilers to do this right away, why not? **************************************************************** From: Robert I. Eachus Sent: Tuesday, September 30, 2003 3:45 PM Tucker said: > This doesn't have any beaujolais effects, because it isn't > a preference rule. Just certain fixed-point type combinations > can't be used with the universal-fixed multiply/divide > operators, based strictly on whether they both have their > own primitive multiply/divide operators. First let me say that this problem is MUCH more serious than potential beaujolais effects. A good solution now should be preferred to continuing to look for a perfect solution. There may be a clean and easy to implement solution without beaujolais effects. If so great. But a preference rule NOW would be great too. > [I phrased the suggested rule as requiring "both" to have > a user-defined primitive operator, but it could be > phrased as "either." ] There are three potential fixed-point types involved, two operands and a result. I think Tucker is talking about when the two operands both have user defined multiply or divide operations. I don't particularly care what the exact rule is though, as long as you get it defined for all cases. > By the way, this isn't totally hypothetical. At one > point we definitely dealt with a customer who was trying > to figure out how to get their old Ada 83 fixed-point code > to work, and the answer was not pretty. Basically they > had to use non-operator functions like "mul" and "div", > and live with the fact that they couldn't prevent misuse > of the predefined univ-fixed operators. I have/had some fielded Ada 83 code on one project where this one issue was enough to cause the project to stay with a "baselined" Ada 83 compiler. I don't know that the particular package ever got rewritten for Ada 95, but distance times sine returning distance, and (apparent) speed divided by cosine to give ground speed were two examples of where it was used in the code. ****************************************************************

Questions? Ask the ACAA Technical Agent