General Polynomial Fit innacurate

[PGH]

Hi all,

I have some problems with the General Polynomial Fit vi that is part of the professional development package.  It is giving answers that are "not quite right" or just insanely wrong.  The symptoms vary with the fitting algorithm (e.g. the default SVD algorithm vs the Givens algorithm) and the polynomial order.

In the first example that I am attaching, the fitter works OK on this particular data set when the polynomial order is 3, but it introduces an erroneous DC offset when the polynomial order is 4.

If you want to see it be insanely wrong, try the 2nd file I'm attaching.  It will handle up to order 6.  First try order 4.  Same problem as before.  Then orders 5 and 6 are insanely wrong.  But what is fascinating is that if you go back to order 4, the VI will not function as before.  In order to get the first result, you have to close the VI and re-load it.  So besides a numerical problem, there is some other kind of failure going on.

I'm getting this effect on both PC's (Windows XP) and Macs (OSX).

I'm looking forward to your comments...

Sincerely,

Peter H.

[altenbach]

I think you are running into numeric errors because your data is basically a straight line and does not warrant any polynomial above 3. All higher terms a infinitely close to zero.

I agree that the polynomial fit should maybe better identify these conditions and return an error instead of poor data.

I don't quite understand your complicated formula node that you need to rewrite whenever you need a higher order than anticipated. The output for the "best fit" is right there! (see attached simplification). As you can see, the fit (givens) works pretty well with much higher orders.

If you need to calculate the polynomial for a new set of X-Values, use polynomial evaluation, feeding it the coefficients array and the new ramp..

Message Edited by altenbach on 08-31-2006 06:21 PM

[PGH]

Hi again,

Your comments helped.  It turns out that there were two problems.

First problem, the loss of accuracy at higher polynomial order:  Yes, the data is basically a straight line, but I *am* interested in the higher-order fit.  It seems that what was really throwing the fitter off was the large offset in the X (or in this case Temperature) axis.  By subtracting off the mean of the X values, so that the input to the fitter has both positive and negative values, I am able to get much better accuracy.  I check up to 8th order with the default algorithm, and get good fits.

The 2nd problem, the program "breaking" after attempting a high order fit turns is actually Mac-specific.  (The first problem happens on both PC and Mac).  The problem was that I use the array-to-cluster function as a short-cut to getting each array element.  If the array has fewer elements than the cluster output, then on a PC, labview always outputs a zero.  However on a Mac, it initially outputs a zero, but if the array grows to that size, then shrinks again, it outputs garbage.  (Actually it outputs whatever the last non-zero value was.)  To fix this, I have added an array padding-with-zeros step.

My "fixed" version is attached.

Your (i.e. altenbach's) "fixed" version is fine, and it helped me figure things out, but for other reasons I had to reconstruct the polynomial curve in this way.

Thanks again,

Peter H.

Message to National Intruments:  be aware of the difference between PC and Mac versions of the Array To Cluster VI.  It can bite you.  (Something to fix??)

[altenbach]

---

PGH wrote: The problem was that I use the array-to-cluster function as a short-cut to getting each array element.  If the array has fewer elements than the cluster output, then on a PC, labview always outputs a zero.  However on a Mac, it initially outputs a zero, but if the array grows to that size, then shrinks again, it outputs garbage. 

---

Well, first of all, that's not a shortcut, but a detour. (Even worse, you unbundle the same old stuff with every single loop iteration instead of only once before the loop). :o. A single expanded "index array" node will do the same just fine, you don't even need to wire the indices (see attached).

I agree that the MAC behavior is not right. Please file a bug report with NI or at least put small note and a link to this thread in the bug thread.

(I don't have a MAC, so I cannot verify the problem).

---

PGH wrote: Your (i.e. altenbach's) "fixed" version is fine, and it helped me figure things out, but for other reasons I had to reconstruct the polynomial curve in this way.

---

There are many ways to calculate a polynomial and the formula node is probably the worst. For fun I did a few alternatives and they all automatically adjust to the polynomial order used. (The "expicit loop" version can easily be modified to e.g. omit higher orders by wriring the N of the loop to a lower number). They all give the same result. 😉 (see attached)

Note that your formula loop iterates once per X value, while my loop iterates once per coefficient.

Message Edited by altenbach on 09-01-2006 04:54 PM

[PGH]

Hi again,

I didn't know you could do that with the index array function!  I learned someting.  By the way, it does not have the buggy behaviour on my mac that the array-to-cluster function has.

Why do you say "There are many ways to calculate a polynomial and the formula node is probably the worst."?  Is it less accurate?  The various ways you show are interesting, but I don't see why one would necessarily pick one method over another... Unless being able to handle an arbitrary order polynomial is necessary, in which case the formula node way fails.

As an aside, I have long wondered about how carefully National is about parsing the text inside a formula node.  I have noticed, for example, that within a formula node, data types are not always what they seem (e.g. I16 vs I32, extended precision...).

Sincerely,

Peter H.

[altenbach]

---

@PGH wrote:
Why do you say "There are many ways to calculate a polynomial and the formula node is probably the worst."?  Is it less accurate?  The various ways you show are interesting, but I don't see why one would necessarily pick one method over another... Unless being able to handle an arbitrary order polynomial is necessary, in which case the formula node way fails.

As an aside, I have long wondered about how carefully National is about parsing the text inside a formula node.  I have noticed, for example, that within a formula node, data types are not always what they seem (e.g. I16 vs I32, extended precision...).

---

Well, I simply don't like the formula node. 🙂 Compared to wires, It is clumsy and you cannot really debug (=place a probe or breakpoint) inside it. A simple spelling or syntax error easily breaks the entire thing and the mistake might be difficult to find.

Once you get the hang of it, wires are so much nicer.  😄 For example see how my loop automatically operates on the entire X array at once.

For seasoned C programmers, the presence of the formula node hinders the transition to "real" LabVIEW programming and they thus tend to miss out on the beauty, simplicity and power of dataflow.

Others may have different opinions, the above are mine.

The accuracy of the formula node is the same and you can define datatypes inside the formula node. You can even work on arrays directly.

[NathanT]

PGH,
      I tried reproducing the array to cluster behavior on a Mac by programmatically adding and then deleting elements from an array and using the array to cluster function after each change.  I did not see the "junk data" that you were talking about.  I have attached the VI that I made to test the behavior.  If you have a simple example VI that demonstrates this behavior on a Mac, please attach it, so I can reproduce it on my end and file a CAR.

Thanks,

NathanT