I found Error in Statistics Express about the algorithm for mode

[jingli]

LabVIEW 7.1 was used. today I acquired a lot of data and analyzed using Statistics Express in LabVIEW 7.1, whereas the results of mode were not correct because I analyzed the data using both Excel and SPSS. so I think there must be something wrong with Statistics Express in LabVIEW 7.1. Attached is the data which mode is 57.24 by SPSS, but the result of Statistics Express showed the result of 32.608.
will someone please help me?

thanks

[altenbach]

Good catch, these seems to be a bug in the express VI.

Mode uses mode.vi, which in turn uses histogram.vi. Both need an input for the number of intervals, which otherwise defaults to "1". To get meaningful data in your case, the interval needs to be set to a much higher number, but it is left unwired deep inside the express VI for statistics and it thus only uses a histogram with a single bin! Not very useful. Please report this to NI.

As a workaround, use the mode.vi in "Analyze..Math..Probablility and statistics" and explicitly wire the "intervals" input. In your case I set intervals to 1000 and the mode was now 57.22, 10000 gave a mode of 57.24.

[jingli]

Thank you very much.
I think it is very important,too, so i contact Ni today.

Thanks again

[Leeser]

Hi all,

Using LabVIEW 8.2 and I have come across this error again but not only in the express mode but in the "mathematics...prob&statistics...mode.vi" . As I had already called this mode.vi previously in my program, it outputs the result from that first operation (but with 2 places of decimals only!) again. In the Statistics Express version, the mode, arithmetic mean, median all give the correct answer but when wired to an indicator it gives the result from the first mode operation! When I wire the intervals it returns the correct value. Maybe there is or needs to be a "reset" on the mode operation?

Regards,

Leeser 

[altenbach]

Could you make a small example that shows the problem?

Outputting a certain number of decimal places is typically a cosmetic property on how the indicator is formatted. So I am not sure what you mean.

[Leeser]

Hi,

I agree the 2 places of decimals is a cosmetic property and I have no issue with that....

I have my vi setup such that at one call it gets the mode of distances between points on lines. The second time I call the mode it is to get the mode of distances between another set of points. Two separate arrays in a fairly large program. I've attached a shortened sample hopefully the error still appears. Also I was wrong about wiring the intervals wire, this did not change anything.

If I run the 2nd mode operation on it's own without the previous call it works fine, only when there is a previous mode operation does it fail to "re-initialise" and returns the result of the first mode operation.

The only thing I can think of is that the first set of data has many different distances and gives a clear mode, whereas the second set has values approximately the same, with the odd multiple (ie 20,22,19,41,62,20,21,23). However, going against this is the Express Statistics vi which calculates the correct values in the Express Window (double clicking on it and selecting the statistics) but when wiring these to an indicator the result from the first mode operation is returned.

Any suggestions welcomed.

Kind regards,

Leeser

[DuffmanSays]

Hello Leeser,

I can definitely confirm the behavior that you are talking about in the VI you have attached. What's interesting is that if you swap the frames after you've run the VI, the values stay locked to 14.98 even if you delete that entire data set. However, if you swap the frames before the VI runs the values do not get locked to 14.98.

When trying to further characterize this behavior to report this to R&D, I cannot recreate this from a blank VI. Namely, if I generate two arrays of data and wire them to the Mode VI, each result shows up correctly (VI is attached for you to test as well). So, I am curious to know if you can build a new VI with a basic set of data that will show the same result. Please let me know if you have any additional information about when this can be seen so that we can try to determine the cause. Thanks very much for your time!

Mike D.
National Instruments
Applications Engineer

Message Edited by Duffman Says: on 06-28-2007 11:25 AM

[JeffBoettcher]

Just FYI - I took a quick look at this, and it seems it might be related to the IMAQ VI used to calculate distance.  I replaced the use of it (because I didn't have IMAQ installed) with a simple implementation of the distance formula I threw together quick, and the problem went away.

That said, I have no idea at this point what could cause that VI to interfere with the mode calculation, I'm just posting my observation.  Incidentally, I've never actually seen the problem (since I don't have IMAQ), but it sounds like Duffman did.

[Leeser]

Hiya,

I tried your suggestion of replacing the IMAQ distance vi with a straight forward formula node. Checked that they gave the same distances as output (they did! phew!) and connected up to mode. Still got the same problem.

I went back over my program and I actually use 3 instances of the mode. The 1st call works fine and outputs the correct result. The 2nd call also works fine and outputs the correct result. The 3rd call outputs the result from the previous call.

I tried to reinitialise the mode vi by setting up an array consisting of 0's getting the mode and then inputting my distance array into the mode vi. However, this gave me a mode of 0! Thought I was onto something and looped my distance data 3 times but only got a mode of NaN.

As most of the values I use in the final mode operation are close to integer multiples I can get around this problem and use a "weighted mean" but it is an interesting bug!!

Regards,

Leeser