"Threshold 1D Array" for descending data?

[johnsold]

Partha,

Here is a 7.1 version. Not tested, just back converted. It should be OK. The original was developed in LV 5.1.

Lynn

[Matt_W1]

I've done some fooling around with waveforms and I think they can be used as efficiently as arrays or at least in the simple cases I tried. Basically you need to only use inplace functions on the Y data, and you need to pass the old waveform into the build waveform function when you put it back together(if you don't LabVIEW wont know that it can work inplace). I attached the vis I was using to test how it works, I added comments explaining what I think is going on (be sure to run it twice so the code is in memory, before trusting the numbers). I'm not sure what will happen in more complicated code though.

You can always overwrite the T0 and DY if you have better numbers for them (They're both doubles so they should be accurate enough). If you change the rate then a waveform can't be used at all though.

As for the show buffer allocations from what I can tell for it shows whether the output connector is an new object, or an inplace modified version of one of the inputs. And for the waveform (I'd assume clusters as well), changing the Y data doesn't require making a new waveform object (I guess it just changes a pointer to the data, note waveforms fall under "All other Types" in show buffer allocations). So I guess it doesn't help that much when working with waveforms or clusters.

I pretty certain that the waveform properties (which can be anything) are written as TDMS properties (which are limited to a few types). So if you start using that heavily be sure to only use types valid in TDMS properties (you could flatten other types to strings if you want to put anything in there).

Matt W

[LabVIEWFL]

Here you go.

Wrote it in Watlow C in 1990 highly optimized for speed to handle both increasing and decreasing values. Been using it for 27 years... This is the 2011 Version, but it has up-compiled through every LV version through the years (since 3.2?)

[crossrulz]

You should have waited another month and you could have been 10 years behind!

[LabVIEWFL]

: ) Always surprises me how these old threads still come up during searches and yet sometimes remain unresolved, figured I'd throw this nugget to the community. Since I wrote it in 1990, it was 17 years ahead of it's time, way before forums & blogs, I think the Watlow C Compiler is long gone. I'll bet there are still people struggling daily without a good solution such a basic problem. and NI has yet to alter the base functionality of the VI. I am surprised I haven't seen an Open G function over the years, but this one is a Windows only CIN.

Easy enough to compute, but difficult to execute in an optimized manner especially with large arrays and multiple iterations since this particular function is likely to be hammered - it better be as efficient as possible. I ran this CIN through heavy speed trials back then, it is one of my most used functions in sig analysis and measurement mainly because of the beautiful fractional index for interpolated accuracy! 

[Kevin_Price]

I was surprised to see this pop up again too, it's one of only a dozen or so threads I've ever started here.

At the time I posed the question, I had the understanding that the LabVIEW function 'Reverse 1D Array' would literally swap all the elements around in memory.  Some years and versions of LabVIEW later, I learned that several array operations like Reverse, Transpose, maybe others could perform much more efficiently.  Now they would would just attach some metadata to the array so that subsequent processing could treat it *as if* it were Reversed/Transposed/whatever, but the elements wouldn't literally get moved around in memory.   I don't honestly know when that more efficient treatment got introduced, whether before or after my original question.

I *did* end up using the binary search algorithm, sorry I never posted it.  But I now know that there'd be a memory efficient option to do Reverse->Threshold->Reverse which would have sufficed back in the day, if it was valid then and if I had known about it. 

I agree it's odd that the built-in function still doesn't inherently support decreasing data. 

-Kevin P

[LabVIEWFL]

Right? I don't even understand why the threshold needs increasing values. My Optimized Watcom C CIN is simply traversing the array forward riding ASC/DEC direction both up and down until it finds the target between two values and returns the fractional index (or the limits). A binary search needs to be sorted or in order, not sure how one would find a target value of unknown data content without first sorting the data, which is a large time hit. Originally I had played with G only array reversals also, but needed something lightning quick & efficient. Given that both the threshold and interpolate are such critically needed functions for evaluating a linearized guess between available data points, it made sense to implement low level. Maybe the array reversal is fast enough now, that was back in LV 3.0.1 (93?) back when the bulldozer was a scary icon of impending doom. 

it was probably the last C app I wrote before giving my soul over to LabVIEW : ) I 

[Hooovahh]

I feel like at any moment Altenbach will come in and demo some G solution that is crazy efficient and some how implements it with imaginary numbers, or some other crazy function I never use.  He's got a knack implementing very efficient G code and I'd be curious if he can make a similar function in pure G.

[Kevin_Price]

Well, to be fair, back in the thread's original era he already *did* suggest the winning idea...

-Kevin P