Re: A Problem with Simplify

*To*: mathgroup at smc.vnet.net*Subject*: [mg87546] Re: A Problem with Simplify*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Sat, 12 Apr 2008 07:02:42 -0400 (EDT)*References*: <20080411182752.415$I3@newsreader.com> <AB57A5A5-064F-4673-A5A6-2D0EF0594066@mimuw.edu.pl> <EF7A20A1-6A1B-4E29-AD75-5D430AE263F8@mimuw.edu.pl>

Just to demonstrate my assertion that returning the answer in terms of Sinc does not solve the general problem here is a slightly different example: Simplify[Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L], {x, 0, L}], Assumptions -> Element[m | n, Integers]] 0 Simplify[Integrate[Exp[(m*I*Pi*x)/L]* Exp[(n*Pi*I*x)/L], {x, 0, L}], Assumptions -> Element[m | n, Integers] && m == -n] Indeterminate Simplify[Integrate[Exp[(0*I *Pi*x)/L]*Exp[(0*Pi*I*x)/L], {x, 0, L}]] L There are certainly lots of others of this kind. I don't see a panacea for all of them. Andrzej Kozlowski On 12 Apr 2008, at 09:57, Andrzej Kozlowski wrote: > As often happens, I answered in too much of a hurry, so some of the > things I wrote were clearly wrong. Here is a more considered response. > > > On 12 Apr 2008, at 08:17, Andrzej Kozlowski wrote: >> >> On 12 Apr 2008, at 07:27, David W. Cantrell wrote: >>> [Message also posted to: comp.soft-sys.math.mathematica] >>> >>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote: >>>> I am not convinced (by the way, this very question with the same >>>> example was discussed here quite recently). >>>> >>>> The usual argument is that Mathematica adopts a "generic" approach, >>>> whatever that means. I don't much like this way of thinking because >>>> such a concept of "genericity" is hard to formalize. Instead I >>>> have my >>>> own way of thinking about this, which at least satisfies me on this >>>> score. Essentially, I think of all Mathematica expressions as >>>> belonging to some formal algebraic system, a "partial algebra" (you >>>> can formally add and multiply most expressions although not quite >>>> all, >>>> and you can even multiply then by "scalars"). There are certain >>>> "built >>>> in" relations that hold between certain expressions in the >>>> algebra and >>>> other relations can be introduced by the user. Any two different >>>> symbols are always different, unless there is a built in >>>> relationship >>>> or a user defined relationship that says otherwise. Hence the >>>> answer >>>> returned by >>>> >>>> Assuming[Element[m | n, Integers], >>>> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]] >>>> >>>> 0 >>>> >>>> is completely correct in my interpretation and not just >>>> "generically >>>> correct" because in my interpretation m and n are not equal >>>> simply by >>>> virtue of being different Mathematica expressions. On the other >>>> hand: >>>> >>>> Assuming[Element[m | n, Integers] && m == n, >>>> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]] >>>> L/2 >>>> >>>> is also O.K. because we performed the simplification with the user >>>> introduced relation m==n. >>> >>> That's not the reason. Rather, it's because we performed the >>> _integration_ >>> with the assumption that m==n. (Note that if the integration had >>> been done >>> without that assumption and then that result had been simplified >>> with the >>> assumption, we would have gotten Indeterminate.) >> >> Yes, of course I realized that. In fact, note that >> >> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}], >> Assumptions -> Element[m | n, Integers] && m == n] >> >> returns Indeterminate while >> >> Assuming[Element[m | n, Integers] && m == n, >> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]] >> >> returns L/2. >> >> I did not mention this because I did not think it was relevant to >> the point I was making, which applies equally well (or equally >> badly) to Integrate and to Simplify. The point was that general >> principle that all distinct symbols represent distinct entities >> unless stated otherwise no logical problems arise. (By the way, >> this can actually be given a formal mathematical proof). However, I >> have to admit that Mathematica does not actually follow this >> principle - in fact it is kind of erratic about it. > > I would like to add that this issue involves a certain basic > distinction between symbolic algebra (as performed by a computer) > and mathematics as practiced by humans. The meaning of every > "statement" (program) in computer algebra (unlike most statements in > mathematics) is "operational", in the sense that it involves a > definite order in which a certian operations are performed, and > quite often different orders will lead to different resulst. In > mathematics this issue is usually ignored as there is usually a > "natural" or "canonical" order which is not made explicit. As an > example consider the problem of simplifying > > Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}] > > under the assumption that m and n are equal integers. > "Operationally" this can have two distinct meaning. One is: we > assume first that m and n are integers and simplify then Integrate > the resulting expression. In other words: > > Simplify[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], > Assumptions -> Element[m | n, Integers] && m == n] > Sin[(n*Pi*x)/L]^2 > > Integrate[%, {x, 0, L}, Assumptions -> > Element[ n, Integers] ] > L/2 > > > The other: we integrate the given expression and then simplify the > answer with the given assumptions. In other words: > > Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}] > (L*n*Cos[n*Pi]*Sin[m*Pi] - L*m*Cos[m*Pi]*Sin[n*Pi])/ > (m^2*Pi - n^2*Pi) > > Simplify[%, Assumptions -> Element[m | n, Integers] && m == n] > Indeterminate > > Ignoring for the time being the case m==n==0 (to which I will return > below) both of the above are quite correct from the "operational" > point of view, but only the first appraoch corresponds to the usual > meaning of "assuming..." in mathematics. In most cases, however, the > different operational orders will lead to the same outcome and the > issue which order to choose will be decided by considerations of > computational efficiency. I don't this issue can be completely > avoided in computer algebra but as long as one is aware of it, it > should not cause serious problems. >> >>> >>> >>>> So, with my interpretation (different symbols are always different >>>> quantities unless stated otherwise) all is well. >>> >>> Not in my opinion. If both m and n are 0, then obviously the value >>> of the >>> integral must be 0, rather than L/2. (BTW, I had not noted that >>> fact in my >>> previous response to Kevin.) >> >> What do you mean? I wrote that if we accept the convention that >> distinct symbols never represent the same quantity (unless >> explicitely stated that they do) then both m and n can't be 0. >> Opinion has nothing to do with that. > > I wrote the above too quickly and I was clearly wrong (I did not > notice you were referring to the n==m case). You are quite right, > this time even my principle does not apply. So, to be strictly > logical and consistent here, there seem to be only three choices: > to return your answer (using Sinc), to return any answer at all (as > Kevin suggested) or to return a conditional answer (from Integrate). > As I wrote below, I think the first solution, although very > attractive, will not solve the general problem. I am inlcined to > think that in this case Integrate ought to return a conditional > answer (If[m!=0,...]) since (unlike Simplify) it does some time > return conditional answers. As I already indicated, I don't think > that the "generic parameters" argument is logically fully > satisfactory, although its not a bad guide to the actual practice. > > Andrzej Kozlowski > >> >> >> >>> >>> >>> In my previous post, I gave a result which is valid for all real >>> values of >>> the parameters: >>> >>> L/2 (Sinc[(m - n) Pi] - Sinc[(m + n) Pi]) >> >> >> This is true but it deal with just the one single case of the >> function Sin. One can certainly come up with other cases where a >> similar problem appears not involving Sin so even if Mathematica >> returned this resut it would hardly deal with the wider problem. >> >> In any case, the problem is only one of formal interpretation - in >> practice it is easy to get around it if one is aware of how it >> comes about. >> >> Andrzej Kozlowski >

**Re: What is @@@?**

**Re: A Problem with Simplify**

**Re: A Problem with Simplify**

**Re: A Problem with Simplify**