Hi All.
My students and I have been getting some entertaining results with the solver arrow for the example problem below.
With the "new" and "legacy" symbolic solver the results are somewhat "brittle" almost on par with the picture you get when playing with the ariels of an old-style TV set. The correct answer should be about 0.0265.
For example a common result popping up for the NEW solver is this one (but the letters after the % can differ). Note also that you can get the "Red Box of Shame™️" with some versions (the type of error in this case is highlighted.
When using the legacy solver it can be more likely to behave and give the correct answer. It also sometimes will give the correct answer but add a very negligible imaginary component.
Ideas her are welcome and PTC probably should give a prize for the most bizarre answer anyone can muster with this problem.
Cheers and Thanks
Bill Capehart
SD Mines
Solved! Go to Solution.
Mathcad 11 / Maple:
There apparently are two possible solutions to the problem, when a=2, b=3.7, c=2.51 and W() is the LambertW function.
Success!
Luc
Mathcad 11 / Maple:
There apparently are two possible solutions to the problem, when a=2, b=3.7, c=2.51 and W() is the LambertW function.
Success!
Luc
Apologies for losing this in the fog of time, Luc. Thanks for this!
What had us curious is the percentage notation and how the letters will vary from attempt to attempt. Is there any explanation for that?
Cheers and Thanks again.
Bill
Prime 8 gives:
And In the mean time there's Prime 9, which is supposed to have fixed a number of symbolic problems.
But you can also solve the problem numerically, using the root function:
This should also work in Prime 6.
Success!
Luc
Yes, root(), solve blocks, hand-written ||-functions the students code that do False-Position, Newton, Second and Bisection all work fine with the same root equation. It's just the symbolic [arrow] solver that produces that behavior. It's hard to replicate. Every semester one or two students get it for the canned example we do in class for the same values of Re, & f. For me it's a curiosity (and an amusement) and not so much of a problem since we have other resources in MCP to do the job.
Cheers
Bill
The new symbolics still has its hickups and in quite some respects lives not up to the old one(s).
But its a work in progress and is slowly but continually improving. As Luc has shown, the problem is already fixed in version 8 (and of course in version 9, too). It just returns the expected numeric result (also when you add the "assume,f>0" constraint).
BTW, sometimes it even happened in good old Mathcad (V.15 and below) that the symbolic result would show some strange "variables" which possibly where used internally and were never supposed to pop up in a final result.
Ah. That's the answer I was looking for 😉 It makes sense the %{XY} was a placeholder to hold larger terms waiting to be addressed by the algorithm!
Thanks
Bill