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
>