NICE-ESG-Libs Digest Mon, 5 Jun 95 Volume 1 : Issue 237
Today's Topics:
infix "^"
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 18:28:36 EDT
From: tynor (Steve Tynor)
Subject: infix "^"
To: NICE-ESG-Libs@atlanta.twr.com
Bertrand wrote:
| It is clear that we need two exponentiation operators: a general one
| and one for integer exponents. But the basic operator "^" should be
| for the general one. I can't see how to justify the use of a very general
| operator for what is defined as an optimization for special cases.
I think we have a disagreement about "generality". I argue that the
integer exponent version is the most general since it applies to _all_
conceivable heirs of NUMERIC and the algorithm can be defined there such
that it need not be defered. This follows from basic abstract math
principles. The non-integral version is in fact the "special case" as it
only applies to a subset of the heirs of NUMERIC, namely "real
numbers". (I've never seen an example of another use of the "^" operator
with exponents other than INTEGER or floating point). This is why we
proposed a `power' feature (with a floating point exponent) to be
introduced in REAL and DOUBLE and have suggested that a renaming ala
INTEGER's "/" and "//" might be in order so that in REAL and DOUBLE,
"^" invokes the "non-integral" case...
| I am also worried that not enough thought has gone into this point,
| as evidenced by the absence of spell checking (``invertable'').
I sincerely hope that the technical merits of our argument do not hinge
on the quality of my spell checker.
| Perhaps we can discuss this in New York.
Alas, I will not be among the Tower contingent in NY.
In any case, if we can not agree on this, then infix "^" must be dropped
from the standard. We cannot implement the PELKS version due to its
assumption that reference entities can be redeclared as expanded ones.
Steve

|
|