In "Sort 1D array" node uses can get both ascending and descending ordered elements

[foolooo]

With "Sort 1D array", we can get ascending ordered elements, as below.

 But in practice,  the chances of using elements with ascending order and descending order are almost the same. Thus it will be helpful to add a node returns the descending ordered elements, or users are able to select between two options within one node. Although we can reverse the array after "ascending sorting" to achieve a descending order, it costs extra CPU and memory.

[AristosQueue (NI)]

> Although we can reverse the array after "ascending sorting" to achieve a descending order, it costs extra CPU and memory.

No. The "Reverse Array" primitive just sets a flag on the wire that tells all downstream operations to use the end of the array as the front.  The array doesn't have to actually be shifted around in memory. If it crosses a subVI boundary, yes, there it has to actually be reordered because the flag doesn't propagate into the subVI along with the data, but that is something that is expected to change in the next couple versions of LabVIEW.  If we get the compiler to handle that boundary, I believe it negates the need for the option on the Sort primitive. 

On the other hand, providing a mechanism for arbitrarily sorting the array -- for example, passing in a VI refnum that has the comparison function -- is an idea that could likely gain large support and significant traction if the kudos were high enough. 

[foolooo]

Hi Aristos,

Thank you for your reply. And I learned from it that 'reverse' doesn't cost mem or CPU, which is a good new for me. Cheers.

Best wishes,

Bo

[tst]

> providing a mechanism for arbitrarily sorting the array -- for example, passing in a VI refnum that has the comparison function -- is an idea that could likely gain large support

How is that different from simply writing a sorting VI with the array as input and output?

[AristosQueue (NI)]

The overall framework of an efficient sort is tricky to get right, and really, there's no reason to rewrite the framework if you can replace just the comparison operation portion of the sort. Most programming languages at some point develop a way of passing a comparison function into sort so that people can stop writing sort itself over and over and over again. LV is deficient in this area.

[ouadji]

"Most programming languages at some point develop a way of passing a comparison function into sort ....."

kudos for Aristos Queue