MathGroup Archive 2008

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

Search the Archive

Re: A Problem with Simplify

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

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:

    Assumptions -> Element[m | n, Integers] && m == n]

Integrate[%, {x, 0, L}, Assumptions ->
      Element[ n, Integers] ]

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]

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: A Problem with Simplify
  • Next by Date: Re: A Problem with Simplify
  • Previous by thread: Re: A Problem with Simplify
  • Next by thread: Re: A Problem with Simplify