Actually, it is not just "some historical versions" of Perl: it is one of the most important properties of hashes that the order of pairs they hold is (for all intents and purposes) random. Most importantly, adding a single pair to a hash may lead to getting the pairs back in an entirely different order. This order is of course not actually random: it's deterministic if you know the hash lookup function. That however may change between different versions and ports of Perl; if nothing else, then this alone means scripts have no business assuming anything about it. | [reply] |
I saw a sorted hash pm somewhere, either in the examples for tie or maybe in Conway's book.
| [reply] |
That would be implemented as a tied hash which only looks like a one, but really is an object.
| [reply] |
Hmm, I thought your code was idempotent: it would find the parts in any location of the string. So it should swollow the parts in the wrong order, or you can try the parts in any order. You delete out of the string each one you find, so anything left is stuff you didn't recognise and that causes an error, when you're done with everything you do know.
If it's not, get rid of the ^ and give it a spin.
—John
P.S. it's the to_string you want the correct order for, right? That wasn't part of the original problem, but that's not a problem:
@value_sorted_keys= sort { $x{a} <=> $x{b} } (keys %x);
| [reply]
[d/l] |
It is true that it would find them in any order, but that if there were duplicates, it would generate an error. I wasn't sure if there might be some circumstance where '3s2m' might be valid input. Hey, you never know!
You need the correct order for the encoding only, yes, not the decoding. The only reason I made that function was for the sake of completeness, and to validate that my decodes were correct using the test harness.
A definition of
idempotent for the curious.
| [reply] |