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