I just got Prime 7 and tried to do a sample calculation for a class. It doesn't seem to be able to evaluate a very simple integral. V15 and MATLAB both get the right answer with no problem. The weird part is that it only gives the wrong answer when the number is 4. I didn't see a problem with other numbers. This was for a lesson on Fourier series.
Hopefully, the problem is me and not Prime 7. I most appreciate any suggestions.
Solved! Go to Solution.
I'm sorry, but the problem is not you, but Prime 7.
Better stick with Prime 6, where it was still OK:
Which means that PTC (again) managed to make things worse.
But it does get better in Prime 7 when you split the integral up:
And then it doesn't matter how you split it up:
If you're a licensed user, report this serious bug to PTC.
Extensive regression testing is usually a requirement for companies that successfully roll out new versions of software. Not sure what internal guidelines are in place at PTC.
I seem to recall that MathSoft utilized beta testing as part of its Mathcad development process. I am unaware of any such effort by PTC.
A long time ago, I volunteered to be and alpha tester for Prime 1. I installed the first release and tried add two integers, something like 2+5. It gave me the wrong answer. I called the help line, thinking I must have done something wrong, and they told me that there were still some errors in the code. I realized then that something was wrong and that I'd probably be using V14/15 for some time to come. I have to assume that, after all this time, PTC is managing the development program better now. I guess we'll find out when they do a bug fix release of P7
It’s well known that software quality for a non-trivial application can be modelled with a Weibull distribution with a large probability of an error during initial stages of test/usage falling off toward zero as usage time goes on as uncovered errors are corrected. The probability of encountering a new error approaches zero but never becomes zero. This is “the cost of doing business”; you cannot modify to add improvements or changes without taking on some risk.
For business reasons, PTC is changing its symbolic engine and errors are likely. This is a reason to keep Prime 6 (or maybe like Luc, Mathcad 11) while these errors are corrected. Unfortunately, the time between Prime versions is many months. There is always Maple and Mathematica for more esoteric needs.
The worrisome thing about the error that you uncovered is that it is in a basic part of the numeric engine. I have believed that Prime versions 5 and 6 are “good enough” for my usual needs and, since PTC uses numerical Prime with its Creo product, I could trust its numerical calculation results.
The basic question is: if I cannot trust either symbolic or numeric results, why should I use Prime 7 at all?
This is interesting. The lesson seems to be that there are ways around the problem, but you have to notice the problem and know the workarounds.
Do we know of other calculation problems with Prime 7? In understand that PTC is pulling the plug on V15 in December, so I'd like to move to Prime. I wonder if the best plan is to wait until summer to get PTC a chance to fix some of the remaining bugs.
This is (probably) a fairly exotic failure due to a change in the software (Every improvement involves a change, but not every change is an improvement. Admitted: every deterioration involves a change, but not every change is a deterioration.). Personally I wonder what produces this value of -0.151365...; I cannot relate it to anything known.
Even if PTC have a rigourous testing vehicle to check correct functioning of their software (within which they now should include a test for this scenario), such failures can always happen. If they henceforth test for the integral with 4 pi, next time it may fail with 16 pi, who knows....
One way around that could be that all numeric answers would be checked by having the symbolic processor produce an answer on the same problem for verification, before the answer is displayed. Unfortunately not all problems can be solved symbolically, but more importantly: You would probably not want to pay the price in performance...
A long time ago, I was part of a software development project. Every release was better than the previous one, but there always seemed to be new errors. Over time, the code became pretty robust.
One thing I remember well is that users always blamed the code when they had problems. The reality was that most problems were user errors, though sometimes subtle ones. Whatever I might think of PTC's business decisions, I have to assume that the programmers are conscientious and diligent. It may be unreasonable to expect them to have found something this odd unless it is a symptom of some more systemic problem.
The path has not been a smooth one, but I'll be ready to move from V15 to Prime 7 when the time comes.
Looking forward to the next release of Prime 7 🙂
The two processors (numeric <=> symbolic) function independently, with different algorithms. It is not uncommon that they produce different answers to a certain task, especially so when the answer is debatable from a mathematical standpoint. One example is the heaviside step function.
In Mathcad 11:
In Prime 7:
I wouldn't be surprised if the symbolic answer in Prime7 would be 1.