From: eugine_kosenko@... (Eugine Kosenko)
Date: 2001-09-11T21:25:10+09:00
Subject: [ruby-talk:21110] Inspecting of hashes

Hi all!

I have developed several minor features of Ruby hashes, which may be
useful not only for me. However, I do not have enough knowledge (and
time to investigate these issues), how to properly include these
features in the Ruby core. This include Ruby style conventions, CVS,
agreement negotiation, standrtization and help writing. So, I need
someone, who developes the Ruby core (or, may be, extensions?), who
may answer me about the feature usability, and help me to integrate
the feature in the Ruby in the best way.

Unfortunately, the Japan is not the language I use fluently, and japan
maillists for developers are incredible for me. Therefore I ask my
questions here.

I tightly work with hashes, searching the optimal implementation of
them in different languages and libraries. So, I strongly investigate
the implementation of the hashes in Ruby. The hashes are made cleanly
and simply, and I the implementation satisfy me at most.

Beside of issues of the implementation of hashes themselves, the good
hash code generation is very important. Since the hash developer can
not responce for the proper implementation of hash code generation,
the special means of hash inspection are required.

I've implement the method 'collisions' of Ruby's hashes using the core
code of version 1.6.4. The method returns an array of pairs, where
each pair contains hash code and the bin size for this code. Using
this array I can analyse the quality of the hash system: I can find
the minimal and maximal bin (collisions per code), average bin size
and distribution.

For instance, using this facility I found, that Integers return only
odd hash codes, and a hash of Integers always is half-empty. Another
surprise for me is become from the evaluation of bin number for a hash
code. I have not explored the scheme in details (I have no time for
this). However, I usually use simple numbers algorithm, and I think,
it is more effective than Ruby's mechanism.

Thanks for attention,
Eugine Kosenko