The code manually derives the expression fm(x1,x2,x3,...,xk) for
the equally spaced points in (k+1) dimensions, where m is the order of the approximation f.
x1=[6 7 8 5 3 2 1 2 5 8];
x2=[9 7 0 8 5 6 4 3 2 10];
y=[9 7 6 4 3 2 5 6 8 1];
x1=[6 7 8 5 3 2 1 2 5 8 5 4];
x2=[9 7 0 8 5 6 4 3 2 10 5 7];
x3=[8 9 7 6 5 4 3 5 6 7 5 3];
y=[9 7 6 4 3 2 5 6 8 1 8 0];
Hi, Is there a way to use this code with the constraint that the parameter estimates are positive?
Thank you !
I'll repeat what is stated in the requirements: You will need Maple to be able to use this code.
If this is an inconvenience, then you should check John D'Errico's
polyfitn.m function also here on the FEX.
You're right, this is due to the new MUPAD engine. On MATLAB versions earlier than the MuPad era the code should work fine. I will try to fix this problem as soon as possible.
at STRB2 function is probably infinite while loop problem
This looks like it would be nice, though I do not have the symbolic TB to put it through its paces, so I will not offer a rating. It is an alternative to my own polyfitn, with output directly into a sym form.
A couple of comments. (Surely you would not expect me to have nothing to say.) Good help. I like to see verbose help, even when some others have been known to say my help is too verbose. I want all of the questions answered in my help, and this help made an effort. I like the examples. Error checks, and an H1 line. All good.
The code itself looks like it was carefully written, but as I said, I could not test it. I had a couple of style points though. I'd rarely recommend the use of variable names like "kkksdgsdg". When you need to debug the code, reading it will be more difficult in a year or so because of a randomly chosen string of characters. I know, sometimes it is difficult to come up with a mnemonic name, but you can try harder than that.
Also, use internal comments. This code has virtually none, except for a credit to Roger Stafford. (Well done there. It is always good to give credit where it is due.) Those internal comments make your code readable. they allow a reader to follow your code and your thoughts as you wrote it. Those comments take less time than you think to write, but they are worth their weight in gold when you need to read even your own code next year.
Finally, I'm not sure I like this style of error message:
error('MSG:ID3','lengths of martices x and y need to be the same')
If you will use a message identifier, why not provide a descriptive name instead of MSG:ID3? This reminds me of the old days writing IBM Fortran code, where each programmer learned the meaning of cryptic error messages, identified only by a few characters and a 3 digit number. We then had a manual that offered an even more cryptic explanation of that error code, if you wanted to dig for it.
If you liked this submission please rate it! :)