Skip to main content
J
JH_129540071-Visitor
1-Visitor
February 26, 2025
Solved

Different analytical results depending on MathCad version

  • February 26, 2025
  • 2 replies
  • 1070 views

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? 

Best answer by Werner_E

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.

Werner_E_0-1740578524698.png

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

Werner_E_1-1740578607103.png

 

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 (??).

Werner_E_3-1740579184502.png

 

Using inline evaluation shows a similar result as seen in your screenshot and I was not able to talk Prime into doing further simplifications.

Werner_E_2-1740579155388.png

We can now evaluate with numerical arguments, but Prime is not able to simplify the results in the desired way

Werner_E_4-1740579416586.png

But even though Prime can't simplify the results, its symbolics 'knows' that they are equivalent

Werner_E_5-1740579553792.png

Interestingly enough this even applies to the full symbolic expressions

Werner_E_6-1740579599830.png

 

 

 

2 replies

L
LucMeekes23-Emerald IV
23-Emerald IV
February 26, 2025

I think its numerical accuracy:

LucMeekes_0-1740560373800.png

You can improve somewhat by having Mathcad solve the integral symbolically in the definition of F:

LucMeekes_1-1740560446700.png

If Prime insists on using the simplified integral result as shown it will help less, of course.

 

Success!
Luc

    J
    JH_129540071-VisitorAuthor
    1-Visitor
    February 26, 2025

    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.

    mathcad_integral2.png

    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. 

    mathcad_integral3.png

    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.

    W
    Werner_E25-Diamond IAnswer
    25-Diamond I
    February 26, 2025

    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.

    Werner_E_0-1740578524698.png

    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

    Werner_E_1-1740578607103.png

     

    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 (??).

    Werner_E_3-1740579184502.png

     

    Using inline evaluation shows a similar result as seen in your screenshot and I was not able to talk Prime into doing further simplifications.

    Werner_E_2-1740579155388.png

    We can now evaluate with numerical arguments, but Prime is not able to simplify the results in the desired way

    Werner_E_4-1740579416586.png

    But even though Prime can't simplify the results, its symbolics 'knows' that they are equivalent

    Werner_E_5-1740579553792.png

    Interestingly enough this even applies to the full symbolic expressions

    Werner_E_6-1740579599830.png

     

     

     

      J
      JH_129540071-VisitorAuthor
      1-Visitor
      February 27, 2025

      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. 

      W
      Werner_E25-Diamond I
      25-Diamond I
      February 27, 2025

      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 ...

      Terms & ConditionsCookie settingsAccessibility statement