Different analytical results depending on MathCad version
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Different analytical results depending on MathCad version
I encountered an interesting and maybe concerning problem in how MathCad solves its intergrals between different versions. In the version of MathCad I use (MathCad Prime 9.0.0.0.) the integral I wanted to solve and get an analytical expression to gave one answer. This answer is different from the answer you get on older MathCad versions. I noticed this from some old reports where this integral was solved via MathCad about 20 years ago and they get a different analytical expression. This expression you get from the older versions is also the same you get by solving the integral completely analytically (which you can do via variable substitution). The difference between the answers seem to be very little and the residual could just be some numerical truncation maybe, but as we can see the difference is not completely negligible depending on what you are after. Has anyone encountered something similar to this and know why this is the case?
Solved! Go to Solution.
- Labels:
-
Mathcad Usage
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Its a pity that the symbolic engine is not able to simplify the result so that the desired analytical expression is shown.
But given that that way the functions F and Fanalytical are defined in a different way (even though the expression may be equivalent)) I am not surprised to see tiny numerical differences - these lie within the expectable numerical tolerance given that IEEE number format is used by the numerical engine.
You probably know that the engine for symbolics was changed a few times in the history of Mathcad.
Up to version 13 it was a subset of the most capable Maple engine which was included. LucMeekes' screenshots show the result of this engine.
In version 14 this engine was replaced by muPad (probably because of legal issues) and this was not an improvement.
I gave your inegral a try in Mathcad 15 but the symbolics refuses to return a result with the error message "Condition contains Otherwise in subexpression".
If we use inline evaluation the function is not defined because of the error and can not be evaluated, neither symbolically nor numerically.
But if we separate the definition and the attempt to simplify it symbolically, we get at least nice compact results when (partially) using numbers as arguments
Prime used muPad up to version 6. In version 6 they additionally introduced friCAS (an Axiom fork) for doing symbolics which starting with Prime 7 is the only symbolic engine in Prime. This engine now is modified and trimmed since then by PTC R&D. I won't say that I see it as an improvement over muPad, but it can be seen that there actually is a development and improvements are noticable.
Defining the function in one region and trying to evaluate it symbolically later fails in Prime 10 - at least the result is not displayed because Prime considers it at being too large (??).
Using inline evaluation shows a similar result as seen in your screenshot and I was not able to talk Prime into doing further simplifications.
We can now evaluate with numerical arguments, but Prime is not able to simplify the results in the desired way
But even though Prime can't simplify the results, its symbolics 'knows' that they are equivalent
Interestingly enough this even applies to the full symbolic expressions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I think its numerical accuracy:
You can improve somewhat by having Mathcad solve the integral symbolically in the definition of F:
If Prime insists on using the simplified integral result as shown it will help less, of course.
Success!
Luc
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Thank you for your response! Yes, it does indeed seem to be numerical accuracy mainly. Unfortunately Prime insists on using the simplified (if one could call it that) result. I have not been able to get the other shorter expression from Prime at all and I personally can not see that this expression simplifies to the other expression if I were to do some algebra. In that sense it is difficult to be sure that it is actually exactly the same expressions analytically and the difference is only numerical accuracy.
On the more positive side, I am also interested in the derivate of the resulting expression and these actually become the same expression hinting towards that it is only numerical accuracy then.
It is still somewhat disconcerting that Prime gives a much longer and uglier expression than other versions of MathCad that in turn gives rise to some numerical deviations, although small.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Its a pity that the symbolic engine is not able to simplify the result so that the desired analytical expression is shown.
But given that that way the functions F and Fanalytical are defined in a different way (even though the expression may be equivalent)) I am not surprised to see tiny numerical differences - these lie within the expectable numerical tolerance given that IEEE number format is used by the numerical engine.
You probably know that the engine for symbolics was changed a few times in the history of Mathcad.
Up to version 13 it was a subset of the most capable Maple engine which was included. LucMeekes' screenshots show the result of this engine.
In version 14 this engine was replaced by muPad (probably because of legal issues) and this was not an improvement.
I gave your inegral a try in Mathcad 15 but the symbolics refuses to return a result with the error message "Condition contains Otherwise in subexpression".
If we use inline evaluation the function is not defined because of the error and can not be evaluated, neither symbolically nor numerically.
But if we separate the definition and the attempt to simplify it symbolically, we get at least nice compact results when (partially) using numbers as arguments
Prime used muPad up to version 6. In version 6 they additionally introduced friCAS (an Axiom fork) for doing symbolics which starting with Prime 7 is the only symbolic engine in Prime. This engine now is modified and trimmed since then by PTC R&D. I won't say that I see it as an improvement over muPad, but it can be seen that there actually is a development and improvements are noticable.
Defining the function in one region and trying to evaluate it symbolically later fails in Prime 10 - at least the result is not displayed because Prime considers it at being too large (??).
Using inline evaluation shows a similar result as seen in your screenshot and I was not able to talk Prime into doing further simplifications.
We can now evaluate with numerical arguments, but Prime is not able to simplify the results in the desired way
But even though Prime can't simplify the results, its symbolics 'knows' that they are equivalent
Interestingly enough this even applies to the full symbolic expressions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Thank you for the very thorough answer! This explains a lot. I have also encountered the problem that I can not evaluate it symbolically later and thought it was weird. I once even had a case were I could not symbolically take the derivate of f(x)=x*A with respect to x, because A was seen as too long even though it could write it out previously.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Especially using the symbolics we often encounter unexpected and unexplainable results.
There is still a lot of room for improvement in the quality and capabilities of the Symbolics (and not only there) in Prime ...
