LabVIEW
Which CPU can make the software run faster?
@Yamaeda wrote:
I like Rolfs idea, if you downsample to a reasonable amount, say 6000 points, you can have take max, min and avg for each group and plot them. Then you'd see spikes and trends.
If you want to do it correctly, you make each pixel in the graph 4 points: The first value, the max, the min and the last value.
If each sample has a constant interval, simply the min and max suffices. A 3rd or 4th point (the average, first or last value or any other value) will not be noticeable.
If you're data is chronological, but intervals are not fixed, the first and last values are required. A line between two pixel that have a gab without data needs to go from the last value of the first to the first value of the second.
Of course decimating the data escalates things quite a bit. The default legend can't be used anymore for selecting plot appearance. Turning on the plot points doesn't make any sense. Only line width and line style does. So if the user needs to select his\her own line color, style and width, you need to make something for that. Of course you probably don't want the user to select bar plots and such, you this needs (way to much) work anyway. If you want a nice right click menu to pick the line width, style and color, you have even more work cut out for you...
It still weirds me out that this isn't done by NI, while (even) if we do this things get a lot faster.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
It still weirds me out that this isn't done by NI, while (even) if we do this things get a lot faster.
You mean the data reduction? I think I can answer that. The min/max approach is one of several possible ones and not suited for every data set. There are instances where you want to rather have an average or some other approach. So simply plotting what is in the data, however inefficient it might be is the safest approach. This especially is true when you talk about non-evenly spaced data sets as you allude to. your approach of first, min, max and last sample per interval is just one of many possible ones and here the data to graph very much makes a difference.
@rolfk wrote:
wiebe@CARYA wrote:
It still weirds me out that this isn't done by NI, while (even) if we do this things get a lot faster.
You mean the data reduction? I think I can answer that. The min/max approach is one of several possible ones and not suited for every data set. There are instances where you want to rather have an average or some other approach. So simply plotting what is in the data, however inefficient it might be is the safest approach. This especially is true when you talk about non-evenly spaced data sets as you allude to. your approach of first, min, max and last sample per interval is just one of many possible ones and here the data to graph very much makes a difference.
I think we had this discussion before 😊.
The first, min, max, last approach will make the data look exactly the same as plotting all the data. It's not one of many possible options, it's the only one that makes chronological data look exactly the same as the original.
For general XY graphs, it's not suitable (e.g. very inefficient). If the XY data is chronological, but not evenly spaced, it is suitable and not noticeable. If it is chronological and evenly spaced, even more so.
Normal graphs\charts could do this without reservations. They will look the same. The min\max routine will not be noticed, except for the higher performance.
XY graphs could have this as an option.
The only problem is the plot points. But if you turn them on, the default drawing could be used for the points, while still drawing the 1st\min\max\last lines. It will be expensive, but still more efficient,
