Building an evenly spaced array

[falkpl]

One additional point on my code is to make it polymorphic, so interger array builds do not have type casting slowing them down.  Any one know how labview G implementation compares to matlab (matlab has a tic operation for speed profiling)  I cant think of a method which is not dominated by the indexing

of the array (independent of the array manipulation) which would always have to be O(n) any way you look at it it wont be the bottleneck in a program.

Paul

[shoneill]

Oh well,

I do remember reading about the compiler "Folding" constants in order to increase execution speed, but it obviously doesn't apply to loops.

The only two options still remain either storage as a constant or on-the-fly generation.  Once the generation isn't performed parallel to timing-critical operations, I don't think it should really be a problem.

As to practical solutions, there have already been enough given.

Well, I've learned something at least.

Shane.

[Robert.Bedford]

Okay.  Each method outlined in this thread has been put head-to-head.  To make things even, I made sure they all did the following:
1)They must include an offset
2)They must accomodate a non-unity step size
3)They must write their results to an array indicator - As an asside, there was only one element viewable on the screen.  While I am sure this makes a difference, it should still be a good direct comparison because this was the same in each.  In comparison, "computation times" were roughly 40% shorter if the output was not wired to an indicator.

I made a loop to create arrays of size 1E4,1E5,1E6, and 1E7, and used the ms counter to time the building of the array.  I repeated each technique 50 times for each array size, saved the results into an array, and wrote them to disk (writing to disk was outside the timed loop). The graph is attached, and it seems that altenbach has the best method, and I do have to admit that it is a clever technique... I never though of using a ramp function.

Cheers, and thanks.
Robert

[PJS]

I did run this experiment using LabVIEW 8 and the math script function on a P3.2GHz XP machine with 1GB of ram and Ultra 320 SCSI drives.  See attached jpg for the diagram. Pretty straight forward.  Well, for starters, this VI loads ~673 subVIs.  It will not fully execute the 1e7 loop, it gives a LabVIEW out of memory error.  Going from 1 step to the next is a x10 increase in time, starting at 1e4=~7.46mS, 1e5=~75.5mS, 1e6=~798.12mS and as I stated, it would not execute the 1e7 loop.  I did not play around with altering the script to accomplish this differently. math script is a dead horse for this implementation. 

FYI

Paul

Message Edited by Pana-man on 11-17-2005 03:13 PM

[PJS]

Another thought to increase speed would be to pre-initialize the array and replace the values in the loop.  Should drastically reduce the time required to build the output.  A quick experiment (using LV8..Not a level playing field given a different machine and LV version.) gave me times of .3mS, 3.3mS, 38.4mS, and 393.3mS on average.  Note again the x10 increase in time.  At least that is consistant. 

[Robert.Bedford]

Replacing the values in the loop is not generally an option in my application, except for potentially using @dynamik's technique and simply storing an index array (1:N) and simply multiplying that by a step and adding an offset to achieve the same thing.  This would not be a bad idea.  You got me thinking that one can decrease the number of for loops by operating on arrays.  Imagine the following:
N (the size of the array) is a multiple of 10.
To build up a indexed array (1:N or 0:N-1), first build a single array 1:N/10.  then truncate 10 arrays such that 1:N/10 to N/10+1:2N/10 to 2N/10:3N/10 and so on.  The number of loop iterations will be N/10+10, but there are some extra mathematics.  I tried this and the results were *worse* than any of the previous results (computation times typically doubled).  Is this just a mechanism of operating on arrays instead of scalar values? 

[Robert.Bedford]

by the way, running in matlab for arrays 1E4,1E5,1E6, and 1E7, average times were 1.7ms, 15.7ms, 16.6ms, and 206.5ms, respectively.  This is sans labview.  I tried 1E8, but it could not compute due to memory limitations.

Cheers all, and thanks for your input.

-R

[PJS]

Using the ramp function and calculating the samples input such that you get the increment desired, using LabVIEW 8, I got 0.7, 2.16,15.66 and 238.28.  BTW, thanks for the suggestion, it has been built into a utility for my toolbox. 

Well back to work.

[altenbach]

A FOR loop knows exactly how many times it will run right before it executes, so all autoindexing outputs can (and will) be fully allocated in one step. There is nothing to improve from the memory allocation point of view.

There is no need jump through extra hoops. 🙂

It probably will be slightly more efficient to do all the "math" inside one loop as in my example (not the ramp pattern version). Don't forget that your array operations are also "intrinsic loops" which again rattle through all elements of the array from begining to end. Each array element must be touched three times after the loop, first for the coercion (very bad because the entire array needs to be reallocated because it needs twice as many bits I32->DBL!), then for the multiply and add array operation.

For more information, study e.g. Application Note 168.

Paul, of course mathscript carries quite a bit more baggage, dictated by the universal functionality. Most likely, extra copies of the array are generated somewhere, leading to your memory problems at bigger array sizes.

[PJS]

It is not that I expected otherwise, but that was the first question asked in this thread.  Just sewing up the details....

Again, thanks for the ramp suggestion.