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 19:55:31 PDT From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: "^" To: NICE-ESG-Libs@atlanta.twr.com (From a message by Pierre-Olivier Nallet from ISE - slightly adapted.) What I understand about "power": 1 integer power: The definition of integer power is integer_power(i:INTEGER): ? require (i < 0) implies invertible ensure (i = 0) implies Result := One; (i > 0) implies Result := integer_power(i-1)*Current; (i < 0) implies Result := integer_power(i+1)/Current In the integer power, there is no notion of logarithm, only multiplication and division. 2 "exponential" power exponential_power (y: ???):??? is require exponentiable ensure Result = (y * (Current.ln)).exp `exponentiable' is also the precondition for `ln' to be applicable. (So maybe it is not the best possible name.) In class REAL, exponentiable means Current > Zero In class COMPLEX exponentiable means Current /= Zero If one writes x = rho * exp (i alpha Pi) ln(x) = ln (rho) +i alpha Pi (modulo 2 i Pi) Then: exponentiable is true if Current.modulus is defined, i.e. Current /= Zero and exponential_power is not ambiguous if y is INTEGER (One could say ln(1) = 2 i Pi Then (1).exponential_power(1,5) = (3* i* Pi).exp = -1 ) ----- End Included Message -----
Date: Mon, 5 Jun 95 14:34:59 PDT From: bertrand@vienna.eiffel.com (Bertrand Meyer) Subject: NICE-ESG-Libs Digest V1 #235 To: NICE-ESG-Libs-digest@atlanta.twr.com, NICE-ESG-Libs@atlanta.twr.com In response to Jason Schroeder: The library committee is not being asked to rubber-stamp anything. The work of the committee is to prepare the standard; approving it is the job of the Board. The work on the PELKS has been proceeding for almost a year. It is appropriate to start showing the first result to the outside world. Although Jason Schroeder may not agree with this view, an overwhelming majority of Eiffel users seem think that we need an officially sanctioned basis to start from - simply to record what IS common between the implementations, or what we agree should be changed soon. Everywhere I went during the past 6 months this was the unanimous message from users. This standard is a win-win situation. We have a common basis, which can only improve portability. And the library committee can do its work serenely for 96. -- BM
Date: Mon, 5 Jun 95 22:59:38 EDT From: tynor (Steve Tynor) Subject: Power issues To: nice-esg-libs Bertrand asked for clarification on why Tower argues that it cannot efficiently implement the power operator as defined in PELKS. The implementation difficulty is an instance of a more general difficulty which Michael Schweitzer first formalized over a year ago in the "Vendor Interoperability Program" (or VIP) as issue #13. Namely, that redefining an argument or return value from a reference type to an expanded type (or vice versa) cannot be compiled efficiently. This issue has been left unresolved. One possible resolution would be to modify the language to make such redefinitions illegal (as we understand it to be in all current implementations). In developing a response, we discovered that the definitions of the recently added "_REF" classes (REAL_REF, INTEGER_REF, etc.) are not legal Eiffel. They are effective classes, which have inherited deferred features (infix "+", infix "<", etc.) without effecting them. The details of our argument depend on the exact definition of these classes (e.g. are the argument and return values still references in the _REF classes, or are they redefined to DOUBLE already)? For this reason, we think you'll agree that there is insufficient time to come to an agreement about "^" before the announcement. Since we cannot agree, the only reasonable alternative is that "^" be removed from the standard and the issue taken up as a high priority item by the committee. This will allow time for the _REF classes to be properly defined. Fred Hart Steve Tynor
