Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X
Hi.
First post, LONG time mathcad user...on prime 9 now.
I'm trying to fit a fairly routine function to some datapoints using genfit.
I don't see where this is going wrong.
genfit basically treats the guess value for 'a' as a hard constraint.
So whatever I set the guess value to ('3', below), the fitted function asymtotes to that value and does not adjust 'a' to fit fit the data.
What am I doing wrong?
Many thanks in advance.
Solved! Go to Solution.
Forgot to attach the worksheet..
BTW, as an alternative to "genfit" you can also use a solve block with "minerr". Here the units seem to be no problem:
I also noticed that the bug you found is even more evident if we don't provide the partial derivatives. Now the guess for "a" really seems to be taken as a hard constraint and the value is not changed all:
@GR_4797597 wrote:
Hi.
First post, LONG time mathcad user...on prime 9 now.
My condolences to you!
I'm trying to fit a fairly routine function to some datapoints using genfit.I don't see where this is going wrong.
genfit basically treats the guess value for 'a' as a hard constraint.
So whatever I set the guess value to ('3', below), the fitted function asymtotes to that value and does not adjust 'a' to fit fit the data.
What am I doing wrong?
Many thanks in advance.
Its too hard to debug a picture!
Please post your sheet with the data.
Maybe Prime is right!? Your fitting function just depends on two parameters. Maybe 2.998 actually IS the optimal value for the scaling parameter a ?!
Could it be that your function has local optimums around any value of a? And then those are found.
Thanks!
I attached the code. Please let me know if there's a better way to do that.
The mis-behaviour is most obvious if I set the 'a' guess = 1, say:
OK, the result with the guess a=3 did no look that bad, but now with a=1 is sure way off.
I played around and found that the reason for this undesired behaviour is the unit ampere. As I understand, genfit should work OK with units, too. At least the help does not mention units in any way in the chapter about genfit, so we have to assume that its OK to use units.
Given that, I tend to call it a bug. You may consider reporting it to PTC support.
In real Mathcad we would not have been allowed to define the guess vector with mixed units (unitless and ampere), but Prime fortunately allows mixed dimensions in matrices and so "genfit" should not have problems using them.
Here a work-around: Guess value tau unitless; when calling genfit we strip the unit from vector I and after that we add the unit to the parameter tau. Not as it should be, but seems to work OK.
Forgot to attach the worksheet..
BTW, as an alternative to "genfit" you can also use a solve block with "minerr". Here the units seem to be no problem:
I also noticed that the bug you found is even more evident if we don't provide the partial derivatives. Now the guess for "a" really seems to be taken as a hard constraint and the value is not changed all:
Hey thanks Everyone! Really helpful.
I've started uising minerr which seems fine even with the goofy solve blocks in Prime.
Cheers!
I searched the forum and found, that I discussed what seems to be the very same bug already 10 years ago with Richard. Had completely forgotten about it.
Bug in Prime 3 using regressions with units? - PTC Community
Perhaps some kind soul (? @DJNewman ?) could report this bug in a way that makes it likely to get fixed as soon as possible.
Documentation actually does make reference to genfit not accepting units. ...It's not on the genfit page, and I don't know why, but it's on this page instead:
So perhaps it's not a bug and a documentation issue, in which case, feel free to click the "Send feedback about this page to PTC" button to email the Documentation team directly.
Thanks for the information. Its well hidden, indeed. BTW, The page says that the ODE solvers won't accept units but I thought that they would be unit aware now!? Or does this apply to the solve block "odesolve" only and the stand-alone solvers still won't accept units. Have to give it a try sometime.
So its sure a documentation issue which should be fixed,
But I still consider it a software bug, too. If a function is not intended for unit-based input values, then it should output an appropriate error message if you feed it with units anyway and not return an incorrect(!) result without comment - that is quite dangerous and an absolute no-go IMHO.
This means that we need two bug fixes in the short term:
1) The documentation must clearly emphasize in the description of the function the fact that units may not be used.
2) The function itself must recognize input variables containing units and output a corresponding error message and must under no circumstances simply deliver incorrect results.
In the medium term, it is of course very desirable, especially with software like Mathcad Prime, that as many of the white spots (functions that cannot handle units) as possible disappear from the map.
BTW, I already made use of the feedback facility.
Thanks for the fast reply.