Sort File path x.x.x

[altenbach]

---

@James_W wrote:
I can't for the life of me see how [i] helps here.

 James

---

the [i] contains the original index, which after sorting will tell you where it was so you can re-build the array in the new (now sorted!) order.

(It really would help if you could fill some reasonable default data into the control of the snippet, so we have something to test.)

[altenbach]

Here's how it would look when sorting numerically. Note that this avoids formatting back to a string. (Note that you don't need to convert the array to a cluster in either case)

[altenbach]

Also note that if the numbers are typically small and there are only up to four, you could read it as U8 array, then pad (to 4 elements) and cast it to a single U32 value for sorting. The cluster elements of the array to be sorted would only contain a U32(data) and I32(index). Might be more efficient.

(Using U64 you could go up to 8 elements. If the numbers are <16 you could pack 16 values into a U64, 4 bits/number) 

[James_W]

---

@altenbach wrote:

---

@James_W wrote:
I can't for the life of me see how [i] helps here.

 James

---

(It really would help if you could fill some reasonable default data into the control of the snippet, so we have something to test.)

---

Ahh, The default data was the string constant being processed in Message 7.

Now I understand why you are looking at the [i] and indexing. it is indeed so much faster, but given my problem as redefined (in code with comments) in message 7 and the test code to drop the test VI into includes alpha chars in the sort. I'm happy with my solution, but agree for a numeric sort it could be further optimised.

(I'm sure you're not happy and will find a further optimisation of my code even now though.)

- Note I did say I did find a bug in the test code expected result. The VI I posted gives me the result I should have expected if I had paid attention to my rules when creating the test code.

James

[altenbach · Accepted solution]

wrote:
Ahh, The default data was the string constant being processed in Message 7.

---

OK, I see. Your problem is that some of your sorting is unnatural (e.g. x.x.2a vs x.x.2.a). as you can see here where my code fails (note that you don't need to create an inner cluster).

 

[James_W]

---

@altenbach wrote:

wrote:
Ahh, The default data was the string constant being processed in Message 7.

---

OK, I see. Your problem is that some of your sorting is unnatural (e.g. x.x.2a vs x.x.2.a). as you can see here where my code fails (note that you don't need to create an inner cluster).

---

Ahh, slightly simpler again and the slightly faster optimisation that I always expect you to find somehow. I bow to your wisdom again!

Yes, as I did say, my initial code string did not follow my sorting rules and your code just highlights that.

Thanks Christian.

Out of interest... Is there any reason why the riffle function always seems to return the same randomisation of that aray? (or is it just my visual impression.)

James

[altenbach]

---

@James_W wrote: 

Out of interest... Is there any reason why the riffle function always seems to return the same randomisation of that aray? (or is it just my visual impression.)

---

It does not, unless you wire the "seed" input with a constant as you do!!. This is a mistake! Make sure to leave that disconnected.

(You can look inside to see what happens if "seed>0" :D)

[James_W]

---

@altenbach wrote:

---

@James_W wrote: 

Out of interest... Is there any reason why the riffle function always seems to return the same randomisation of that aray? (or is it just my visual impression.)

---

It does not, unless you wire the "seed" input with a constant as you do!!. This is a mistake! Make sure to leave that disconnected.

(You can look inside to see what happens if "seed>0" :D)

---

Doh!