Reverse order indexing for Map on for loop

[TiTou]

When indexing a map on a for loop, the indexing is automatically done by ascending order on the key value.

I like this as a default behavior.

I'd like to have a context menu option to force the for loop indexation to be done in reverse order.

[wiebe@CARYA]

Just for maps? Or also for sets? Arrays are easy to reverse 'manually', but if it's added for maps, and sets, why not for all 'containers'?

Alternatively, maps and sets could get a flag (conceptually) that would make 'Reverse 1D Array" work on them:

(This could internally be implemented with a SubMap, SubSet structure, like SubArrays and SubStrings do for arrays and strings.)

AFAIC, This would qualify as a detail of your idea ("Reverse order indexing for Map on for loop")...

[Hooovahh]

I was kinda hoping that the Index function would work on maps, and then you could just index the map at ([Map Size] - i) - 1 but that doesn't work either.  Maybe this idea could be that more array functions could work on maps.

[AristosQueue (NI)]

Hoovah: Indexing deliberately does not work on sets or maps. They are not directly indexable data structures the way arrays are, and if you need indexing, you should use a different data structure. Every "index" into them would be a full linear traverse to that point in the structure. Not the right choice.

[AristosQueue (NI)]

The reverseability (via flagging) and the reverse indexing are both good suggestions. I'll add my personal kudos.

[pauldavey]

I am not sure I think the reverseability via flagging is a good idea, to be honest (although I would find it useful).  When you access elements in an array, you have no expectations on the order of the elements (they are what they are), since there is no built-in sorting, but when you access a map (or set), you expect the keys to be in ascending order (it is part of the data type). If somewhere upstream this flag has been set, that expectation is broken.  It will surely cause bugs.  You would need a "sort keys/set" function to ensure the integrity, which then defeats the whole purpose of using them.

[AristosQueue (NI)]

Kicked the tires on this some more...

The original idea is still a good idea. Weibe's extension for a "Reverse Container" node might be a good idea, but it is a substantial amount of work, and I think the downsides have the potential to make it a bad idea.

Adding a "Reverse Container" node would require introducing entirely new data type wires for "reversed map" and "reversed set" because order of sets and maps is based on data type directly. Any collection of the same element type but with a different ordering scheme is literally a different container data type. Trying to crosswire those results in algorithms that don't work (look at the code for all the VIMs in the Sets palette that do math ops on sets if you want some easy, obvious examples). We therefore need to be able to break the wire if you tried to connect a reversed map wire to a regular map terminal (same for set). The under-the-hood implementation could still be setting a flag, but the type propagation has to be compile-time known. And because they are different types, any generic algorithms that combine two or more containers would need ways of differentiating the two cases, and you'd need to turn lots of helper functions into VIMs if you want to reuse them. That overhead could push the whole idea into being a bad idea.

Adding an option on an input indexing tunnel to do reverse indexing doesn't require that type extension and could be done for all input indexing tunnels.

[wiebe@CARYA]

>Adding an option on an input indexing tunnel to do reverse indexing doesn't require that type extension and could be done for all input indexing tunnels.

That would be great. It seemed to be more work from the outside

Other languages (C++) reverse the iterator, not the map. That's probably a good clue to reverse at the tunnel.

I see the problems with a flag and generics. This could be a compromise: with functions to get the direction we could work probably with it, but you'd loose the compile time optimizations. But it does smells.

[wiebe@CARYA]

A fast search online seems to confirm my recollection that map implementations often do not have any specified ordering. Languages usually specify that the ordering is not specified, but guarantee it is consistent (in a specific release?).

Does LabVIEW specify how a map is ordered? I suspect simply = and > (or =>). But if it isn't specified, could it change between versions (OS, RT, 32/64 bit, LV version)?

If you depend on reversing the order, does this imply a certain ordering is expected? And can we expect a certain ordering? 

Reversing an unspecified ordering does seem slightly weird. But since it's guaranteed to be consistent it could still be useful.

Just wandering...

[AristosQueue (NI)]

Yes, we absolutely specify and guarantee the ordering. I talked about that in one of my 2019 presentations to some group of customers (yeah, memory has faded out!). The ordered sets and ordered maps are far more useful in key contexts specific to test and measurement, and we had no interest in trying to expand LV to have four different data types (ordered map, unordered map, ordered set, unordered set), which is the common language pattern.