More Advanced Initialize Array

[DarkLordOfG]

We are all used to creating arrays with a for loop.  I have always wondered why there wasn't a simplier way to do this.

What about simplfying array creation with a more advanced Initialize Array.  Add another terminal that is just "increment" or "delta".  In the example below a double array of length 1000 with a starting value of .004 and an increment of .004 per element.

[altenbach]

You mean like Ramp Pattern?

[DarkLordOfG]

Exactly what I am looking for - Thanks!  Didn't think to search for Ramp or under signal generation.

[Darin.K]

Searching for the proper adjective here, it is (crazy, silly, annoying) that that function requires the Full Development system. I also look forward to the day when the G solution is fast enough so a CLFN is not used for this basic functionality.

[altenbach]

I think the CLFN is mostly to protect the FDS requirement. 😉

I never benchmarked this, but really how much slower is a homemade G version anyway?

[Darin.K]

Last time I checked, the Ramp VI could generate an array of DBL with specified start/stop and #samples in about 1/4 of the time it takes a For Loop to spin #samples time to generate a simple integer array and coerce it to DBL.

[X.]

It seems to be borne out by this not-so-clever VI (about 4 times longer for the G Ramp than for the C Ramp). But it becomes measurable (in ticks) only above 10^4 elements... So what is the need of the C Ramp, really, except for convenience? Let have the Open G people implement a G Ramp and that will be it.

PS: the weird structure comes from my clumsy attempt to optimize the timing performance. I also used this as a "Subroutine" VI just to be on the safe side.

[altenbach]

Well, I don't know why you add so much code! 😮 For 1M samples, my simple version is within 5% of the stock Ramp Pattern, in fact you would be hard pressed to see a difference unless you look at the 100pt running average shown in white.

The green trace indicates which version is active.

On the same benchmark, your version is about 2x slower.

[X.]

I (te)bow to that . The conclusion is the same: no need for the ramp VI... or for a new function for that matter.

[Darin.K]

New machine since I last checked. On my Quad Core, homemade is not far off. Still a factor of 3-4 on the old laptop. New CLFN with parallel code smokes both. The absolute times are not too shabby for most uses.

[JordanG]

Idea already exists http://zone.ni.com/reference/en-XX/help/371361H-01/lvanls/ramp_pattern/