LabVIEW
parametic test loops
Solved!
ShotSimon wrote:I must be doing something wrong. I went and added another loop to create another parametric parameter ~150,000 x 4 parameters.
Allocating the output array once and doing things "in place" is the right thing to do. Keeping track of the insert point is trivial.
Try this:
My solution was very close but I was still missing the index shift register on the inner loop? I guess I still don't understand why I can't use the index on the inner most loop as the row index
Thank you for saving me some time figuring this out. -SS
I get it now, every index choice rolls from 0 to N. So we need an index that only changes once per every four loops! Excellent little solution.
When you get a chance could you explain how you can do things entirely inside the loops? That is remove the four initialization loops?
-SS
ShotSimon wrote:When you get a chance could you explain how you can do things entirely inside the loops?
I am currently on vacation in a hotel room in the middle of nowhere. I'm not sure how much time I'll have in the next few days. 🙂
(I agree, there is way too much duplicate code, still.)
ShotSimon wrote:When you get a chance could you explain how you can do things entirely inside the loops? That is remove the four initialization loops?
Well, it's quite simple.
- You would just calculate the array elements on the fly inside each of the stacked loops (see option 1).
- If you don't want to use the shift regsiters, you can just built it in autoidenxing output tunnels and reshape later (see option 2)
- You could even get away with a single FOR loop if you do some fancy math (see option 3, also attached).
- There are many other possibilities
Note that these three solutions probably differ somewhat in performance, but it's probably not worth worrying about it unless you need gigantic arrays. Can you guess which one is best? 🙂
Oh, btw, you should really change the display format of your controls. It is very annoying to have it display 0 digits of precision, but have the increment set at 0.25. This means that 75% of all presses on the increment/decrement buttons have no visible effect, but still change the data.
(I have not changed this in my versions above.)
Altenbach,
That solution is really amazing. I didn't realize my increment was set the way it was, sorry about that. I timed the code and I believe you improved the timing by a factor of three with the third version. -SS
Altenbach,
OK this solution is very good for another reason. If I want to add other parameters, it's simply a matter of increasing the size of the Index and Build Array Functions and adding another Quotient & Remainder Function. This is much easier then adding in FOR loops and such.
I'm still curious how I could make this routine such that if the user added more parameters on the input array it would simple accomidate this and create the corresponding parametric outputs. It seems so close the way it's written.
Sorry I realize I might be driving you nuts, so forgive me in advance
-SS
ShotSimon wrote:I'm still curious how I could make this routine such that if the user added more parameters on the input array it would simple accomidate this and create the corresponding parametric outputs. It seems so close the way it's written.
Anything repetitive can probably be written using an autoindexig FOR loop. 😄
In this particular case the only problem is that we need to reverse the array for the inner loop, but that's probably not such a big deal.
(If you don't reverse, you simply get the solution sorted differently, that might be OK too. Try it!)
Here's a quick draft. Makes sense?
This code is getting more compact with each version... 😉
