From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,751584f55705ddb7 X-Google-Attributes: gid103376,public From: John G. Volan Subject: Re: Side-effect arithmetic again [was: Ada ... in embedded systems] Date: 1996/03/27 Message-ID: <4jbrs2$2n2@dayuc.dayton.saic.com> X-Deja-AN: 144502303 distribution: world references: <4i6efq$dd9@dfw.dfw.net> <4j982l$cnh@usenet.srv.cis.pitt.edu> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-03-27T00:00:00+00:00 List-Id: In article Robert I. Eachus, eachus@spectre.mitre.org writes: > I felt that the range of Integer is large enough for most uses. >In general I expect this package to be used with 1) enumeration types >2) character types 3) loop indexes and 4) string indexes. Two points: - (2) is just a special case of (1). I could see your procedures going into something like the Discrete_Arithmetic package I described, but then I think the package ought to be called Enumeration_Arithmetic, to emphasize the intent that the actual Item type be an enumeration. - (3) and (4) might be enumerated types, but when they're integer types, they could be supported more simply and directly by the Integer_Arithmetic package I described. No need to mix things up by tying everything to Standard.Integer. > > Also, why limit Increment/Decrement to Positive? Why not allow any > > arbitrary integer? The C analogs for these procedures, += and -=, > > carry no such limitation. > > Shrug. I guess I could be convinced to Integer, but Inc(X, -1) >seems silly. If the following is legal in Ada: X := X + (-1); then why should we presume to stop a programmer from doing: Increase (X, By => -1); no matter how silly (we think) it is? And why do you assume that the second parameter to this procedure would always be a (small) integer _literal_? Given that you clearly are making that assumption, I can understand how it wouldn't really matter to you what type the second parameter was, so Standard.Integer is as good as anything. But this is what I mean by your focus being too narrow. Here's a (somewhat) realistic example that overturns your assumption: -- assume these are all the same type: Vertical_Acceleration := Gravity; -- happens to be negative (downward) Vertical_Velocity := ... ; -- could begin positive but ends up negative Altitude := ... ; ... while Altitude > 0 loop ... -- using a fast, but admittedly non-Newtonian, approximation, and -- assuming 1 unit (whatever that is) elapsed time between updates: Increase (Vertical_Velocity, By => Vertical_Acceleration); Increase (Altitude, By => Vertical_Velocity); ... end loop; Put_Line (">>CRUNCH!<<"); -- :-) the C equivalent being: Vertical_Velocity += Vertical_Acceleration; Altitude += Vertical_Velocity; Perhaps the words "Increase" and "Decrease" carry too much of a connotation of directionality. Perhaps we need better identifiers than these to convey the sense of what += and -= really do. Anybody have any suggestions? But on second thought, why isn't the second parameter on the "+" and "-" functions limited to Positive? Doesn't "addition" carry a sense of making a value "bigger" and "subtraction" carry a sense of making a value "smaller"? Yet, despite these connotations, does anybody have any trouble with the fact that you can _add_ a negative number and thereby generate a _smaller_ value, or _subtract_ a negative number and thereby generate a _bigger_ value? Or that you can add or subtract zero and get the same value? Does this make "+" and "-" harder to understand and less "readable"? Or have we all managed to internalize all these ideas? Well, if we can do that with "+" and "-", then what's the problem with transferring that understanding to "Increase" and "Decrease" (or whatever you want to call them)? Especially if we explain to new Ada students that "Increase" is related to "+" and "Decrease" is related to "-", so keep in mind everything you learned in junior-high algebra? (By the same token, why isn't the second parameter on "*" and "/" restricted to numbers greater than 1.0? Isn't multiplication supposed to "expand" a value while division "reduces" it? But if you apply a number between 0.0 and 1.0 (exclusive), the effects of these operations are the exact reverse. And, of course, multiplying or dividing exactly by 1.0 has no effect. But do these properties reduce the understandability or readability of "*" and "/"? "You may very well think so, but I could not possibly comment." -- Daniel Urquhart :-) [snip] >I left out the Min and Max also, but I now think the two >argument versions should go in, but the versions with array parameters >complicate things too much. Are we talking Ada83 here? If you mean Ada95, why reinvent the wheel? Aren't Item'Min and Item'Max adequate? Or did you mean: function Minimum_Of (This, That : in Item) return Item renames Item'Min; function Maximum_Of (This, That : in Item) return Item renames Item'Max; Or maybe you meant: procedure Minimize (This : in out Item; Against : in Item) is begin This := Item'Min (This, Against); end Minimize; procedure Maximize (This : in out Item; Against : in Item) is begin This := Item'Max (This, Against); end Maximize; As for array versions, well, there's a lot you could put into an Array_Arithmetic package, but let's not go overboard... :-) ... Hmm, I just realized that I missed a couple of operators. Maybe we should also include: procedure Negate (This : in out Item) is begin This := -This; end Negate; procedure Absolve (This : in out Item) is begin This := abs This; end Absolve; -- :-) Well, can you think of a better related verb? Of course, there's no C analog for these, but they do fit the pattern of avoiding an error-prone repetition of a long target variable name. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature ( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Humorous_Disclaimer => "These opinions are undefined by SAIC, so" & "any use would be erroneous ... or is that a bounded error now?" ); ------------------------------------------------------------------------