integration weirdness

[Ryan]

Dear all,

Please help me resolve these confusing usage issues.

I'm using Mathcad 15.0 (15.0.0.436 [006041742]).

I've additionally attached my working as a Mathcad worksheet. Thanks.

[AlanStevens]

Mupad(the Mathcad symbolic engine) is not infallible and has problems with difficult integrals (and some simple ones!). I'm using exactly the same version of M15 as you, but your worksheet gives slightly different results for me, as can be seen below:

Alan

[Ryan]

Hi Alan, thanks for your reply.

Okay, I just reopened the worksheet on the same system, and weirdly, my Mathcad is now giving the exact same values as yours (i.e. it is no longer giving the values I originally got earlier on!).

I.e. our copies of Mathcad (including Vladimir's copy of Prime 2.0) all give the same errors.

Please refer to the updated worksheet below (specifically the last question, where I have re-angled the problem):

Thanks!

[VladimirN]

Ryan Goh wrote:

...

I'm using Mathcad 15.0 (15.0.0.436 [006041742])..

This is a F000 service release of Mathcad 15. And I have the same result as shown by Alan (use Mathcad 15 M010).

[Ryan]

Hi, I'm sorry, but I'm not familiar with release history-- what does (F000) service release mean? And how do I upgrade to the version 15 M010 that you mention (without having to pay)?

Thanks.

[VladimirN]

1. Datecodes starting with an "F" designate the first release of a product. Datecodes starting with an "M" denote a maintenance release. Mathcad 15 M010 - the latest service release at this time.

2. To upgrade, you must have paid for a maintenance .

[VladimirN]

Answer in Mathcad Prime 2.0:

[rag · Accepted solution]

think you should not use the variable of integration as a boundery.

Mathcad simply can not integrate that int sybolically.

Obviously it creates nonsense when variable and boundery are the same.

[AlanStevens]

winfrod rager wrote:

think you should not use the variable of integration as a boundery.

I agree, but that's not the cause of the problem here - the same problems occur even if you use a different symbol for the upper bound.

The integral is just too difficult for Mupad. Maple gives the following, where Si is the sine integral and Ci is the cosine integral:

Alan

[mzeftel]

I am logging these issues to be investigated for a future release of Mathcad.

Mona

[ViktorKorobov]

No problem in Mathcad 11:

[Ryan]

This is pure madness! LOL

[Ryan]

Hi Alan, I think Winfrod Rager is right though. If you look at all the examples in our worksheets thus far, Mathcad makes the integration mistake that I highlighted only when the dummy variable of integration is also used as one of the boundaries of integration (whether the dummy variable is x or y or whatever).

[AlanStevens]

Ryan Goh wrote:

Hi Alan, I think Winfrod Rager is right though. If you look at all the examples in our worksheets thus far, Mathcad makes the integration mistake that I highlighted only when the dummy variable of integration is also used as one of the boundaries of integration (whether the dummy variable is x or y or whatever).

Yes, it gives the wrong answer when the boundary variable is the same as the dummy variable. It gives a true but useless answer when the boundary variable is different; but it never gives a true and useful answer!

Alan

[Ryan]

Yes, but Mathcad returning a false answer is more dangerous (when one is not being careful) than it returning a useless (albeit true) answer.

It's not true that Mathcad *never* returns a true and useful answer to this particular integration problem though: the third expression (where the lower and upper limits are set to 0 and 0.8 respectively) is correctly numerically-evaluated as 0.23548... Although oddly enough, when the limits are changed to 0 and 5 (the second expression in the worksheet), Mathcad once again fails. (I have just arbitrarily chosen these particular choice of boundary values.)

[AlanStevens]

Ryan Goh wrote:

Dear Mona, I also note that even though Mathcad is unable to *numerically* evaluate the integral when the lower and upper limits are set to 0 and 5 respectively, it suceeds when the limits are set to to 0 and 0.8, correcting returning the answer 0.23548... (I have no particular reason for these particular choice of boundary values.)

That's because it tries to find an exact solution with exact integer values everywhere (and we already know it is unable to do that!). Stick a decimal point in somewhere and it'll produce a numerical result.

Alan