LabVIEW
simplify array by removing duplicates
Solved!
@JÞB wrote:
Not as neat as it could be. Tip: Any time you find a comparison output wired to a case selector And the input to the compare is on a tunnel of that same case. Think about the Rube Goldberg thread you might show up as a victim
String to Number functions work on arrays. Nice job though
EDIT: My eyes popped out when I look again. Get rid of the Transpose and wire the "2" to the Col input leaving Row unwired will slice by column
@Jeff sorry, i don't know why i didn't address you directly but in third person only
regarding the transpose ... lol .. thx, somehow i missed that very much too 😉
TIL "decimal string to number" works on arrays, never used it that way.
regarding the rube goldberg, i guess i don't understand you all that well there, could you provide a negative example please (not trolling, really curious)
... thinking a little more ... you mean, that i had the extra case structure which you put into the first one?
i guess all the "errors" show the way/stages i worked through the problem
that was fun 😉
and for posterity:
@altenbach very nice solution, will be studied, did not spend a thought about runtimes, and never used variants this way .. i really should regard them more as dictionaries
could not edit my post anymore
OT: nice, was confused for a second .. the interface for picture upload changed between postings
@jwscs wrote:
could not edit my post anymore
OT: nice, was confused for a second .. the interface for picture upload changed between postings
Actually, if you look a lot harder
you had two case structures with the exact same conditions. Found String Not? (Index -1, or default) and Found Index <0 = True/False. Since the -1, Default and Less than 0=True, False are just plain the same for the output of Search 1D array. You get an Honorable Mention on the R-G thread (I see you posted it yourself NICE!)
Well documented Explanation! Kudos
now, could you improve it? (the optimizer in the compiler probably migrates this anyway BUT)
i have not looked at the spoiler yet
but i am guessing, because i still know way to little about how the compiler optimizes stuff.
Update: seems this is what you had in mind
Update2: props to altenbach ... i like this solution more and more
@jwscs wrote:
i have not looked at the spoiler yet
but i am guessing, because i still know way to little about how the compiler optimizes stuff.
Update: seems this is what you had in mind
Update2: props to altenbach ... i like this solution more and more
Altenbach deserves the props! and bingo on the modification. Very few people know exactly what that option for the optimizer slide bar really does in the tools-options dialog (and many who do know won't tell you because its an undocumented feature) What do the terms mean?
And which optimizations cut out when? Which exist?
This is a fairly simple vi and the code complexity is... UNKNOWN! Snippets don't drop on the new interface. Going over to Feedback to solve that!
But, the Code complexity of that snip should "Rarely Limit" full optimization.
So if we don't want to use variants, we could still do it at least without case structures. 😄
Here's my original variant version and below the version without case structures (LabVIEW 2014. Make sure it works correctly. One limitation is that the string entry cannot be an empty string).
Jump on Value Changed.vim my friend.
I think the variant solution was more elegant as modified by jwscs. A Benchmark could prove me wrong again, show I'm right again, or do both at the same time. That difference would be trivial. Yet, I do like to learn as I go.
If you can show a faster lookup than that Variant trick - You have been holding back!
I do not see the limitation (I learn something new every day) Unless its the (maybe ) error out of Variant to Data
@JÞB wrote:
I think the variant solution was more elegant as modified by jwscs.
I am not so sure. One of the problems is that allocating all these extra 1D arrays (2 strings and 1 numeric) before the loop costs more memory. Mine works exclusively (and intentionally) on scalars inside the loop. He also has twice the number of auto-indexing input tunnels on the loop. One is enough. 😄
I haven't done any benchmarks and doubt there is a big difference in speed. For smallish inputs it does not matter anyway.
@altenbach wrote:
@JÞB wrote:
I think the variant solution was more elegant as modified by jwscs.
I am not so sure. One of the problems is that allocating all these extra 1D arrays (2 strings and 1 numeric) before the loop costs more memory. Mine works exclusively (and intentionally) on scalars inside the loop. He also has twice the number of auto-indexing input tunnels on the loop. One is enough. 😄
I haven't done any benchmarks and doubt there is a big difference in speed. For smallish inputs it does not matter anyway.
If LabVIEW ever offered ragged arrays... I'd grant that argument for this example. UNLESS, I'm about to learn something I had always assumed that the number of auto-indexing input tunnels into a Loop did not affect performance But, I usually deal with "Test" where the UUT is the bottleneck. I don't dive to Si
Always willing to learn a lesson.
@JÞB wrote:
I had always assumed the the number of auto-indexing input tunnels into a Loop did not affect performance
I was thinking more about code readability. There is probably no difference in performance. (of course LabVIEW probably needs to check all the array sizes and pick the shortest to determine the number of iterations, but that's peanuts. :D)
