Re: Inconsistent behaviour of Integrate
- To: mathgroup at smc.vnet.net
- Subject: [mg112487] Re: Inconsistent behaviour of Integrate
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Fri, 17 Sep 2010 06:41:06 -0400 (EDT)
On 16 Sep 2010, at 18:00, Andreas Maier wrote:
> Andrzej Kozlowski wrote:
>> Well, on a fast computer Mathematica will consistently produce the better result, unless your CPU is busy with other things or you on purpose decide to reduce performance. On a slower computer you will get the better (more "reduced") result on a second attempt after cashing it. The alternative would be to let your computer run for much longer. That would make Integrate more consistent but would also probably make many users loose patience.
>> Having everyone get the "less good" result would not seem to me like "progress".
>
> The problem in my case is that the result produced on a slower computer is actually more useful
> than the result produced on a faster computer. The solution
>
> Out[1]== 1/6 (Sqrt[2] + ArcSinh[1])
>
> is much more useful to me than
>
> Out[2]== 1/24 (4 Sqrt[2] + Log[17 + 12 Sqrt[2]])
>
> So not in every case more CPU-h means a better result. And the reason seems to be that
> Mathematica can expand (1 + Sqrt[2])^4 to 17 + 12 Sqrt[2], but not factorize
> 17 + 12 Sqrt[2] to (1 + Sqrt[2])^4 again. So when running for a longer time Mathematica
> seems to fall into a "trap" and is not being able to go back to the simpler result.
Well, you can do this:
ExpToTrig[(1/24)*(4*Sqrt[2] +
Log[17 + 12*Sqrt[2]])] // FullSimplify
(1/24)*(4*Sqrt[2] + ArcCosh[17])
this is not the same as your first output but I don't see how you can claim it is significantly more complicated. I agree that in this particular case it is difficult to see why Mathematica prefers the second result to the first but in general, the principle that Mathematica should attempt more transformations on faster computers and rely on caching on slower ones seems fine to me.
> Another possibility is that Mathematicas algorithm somehow considers Out[2] as
> simpler result than Out[1]. But this is odd, since Out[2] uses more operations
> and bigger integer number than Out[1]. Here it would be nice if one could influence
> the criteria Mathematica uses to consider one expression as simpler than another.
You can influence these criteria, by using the options TransformationFunctions and CompexityFunction in FullSimplify. There have been many examples of this on the forum so I won't go into that again. But of course this will not in general make Mathematica convert and expression to precisely the form you prefer. In any case, it is clear that the final answer in this problem was not the one that applying FullSimplify to the earlier output would have produced:
FullSimplify[(1/6)*(Sqrt[2] + ArcSinh[1])]
(1/6)*(Sqrt[2] + ArcSinh[1])
Even applying TrigToExp produces a simpler answer:
Simplify[TrigToExp[(1/6)*(Sqrt[2] + ArcSinh[1])]]
(1/6)*(Sqrt[2] + Log[1 + Sqrt[2]])
This case is rather mysterious and I have to confess to not understanding it fully. I hope someone from Wolfram will provide more enlightenment.
Andrzej Kozlowski