LabVIEW
Initialize Incremental Array
I've been having a short wrestling match with conversion and rounding of numbers between DBL and I32, but was apparently not sufficiently well prepared when I started. After being bitten in the derrière a good few times, I now have something that I think works (I've also scaled down my initial aim somewhat to make things easier). This will be used a lot, and I was wondering if someone could scan their eye over this code snippet to make sure I've not missed any potential hazards! 
This vi creates a 1D array in which the first element and step size are as entered, and the last element in the array is less than or equal to the value entered (depending on the step size). An empty array is returned if the first element is greater than the last.
P.S. Sorry for asking such a simple question, but I don't have anyone else where I work who can double check my code. 
Do you need to have the "Last Element" in the array regardless? If you have a start number of 2, an increment of 2, and an end of 5 you will not have the 5. The result will be {2,4}.
Also, since you are dealing with integers, you really should use the Quotient & Remainder instead of the Divide. It will save you a coersion and the round down.
Thank you both.
I've replaced the divide and round-down by the Quotient & Remainder (I'm always forgetting to use that) as suggested. To be honest, I hadn't even considered whether the user wanted to always have the last element in the array as well. I'll check with them, but thanks for pointing that out!
The downside of using the Ramp function is that it is using doubles. The OP is using integers. Seems kind of a waste of memory and processing.
@J.Mamakos wrote:
P.S. Sorry for asking such a simple question, but I don't have anyone else where I work who can double check my code.
Here's equivalent code (LV 8.5) that seems to give the same result with much less effort. if the difference is negative, N will be zero and the output array will be empty.
(There is no need to initialize the array and replace elements. Autoindexing is equally efficient and much simpler. You are doing way too much duplicate work by initializing the array filled will copies of the first element, then rewriting the first element once again in the first iteration of the FOR loop, then overwrite all other elements, one at a time.)
Note that my version allows a smaller end point if the increment is negative. Modify as needed.
P@Anand wrote:
@nathand wrote:
Have you looked at the Ramp Pattern function that is supplied with LabVIEW? It does what your VI does, although the inputs are set up slightly differently.
If he use the Ramp by Delta polymorphic instance then it is the very same what he is trying to do.
Ramp Pattern is available in LV8.5 (and is the equivalent of Ramp by Samples in later versions) but I do not have the Ramp by Delta version available to me. Is it possible for someone who has this vi to downgrade it for me? (Is that even possible when they use library call nodes?)
altenbach wrote:Here's equivalent code (LV 8.5) that seems to give the same result with much less effort. If the difference is negative, N will be zero and the output array will be empty.
(There is no need to initialize the array and replace elements. Autoindexing is equally efficient and much simpler. You are doing way too much duplicate work by initializing the array filled will copies of the first element, then rewriting the first element once again in the first iteration of the FOR loop, then overwrite all other elements, one at a time.)
[...image...]
Note that my version allows a smaller end point if the increment is negative. Modify as needed.
Thank you for the code feedback. Your method is indeed faster, more efficient, and handles more situations than my version. I realized that in mine, an Increment value of 0 would make LabVIEW run out of memory! I built my code based on the premise that sometimes initializing an array then replacing subsets is quicker than autoindexing; it seems I still need to learn when this is and isn't true.
I have since realized that I need to use this in two different locations (requiring I32 inputs in one case, and DBL in the other), so I created a polymorphic vi to handle these cases (with a little extra code when working with DBL to get round the representation 'errors'). This works fine and I learnt whilst doing so that the Quotient & Remainder primitive, though quicker when dealing with integers, is like a-particularly-slow-tortoise-on-a-lazy-day when dealing with DBL values!
@J.Mamakos wrote:
I built my code based on the premise that sometimes initializing an array then replacing subsets is quicker than autoindexing; it seems I still need to learn when this is and isn't true.
In the case of a FOR loop, the final array size of autoindexing outputs is known when the loop starts, so the compiler can efficiently allocate the exact amount of memory needed from the beginning. Very efficient!
