NICE-ESG-Libs Digest        Wed,  7 Jun 95       Volume 1 : Issue 249 

Today's Topics:
     fwd: [eiffel@swissoft.h.provi.de] Comments on Power operator


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: Wed, 7 Jun 95 17:23:55 EDT From: tynor (Steve Tynor) Subject: fwd: [eiffel@swissoft.h.provi.de] Comments on Power operator To: nice-esg-libs I asked Michael Schweitzer of Eiffel/S fame, who has a vastly superior mathematics background than I, to comment on the current "power operator" controversy. I think he has done a much better job than me in explaining our position. I hope it sheds some light on the subject. [For those with weak stomachs for mathematics, don't worry: though even this appears dry and complicated, it's really not all that hard to follow :-)]. Steve ------- start of forwarded message (RFC 934 encapsulation) ------- From: eiffel@swissoft.h.provi.de (Michael Schweitzer) To: tynor@atlanta.twr.com Subject: Comments on Power Operator Date: 07 Jun 1995 19:35:00 +0200 Dear colleagues, I'd like to contribute to the discussion about the feature infix "^" in class NUMERIC. A) Semantics: For every feature in every class one should at least be able to explain the semantics in a natural language (English, say) - if this fails, all your alarm bells should ring (be- cause then there isn't the slightest chance to describe the semantics in a formal language). Now, if the signature of '^' (in NUMERIC) is supposed to be infix "^" (other : NUMERIC) : NUMERIC then what are the semantics of this feature? You may say: "well, that's clear, raise Current to the power of other!". But a moments reflection shows that you've only said: "'a ^ b' must be read as 'raise a to the power of b'. But that doesn't explain anything - it only gives '^' another name. Of course, we all have an intuitive understanding of what "raise a to the power of b" should mean. In fact, in mathematics, exponentiation always includes the 'natural' cases where the exponent is a natural number - i.e. whenever you have a notion of exponentiation in mathematics ('^') then you also have exponentiation with natural numbers. The signature of infix "^" should reflect this - i.e., whenever you are allowed to write a ^ b for some expressions of type A and B, respectively, then it should also be allowed to write a ^ 2 (as an abbreviation for a * a). However, the proposed signature fails to fulfill this simple criterion. - ----------------------------------------------------------- B) Algebraic vs. analytic It is sad that so many people confuse exponentiation (i.e. a ^ b) with exponential functions and logarithms. Exponentiation is an algebraic concept, exponential functions and logarithms are analytic concepts. Ex- ponentiation with non-negative integers is possible whenever you have a notion of multiplication: a ^ b is simply an abbreviation for a * a * ... * a (b times). For example, in every group (written multi- plicatively) and in every ring you have exponentiation. You can raise a square matrix to the power of 100, say. You can raise a polynomial to the power of 2, say - etc. Exponential functions and logarithms are something com- pletely different. It would take too much space to explain this (and for non-mathematicians it would be of little use anyway). Suffice it to say that exponentiation (with integer exponents) is mathematically the more general concept. - ----------------------------------------------------------- C) Comments ISE has proposed the above mentioned signature for infix "^" and I would like to comment two statements made by Bertrand Meyer and by Pierre-Olivier Nallet: Bertrand Meyer wrote: > It is to be expected that a class COMPLEX will have a power > operator, such that e.g. (-1) ^ 0.5, i.e. square root of > -1, has value i. This is the 'algebraic' aspect: extract 'the' square root of -1. Now, everybody knows that there always exist two square roots (except for zero) of a complex number, i.e. X ^ 2 = c has always two solutions x and -x. In the case of real numbers there is a convention: the function square_root (r) should return the non-negative root (of course, here we must have r >= 0). It may equally well return the non- positive root. But how could one possibly formulate such a rule for the complex numbers. For instance, the expression (-1) ^ 0.000001 has one million different values. Now we come to the 'solution' of this dilemma: USE LOGARITHMS! Pierre-Olivier Nallet wrote: > exponential_power (y: ???):??? is > require > exponentiable > ensure > Result = (y * (Current.ln)).exp .... >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 The only piece of this message which makes any sense is the observation that there are infinitely many logarithms of complex numbers (the 'modulo ...' piece). It is well known that you cannot have a logarithm which 'works' for all complex numbers - you have to exclude a 'half line' - usually the real numbers <= 0. The 'true' logarithm 'lives' on a Riemannian surface. One can definitely _not_ say that ln (1) = 2 * i * pi, because ln (1) = ln (1 * 1) = ln (1) + ln (1) from which we can easily conclude that ln(1) = 0 (if 1 is allowed as argument to ln). The last message also included the definition of 'exponentiable' in the case of real numbers - it says that you cannot raise a negative real number to any power whatsoever! Therefore you must rewrite (x0 - x1) ^ 2 + (y0 - y1) ^ 2 (distance of two points (x0, y0), (x1, y1)) as (x0 - x1) * (x0 - x1) + (y0 - y1) * (y0 - y1). - ----------------------------------------------------------- D) Generality Bertrand said that the proposed signature is the most 'general' and is therefore better than the signature proposed by Tower and SiG (i.e. the Gustave signature). If you take the narrow view that 'the higher in the class graph, the better' then this is both true and false. It is true, because NUMERIC is closer to ANY than INTEGER. It is false, because ANY would even be better, i.e. infix "^" (other : ANY) : ANY would be the most general signature that I can imagine. Mathe- matically, it makes as much sense as the proposed signature, be- cause none of the assertions and none of the features mentioned in the assertions of "^" make any use of the fact that the argument or return type is NUMERIC - it could as well be ANY, or ARRAY or whatever. Infix "^" is just "Ein Mann ohne Eigen- schaften" (for those who know Musil) or "a feature without semantics" (for those who don't know Musil). Scientists do not seek for the most 'general' formulation or theory for the sake of generality alone, but they seek for the most general formulation within the frame of reality. This is especially true for mathematics and it's one of the major reasons why mathematics have turned out to be such a powerful tool for the natural sciences. Bertrand's claim that our definition comes out of the muddy waters of computer science (efficiency and other slimy animals) whereas his definition comes from the holy sphere of pure science is totally unjustified. Where ever ISE's definition comes from - it has nothing to do with mathematics. - ----------------------------------------------------------- Conclusion: I could give you more examples why the proposed signature is mathematically unsound. I could try to explain the comments I've made above in more detail. I could give you a list of references to textbooks written by the most outstanding mathematicians of our century. But this is not a seminar on math and I think it's a shame that such scientific unsound proposals need to be discussed at all. With best regards, Michael Schweitzer SwisSoft, Michael Schweitzer Geismar Landstr. 16 D-37083 Goettingen Fax : +49 551 770 35 44 email : eiffel@swissoft.h.provi.de ------- end -------