MathGroup Archive 2008

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

Search the Archive

Re: A Problem with Simplify

  • To: mathgroup at smc.vnet.net
  • Subject: [mg87550] Re: A Problem with Simplify
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sat, 12 Apr 2008 07:03:27 -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> <005e01c89c52$3adb21b0$13783e44@Dell>

Yes, you are right here and I admit that I spent no time at all on  
this issue. I manufactured the example essentilally by replacing Sin  
by Exp, and of course I should have  remembered that as these  
functions are closely related one very likely probably manufacture a  
siutbale anti-derivative in terms of Sinc.

But my purpose was to demonstrate how easily one can generate examples  
of this kind. In order for your proposed solution to be really useful  
what you would need to do is

1) construct a general algorithm for expressing at least a wide class  
of such anti-derivatives in tems of Sinc (and parhaps other related  
functions)

2) show how to combine this algorithm with the Risch algorithm used in  
all current CAS systems for evaluating indefinite integrals.

Unless you or someone can deal with both of these problems (none of  
which seems very easy to me but then this is not my field and I have  
not given the issue more time than it takes ot write this sort of  
message), then even if you write many more posts to the MathGroup on  
the virues of Sinc and related topics (in addition to the large number  
that you have already written) they will all remain just curiosities  
without any practical impact.

Andrzej Kozlowski


On 12 Apr 2008, at 13:03, David W. Cantrell wrote:
> 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: Directory of Mathematica Add-Ons
  • Previous by thread: Re: A Problem with Simplify
  • Next by thread: Re: A Problem with Simplify