On Sun, 27 Feb 2005 15:36:42 -0700, [EMAIL PROTECTED] (Luke Palmer) wrote:
> Nigel Sandever writes:
>
> When we're talking about hashes of everything, there are a couple of
> routes we can take. We can go Java's way and define a .hash method on
> every object. We can go C++'s way and not hash at all, but instead
> define a transitive ordering on every object.
The more I think about this, please, no. The reason hashes are called hashes is
because they hash.
If we need bags, sets, or orderThingies with overloadable transitive ordering,
they can be written as classes--that possibly overload the hash syntax
obj<<key>> = value
or whatever, but don't tack all that overhead on to the basic primitive.
> We can go Perl's way and
> find a string representation of the object and map the problem back to
> string hashing, which we can do well.
The only question is why does the thing that gets hashed have to be stringyfied
first?
In p5, I often use hash{ pack'V', $key } = $value. # or 'd'
1) Because for large hashes using numeric keys it use up less space for the
keys. 4-bytes rather than 10 for 2**32.
2) By using all 256 values of each byte, it tends to spread the keys more even
across fewer buckets;
use Devel::Size qw[total_size size];
undef $h{ pack 'V', $_ } for map{ $_ * 10000 } 0 .. 999999;
print total_size \%h;
18418136
print scalar %h;
292754/524288
versus
use Devel::Size qw[total_size size];
undef $h{ $_ } for map{ $_ * 10000 } 0 .. 999999;
print total_size \%h;
48083250
print scalar %h;
644301/1048576
It would also avoid the need for hacks like Tie:RefHash, by hashing the address
of the ref rather than the stringyfied ref and forcing the key to be stored
twice and the creation of zillions of anonymous arrays to hold the unstrigyfied
ref+value.
The same could be extended to hashing the composite binary representations of
whole structures and objects.
njs.
