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: Mon, 5 Jun 95 12:00:08 EDT From: tynor (Steve Tynor) Subject: PELKS-8 To: nice-esg-libs, nice-board Fellow Eiffelists, We have just finished a review of PELKS-8 in order to verify that the changes we agreed to have been reflected in the document. I'm happy to say that, except for the following points, PELKS-8 reflects what Tower, ISE and SiG agreed to amongst themselves. While we agree with PELKS in principle, there are a handful of details which must be addressed, but the Board's hasty vote on the issue did not give us time to raise them. We realize that time was of the essense, but we think a bad precedent is being set with the Board adopting the standard before the Committee has even had a chance to endorse it. We sympathize with those who have expressed reluctance to approve changes which have not been discussed in committee. Even so, we are willing to endorse PELKS-8 (as long as the modifications we outlined here are adopted). We recognize that serious discussions need to continue and that changes to the standard are inevitable. We hope that these negotiations outside of the committee have been a one time abberation of the process. What Tower is prepared to endorse ---- ----- -- -------- -- ------- The document that Tower endorses is PELKS-8 with the following modifications (in increasing order of importance): - The comment about default values not being hashable be removed from the indexing clause in HASHABLE (this appears to be a typographical oversight). - FILE's `to_next_line' be renamed as `skip_to_next_line' (Bertrand implied that this name was subject to change, and at least one committee member has endorsed this new name). - `to_pointer' is removed from STRING and ARRAY (in response to Bertrand's request from yesterday). - Either: - infix "^" is modified to have the following signature (and `exponentiable' is changed to `invertable'): infix "^" (exp : INTEGER) : like Current -- Raise Current to `exp'-th power require valid_exponent: exp >= 0 or invertable invertable : BOOLEAN -- Does multiplicative inverse of `Current' exist? - or, infix "^" and `exponentiable' are removed from NUMERIC and its heirs. [ We obviously favor the former. We had understood this to have been agreed to in our negotiations with ISE and SiG. See our rationale below. In case it's not obvious from the rationale, Tower cannot implement the PELKS version. ] Rationale for change to infix "^" --------- --- ------ -- ----- --- 1. a. For all types T descending from NUMERIC, it is valid to raise value v of type T to a nonnegative integral power. b. For all types T, descending from NUMERIC, there exists values v of type T for which it is valid to raise v to a negative integral exponent. Those values v which cannot be raised to a negative exponent are non-invertable. Invertability and testing for it are well known concepts. Invertability is only a function of the value v, it does not involve the exponent. c. There exist common descendents of NUMERIC (SQUARE_MATRIX) for which no values of these types can be raised to non-integral powers. Furthermore the precondition for "^" (exponentiable) becomes more complex since it is a function of both the value v and the exponent in question. 2. It is possible to efficiently implement the feature "^" which takes INTEGER exponents in NUMERIC so that the feature does not have to be deferred. e.g.: infix "^" (exp : INTEGER) : like Current is -- Raise Current to `exp'-th power require valid_exponent: exp >= 0 or invertable local e : INTEGER; factor : like Current; do Result := one; factor := Current; from e := exp.abs; until e = 0 loop if (e \\ 2) = 1 then Result := Result * factor; end; e := e // 2; factor := factor * factor; end; if exp < 0 then Result := one / Result; end end; 3. Programmers doing mathematical calculations expect "^" to be efficient. If it is defined in terms of reference types (NUMERIC), then compilers are forced to generate "reference equivalent" promotion (which is inherently inefficient), or even worse, to "special case" an optimization to avoid one. [This ignores the "implementability" issues associated with reference->expanded redefinition outlined in point #5]. 4. In PELKS, integer exponentiation (e.g. 2^16) results in a floating point result which must then be truncated in order to get the desired INTEGER result -- it is difficult to imagine a case where a programmer would actually desire a floating point value from such an expression. 5. The current form of "^" in NUMERIC takes an argument of type NUMERIC and returns NUMERIC (a reference type). [NOTE: this is an instance of the VIP issue #13]: In INTEGER, "^" takes a NUMERIC and returns DOUBLE. There are two problems with this. First, raising an integer to an integral power (a rather common operation) requires promoting the exponent to a reference equivalent. Secondly, it is unclear how to efficiently implement the redefinition of a return type from reference to expanded (or basic type). In INTEGER we are redefining the return type from NUMERIC to DOUBLE. In common implementations, DOUBLE has different size (8 bytes vs 4) and semantics (reference vs expanded) than NUMERIC. Given the redefinition of return type from NUMERIC to DOUBLE, when invoking "^" on a NUMERIC object how is the receiver supposed to know whether the returned value is a reference or a DOUBLE? REAL suffers from the same problems as INTEGER DOUBLE's "^" takes like Current and returns like Current (effectively DOUBLE and DOUBLE). Here both the parameter and return type have been redefined from a reference (NUMERIC) to a basic type (DOUBLE) the same problem applies. Why does DOUBLE's "^" take like Current and INTEGER and REAL's "^" take NUMERIC? [This is summarized in point #6 below]. By using INTEGER as the argument type and like Current for the Result type for "^" in NUMERIC, these problems are avoided. Classes such as DOUBLE and REAL that need to raise values to non-integral exponents can introduce a new feature that does just that. This solution is also consistent with the approach taken with integer and real division in PELKS. 6. (Though this does not serve as rationale for why our proposed design is "better", we note that the various definitions of "^" in PELKS are inconsistent. The verious redefinitions in INTEGER, REAL and DOUBLE are not redefined consistently - it would help us to know which style of redefinition was intended for PELKS): NUMERIC: infix "^" (exp : NUMERIC): NUMERIC DOUBLE: infix "^" (exp : like Current): like Current INTEGER: infix "^" (exp : NUMERIC): DOUBLE REAL: infix "^" (exp : NUMERIC): DOUBLE Why should raising a REAL to a power result in a DOUBLE? If the user is doing single-precision math, why would he want to have some of his arithmetic changed to double-precision? Why is DOUBLE defined in terms of like Current, but the others in terms of NUMERIC and DOUBLE? Fred Hart Steve Tynor
