NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Tue, 13 Jun 95 10:06:18 EDT From: tynor (Steve Tynor) Subject: More exponentiation To: nice-esg-libs It's unfortunate that Michael's handful of somewhat less than diplomatic statements have overshadowed the rest of his argument, which I think was quite lucid and technically defendable. Allow me to summarize our design so that end users like Paul Dubois do not get the wrong impression that our design is less usable or that because it is based on solid (if seemingly abstract) mathematical principles, that it is somehow out of touch with the "real world". I'd like to remind those who concentrate on REAL and DOUBLE that NUMERIC will serve as more than a common ancestor to the INTEGER, DOUBLE and REAL classes: it is also the logical ancestor for all sorts of interesting numeric classes like square matrices, polynomials, rational numbers, "big nums" (infinite precision numbers), etc. We should strive for a design serves both purposes. In NUMERIC, the signature of "^" is : infix "^" (exp : INTEGER) : like Current require exp >= 0 or else invertible -- note spelling ensure not_void: Result /= Void consistent_neg: exp < 0 implies Result.is_equal(one / Current) ^ (-exp)) consistent_zero: exp = 0 implies Result.is_equal(one) consistent_pos: exp > 0 implies Result.is_equal((Current ^ (exp-1)) * Current) With this signature, one can write useful postconditions specifying precisely what it means to apply the exponentiation operator. (As Michael ably pointed out, no such assertions can be made about the ISE signature). These specifications hold for _all_ conceivable descendents of NUMERIC. That includes polynomials, square matrices, etc. Not just the real numbers. In fact, as I showed in my post last week, the body of "^" can actually be implemented efficiently in NUMERIC -- it need not be deferred! In NUMERIC, `invertible' is deferred. In INTEGER, it is defined to be `Current=1' (since a negative exponent makes no sense for integer exponentiation except for 1). In REAL and DOUBLE, `invertible' is redefined as `true' (since it is in fact possible to invert a floating point value and get a meaningful result). In classes REAL and DOUBLE (or more properly in their _REF equivalents), we propose to rename "^". This is directly analogous to the renaming of "/" to "//" in class INTEGER. Here, conventional notation expects "/" to return a DOUBLE, so the version inherited from NUMERIC is renamed "//" and a new division operator is introduced. Similarly, for "^", we have: infix "^" (exp : DOUBLE) : like Current and power (exp : INTEGER): like Current -- Renamed from "^" in NUMERIC So, an ex-Fortran programmer will feel right at home. He can write x^2 or x^3.3 or x^0.5. And we've not sacrificed a useful specification of "^" in the more general NUMERIC class. Q.E.D.? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This is my theory. That is to say, the theory which is mine. -- Anne Elk Steve Tynor Internet: Steve.Tynor@atlanta.twr.com Tower Technology UUCP: twratl!Steve.Tynor WWW: http://www.cm.cf.ac.uk/Tower/
