Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
Hello folks,
I'm currently doing data fits in a bulk; i.e. several hundred sets. Therefore, I'd like to automate this. Some data sets seemed peculiar and I noticed an odd behaviour when it comes to exponential fitting; see attached file.
In two different data sets, which are very similar, Mathcad's expfit function determines vastly different coefficients. Does any body has a remedy for this or can explain it?
I'm using MC15 on a 64 bit Win 7 machine.
Thanks
Raiko
Solved! Go to Solution.
I think the conclusion so far is that you are better off using genfit or a solve block as opposed to expfit or you may fiddle around with the guesses.
I don't know if this would be an option but it looks to me that a modified exponential f(x)=a*exp(b/x) might make an equal good if not even a better fit and is only dependent on two parameters (BTW, as you can see in the pic, even changing the guess 1 to 2 makes expfit work OK):
I have no explanation (other than we are dealing with a numerical algorithm trying to fins a local(!!) minimum and so depends on the guess values) so but of course you can change the behaviour by changing the guess vector. Replace the 1 there for a 10(even 2 dows the job) and your second example gives you the result you expect.
Exchange the 1 for 0.1 in the the first example and it will give you the same undesired result.
I understand thats its quite demanding how to generate appropriate guesses in a bulk processing.
You may provide a few different guesses and calculate the Error (least squares) for the fit you get with each of them and then keep the best.
I also noticed that genfit seems to do a better job (at least with your second example).
Maybe a solve block with minerr does even better. At least you get the error immediately by evaluating the system variable ERR after the solve block.
If you build a solve block, you can force the exponent to be negative. may be enough. . .
Time for some more coffee 😉
You have put the <0 in the index but the solve block gives the desired result even without this constraint (as does genfit). Looks like expfit is in some way too sensitive wrt guesses.
@Werner_E wrote:
Time for some more coffee 😉
No, I think it's time to retire!
I think the conclusion so far is that you are better off using genfit or a solve block as opposed to expfit or you may fiddle around with the guesses.
I don't know if this would be an option but it looks to me that a modified exponential f(x)=a*exp(b/x) might make an equal good if not even a better fit and is only dependent on two parameters (BTW, as you can see in the pic, even changing the guess 1 to 2 makes expfit work OK):
Just to justify my coffee consumption, I've modified the attached file from the previous blunder.
One thing to note: change the TOL definition off and on, watch the results change!
Interesting observation - so the solve block is affected by TOL but expfit seems to be not.
I don't think that you should abandon you solve block - it might be that the constraint a[1 < 0 can be necessary for other data sets.
I am not sure if it better to use minerr (for which I have a tendency to) or minerr as you did. The results are marginally different and minerr seems not to be dependent on TOL.
For the two datasets given the constraint a[1<0 would not be necessary and if I change that to a[1 > 0 is has no effect at all ? 😞
Coffee seems to be the drug of day!
This morning, over a coffee, I had the idea to use genfit instead of expfit. And lo and behold, when I checked my e-mails I saw your solutions.
Thanks you both Werner and Fred
Raiko
"One more cup of coffee for the road.
One more cup of coffee before I go.
To the valley below".
Robert Plant (Led Zeppelin) - the song is by Bob Dylan
😉
the song is by Bob Dylan
Yes, 1976!