I am using 2009 SP1 For orders 0-3 it seems to works. Orders 4 and above produce results that at so clearly not a best fit I can imagine how its possible. I've seen other posts about this but no one seems to fully acknowledge that this is clearly a bug. The other techniques work well, by eye anyway, and totally agree with each other for the least squared fit. Can anyone explain this? Does NI have a bug report for this? Does 2010 still have this issue? I am attaching a vi with my data set and a loop so you can play with the fits and watch the non-sense.

Floating point numbers are stored in a format mantissa*2^(exp), with a specified number of bits to store each. Lets say you use m bits to store the mantissa and n for the exponent. Typically, the leading bit of the mantissa is assumed to be one, so you effectively have m+1 bits. The smallest increment you can represent is (1/2^{m+1})*2^n or 2^(n-m-1). As the number increases, the increment increases as well, that is why we normally say you have x digits for a given representation. The accuracy, as expressed by the magnitude of that last digit, depends on the size of the number. What is my point? Scaling X works in this case because the smallest X values are not fully exploiting all of the bits at their disposal. Dividing by say 10^4 doesn't effect the accuracy of the small number representations but helps dramatically on the large X values raised to large powers. At some point you start losing information on the small X values and scaling no longer helps. Then you either declare victory, change algorithms, change representations, change the problem, or move on. The Givens and Householder (I always use Householder) transformations are inherently effective with these type problems (no coincidence why they are popular). Most algorithms include scaling steps to increase numerical stability.

ni.com is currently undergoing scheduled maintenance.

Some services may be unavailable at this time. Please contact us for help or try again later.

LabVIEW

General polynomial fit SVD method produces obviously wrong bad fit

Solved!

Actually, I'm not sure marking posts a solution was even available 5 years ago!

I appreciate you coming back and adding more interesting information about your problem.

Message 11 of 11

(393 Views)

LabVIEW

General polynomial fit SVD method produces obviously wrong bad fit

Re: General polynomial fit SVD method produces obviously wrong bad fit