[Date Index]
[Thread Index]
[Author Index]
Re: A Problem with Simplify
*To*: mathgroup at smc.vnet.net
*Subject*: [mg87548] Re: A Problem with Simplify
*From*: "David W. Cantrell" <DWCantrell at sigmaxi.net>
*Date*: Sat, 12 Apr 2008 07:03:05 -0400 (EDT)
*References*: <20080411182752.415$I3@newsreader.com> <AB57A5A5-064F-4673-A5A6-2D0EF0594066@mimuw.edu.pl> <EF7A20A1-6A1B-4E29-AD75-5D430AE263F8@mimuw.edu.pl> <7C8E66D5-850E-404B-B7DF-1D6E9B2FBEBC@mimuw.edu.pl>
On 12 Apr 2008, Andrzej Kozlowski wrote, in his third response to me:
> 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.
I never claimed to have a panacea. Nonetheless, returning an answer in
terms of Sinc certainly _does_ work for your "slightly different
example". (BTW, I'm quite puzzled that you claim to provide an example
showing that returning an answer in terms of Sinc does not help, but
yet you never actually show what an appropriate answer in terms of
Sinc would be!)
Your example seems, at least to my eye, to be needlessly complicated.
The problem which lies at its heart is simply that
In[6]:= Integrate[Exp[r x], x]
Out[6]= E^(r*x)/r
is not valid when r happens to be 0, for then we should instead have
In[7]:= Integrate[Exp[0 x], x]
Out[7]= x
But, using Sinc, it's easy to give an antiderivative for Exp[r x]
which is valid even when r happens to be 0:
x (Sinc[I r x] + r x/2 Sinc[I r x/2]^2)
Of course, that antiderivative can then be used to get an answer for
your specific example, namely, your first definite integral
Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L], {x, 0, L}]
is
L*(Sinc[2*(m + n)*Pi] + I*(m + n)*Pi*Sinc[(m + n)*Pi]^2)
So again, Sinc was helpful. But of course, many examples
could be given in which Sinc would be of no help.
David W. Cantrell
> 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
>>
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**
| |