Re: [tlug] Are ordered hashes useful?

[Raymond Wan <rwan.kyoto@example.com>]

On Fri, Feb 11, 2011 at 11:03 PM, Josh Glover <jmglov@example.com> wrote:
> On 11 February 2011 13:09, Kenneth Burling <burlingk@example.com> wrote:
>
>> My understanding of Hashes was that Hash keys are quite often a way of
>> getting away from the need for predictable ordering.
>
> That's one reason. Some others are:
>
> * O(1)--i.e. constant time--access
> * meaningful indexes; you often do stuff like this: my_hash.each.map
> {|key, val| key =~ /foo/ ? something(val) : something_else(bar) }
> * human-readable params in languages that do not natively support
> named params (Python does, Ruby 1.8--and 1.9 as well, IIRC--and Perl
> do not)
>
> I'm sure I'm missing some other good uses for hashes. :)


Actually, I think there are conflicting definitions of hashing and
they seem to be the opposite of each other.

1)  One is to provide constant access time.  When you hash something,
you get a key to insert into some kind of array (hash table).  If the
array is large enough, then collisions will be rare and you end up
with O(1) access time.  In this case, you will want to make sure if
you hash something, it always gives you the same key.  Otherwise,
after you insert it into the array, you won't be able to find it
again.  :-)

2)  The other reason is to give a unique key through hashing.  For
security reasons, you probably want the result of hashing to be
different between program runs or between systems or something.

Of the two, when I hear the word "hashing", I think of the first one.
And the first one is perhaps easier to implement.  To change the hash
key between runs means you need to influence the hashing with
something else (date or time of day).  And perhaps to do it in a way
that is secure?

Sometimes I wish people would come up with a new word for a new idea.
I think a kanji character would be a good representation for the
second form of hashing...  ;-)

Ray