LabVIEW
All possible permutations (with repetition) of a 1D array given a new array size
Solved!
@aputman wrote:
As the dataset becomes larger, it may be better to calculate the total number of permutations, initialize an array to that size and update the values in-place.
My code does exactly that. Since N for the second loop (and it's inner loop) is known before the loop starts, the autoindexing output tunnel can, and will be fully allocated at once.
@aputman wrote:
Ah. I did not know that's how the auto-indexing works. Good to know.
Of course there are scenarios where explicit allocation is needed, for example if the compiler cannot tell the final size, but you know it from independent information. For example if the inner FOR loop does not always have the same number of iterations here but you know the largest, or if we are auto-indexing on while loop outputs. Of course if you know the number of while loop iterations, it should be replaced by a FOR loop anyway. 😄
Um, as I read the original Poster's Problem Statement, it occurs to me that many of the responders are being misled by the (incorrect, I believe) use of the word "permutation" in the title. In the example given, namely choosing three elements with repetition from [1, 2, 3, 4, 5], Altenbach is correct that this is equivalent to writing all three-digit numbers in base 5, a total of 5^3 values. The following direct code seems to run "instanteously" (there's no obvious pause while it runs) -- it might already be posted, in which case I apologize to the earlier poster for missing their post ...
@Bob_Schor wrote:
The following direct code seems to run "instanteously" (there's no obvious pause while it runs)
There is no such thing as instantaneously. With debugging disabled, it WILL run almost instantaneously, because of constant folding.
The main problem with your code is "scalability". You would need to almost rewrite the program from scratch for different numbers of digits (or write some complicated scripting code that would do it for you :D).
My code could of course be simplified to generate the numbers directly, but I intentionally made it even more scalable, because it is now trivial to adapt it to any other kind of input array (e.g. strings [one, two, three, four...], [cat, dog, cow, ...]; colorboxes, unevenly spaced numbers [1, 2, 3, 5, 8], enums , etc.)
Also note that my array reversal is just cosmetic to keep the element order as in the original example. I don't think speed is really an issue, you'll run out of memory well before you run out of time. 😄 (Well you generate I32, while I did it with 4x less memory :D)
But yes, here are two variations of your idea. The second is basically what the OP did, except in a better representations. There is no need for DBL to distiguish 5 values.
(I am not sure if it is better to build the three element array incrementally (like in your example) or once (as below). Doing the +1 as in your example is probably more efficient)
@altenbach wrote:
@ altenbach
Is that iterative calculation for number of combinations any better than using the Power of X function?
Mancho00 wrote:@ altenbach
Is that iterative calculation for number of combinations any better than using the Power of X function?
Define "better". 🙂 We are dealing with small numbers, so that loop completes in nanoseconds, basically for free. Power of x requires floating point, thus requiring two coercions (first at the function input and later wired to N) and math on twice as many bytes. Seems ugly. 🙂
Of course you also need to ensure that the loop output is correct for strange inputs. Mine is correct for 0 to the power of 0 equal 1, for example. Of course it will not work for negative powers or anything that uses or results in fractions, etc.
