ansaurus

Question

Bug in Mathematica's Integrate with PrincipalValue->True

Answer 1

+2 A:

I don't think this is a bug in PrincipalValue. In the first line PrincipalValue does not work "correctly" because the position of the pole is not known until after Integrate is done.

EDIT: I played around in Mathematica a bit and this is exactly what happens. You can see for yourself by using the Trace[] command. The output is a bit messy (which is why I don't replicate it here), but you can see where the integration gets done and where the value for x0 is substituted and how that messes with PrincipalValue.

EDIT2: So back to solving your actual problem. If you use an Assumption that specifies which side of x=1/2 x0 lies, then the two examples give the same answer.

Timo 2010-06-02 09:52:11

From your answer, it appears that you consider PrincipalValue as sort of a methods guidance for the integration algorithm, whereas I think of it as requesting a mathematically well defined result, namely the Cauchy principal value of the integral. As this result has a strict mathematical definition, it constitutes a bug (from my point of view) if Mathematica arrives at two different answers when asked for the result in two different (but mathematically equivalent) ways.

Janus 2010-06-03 03:18:53

Well it is not strictly me who thinks of PrincipalValue that way, I'm just telling you how Mathematica behaves ;-). The question may be mathematically equivalent, but that does not mean that it is computationally equivalent or possible. Look at the output of Trace for both cases and think about what happens if x0->I. See how it becomes very difficult to decide on the principal value of the integral before the substitution?

Timo 2010-06-03 05:54:22

I would also point out that the two ways are not mathematically equivalent. As you point out, the first integral is evaluated with x0 as a free parameter. Now my math is slightly rusty, but that seems to disqualify the integral from being a definite integral and thus make it impossible to select the Cauchy principal value even in a purely mathematical sense.

Timo 2010-06-03 12:04:49

I don't quite agree on the mathematical equivalence -- but instead of continuing that discussion (without MathML), I have added another example of the bug to the question. For the new example I hope that we can agree that Mathematica spits out different results to exactly the same question?As flipping the sign fixes the problem in all the situations I need it, I wont be examining this much more -- at the price Wolfram charges, they should certainly do their own bughunting!

Janus 2010-06-03 15:24:15

OK, that's a bug! For an even better demonstration remove the `Assumptions->{x0>0}` part.

Timo 2010-06-04 05:23:18

So back to solving your actual problem. If you use an Assumption that specifies which side of x=1/2 x0 lies, then the two examples give the same answer.

Timo 2010-06-04 05:43:11

Thanks Timo. In my case, I don't know x0 -- the real motivation is that I want an expression that's valid for all values, preferably without a cases statement.After flipping the sign on the integrand, I now get the answer I need, so all is peachy (my best guess is that `PrincipalValue` just looks for simple poles, and that the pattern is not clever enough). Anyways, I'll mark this as an answer to close the question.

Janus 2010-06-07 06:30:04

Thanks. On a final note, flipping the sign actually does what I was suggesting since the assumption x0>0 puts x0 squarely on one side of x=-1/2 (note the sign change). The problem as far as I can determine is that if it is possible for the pole to be at x=1/2 (or -1/2 if you flip x's sign), this messes up Mathematicas logic for finding the principal value. Also, note that flipping the sign changes the problem in as much that the Assumption should read x0<0 now for the problem to be equivalent. This of course brings back the original problem :-(.

Timo 2010-06-07 07:41:18

Answer 2

A:

Well Wolfram Alpha, which I would assume uses the latest version of Mathematica, doesn't like your first expression and gives this for the second: log(3)+constant

http://www.wolframalpha.com/input/?i=Integrate[UnitBox[x]%2F%28x0+-+x%29+%2F.+x0+-%3E+1%2C+{x%2C+-Infinity%2C+Infinity}%2C++++PrincipalValue+-%3E+True]

It may be that this article applies in this case but I'm not a math expert so I wouldn't know? There are some situations, however, where several different answers are all equally consistent with the formal mathematical definitions. Thus, for example, in computing symbolic integrals, there are often several different expressions which all yield the same derivative. Which of these expressions is actually generated by Integrate can then depend on how Integrate works inside.

daveangel 2010-06-03 03:38:21

Thanks. It seems that Wolfram Alpha doesn't understand the `Replace` and `Rule` syntax from standard Mathematica, so I am not quite sure what question it is answering.

Janus 2010-06-03 14:58:33

ansaurus

tags:

views:

answers:

Bug in Mathematica's Integrate with PrincipalValue->True

related questions