... Forgot to add that replacement of g = x by g = x^2 seems to give the correct answer, so it may be something to do with just x being miscalculated (or some assumption that I'm making that the symbolic processor isn't!).
.... this also seems vaguely familiar - I have a slight sense of deja vu.
in Mathcad Prime 3.1 problem is resolved by changing sin(6) to sin(6 rad). Symbolic solver needs to know units.
MH
The same is true for Mathcad 15.
But its not the unit which does the trick. For the symbolics rad is unknown and so its treated like a variable. As long as you provide any variable as argument of sine, all is OK.
Well, I tried but I only have a Basic PTC.com Account and it seems that I have to upgrade to open a case. And to upgrade I need a Customer Number and a Service Contract Number etc. I have requested the necessary information from our IT department.
Do you know any alternative way to contact PTC Support?
Amazing. Not the bug, there are so many, but the thousands of jobs where the bug can set bad calculations. Also amazing the time from the bug appear and the Henning discover. Well, it's engineering, not an exact science. Hope no buildings or aircraft or thermal engines wasn't be affected by this.
Just because with sin(6.0) can get the correct answer, and the general form of diff function in mupad is diff(function, var1, var2, var3, ...) I guess that the bug must to be related with the way in that mathcad handle exact/inexact numbers and the way for transform mupad's diff to mathcad's diff, which (I assume) much more similar to maple's: diff(function, var$n). For example, in mupad diff(f(x,y),x,,x,y) is in mathcad diff(diff(f(x,y),x,2),y). In the steps for making that is where the second arg for sin, ln, log, etc. could be appear.
