MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: A Problem with Simplify

  • To: mathgroup at
  • Subject: [mg87546] Re: A Problem with Simplify
  • From: Andrzej Kozlowski <akoz at>
  • Date: Sat, 12 Apr 2008 07:02:42 -0400 (EDT)
  • References: <20080411182752.415$> <> <>

Just to demonstrate my assertion that returning the answer in terms of  
Sinc does not solve the general problem here is a slightly different  

  Simplify[Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L], {x, 0,  
  Assumptions -> Element[m | n, Integers]]

        Exp[(n*Pi*I*x)/L], {x, 0, L}],
    Assumptions -> Element[m | n, Integers] &&
        m == -n]

Simplify[Integrate[Exp[(0*I *Pi*x)/L]*Exp[(0*Pi*I*x)/L], {x, 0, 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> 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

  • Prev by Date: Re: What is @@@?
  • Next by Date: Re: A Problem with Simplify
  • Previous by thread: Re: A Problem with Simplify
  • Next by thread: Re: A Problem with Simplify