On Sun, 2007-06-05 at 21:30 -0400, Tom Lane wrote:
It'd be a good idea if you repeat the previous number-of-collisions
experiment on this code.
I repeated the same experiment, and got essentially the same number of
collisions (829 collisions on ~2 million randomly generated numerics,
with 273
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2007-03-05 at 23:57 -0400, Tom Lane wrote:
Hm, but apply hash_any() to the remaining digits? That might work, if
you are careful about how you factor the weight into it (or just not try
to use the weight in the hash).
Attached is a patch that
On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
I'm still not very comfortable with that. You're proposing to add a
pretty obvious failure mechanism --- any numeric-returning function
that failed to normalize its output would now create a subtle,
hard-to-find bug.
What about teaching
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
I'm still not very comfortable with that. You're proposing to add a
pretty obvious failure mechanism --- any numeric-returning function
that failed to normalize its output would now create a subtle,
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2007-04-27 at 10:02 -0400, Tom Lane wrote:
Perhaps a sufficiently robust way would be to form the hash as the
XOR of each supplied digit, circular-shifted by say 3 times the
digit's weight.
The only objection I have to this is that it means we
On Fri, 2007-04-27 at 04:09 -0400, Tom Lane wrote:
I feel uncomfortable about this proposal because it will compute
different hashes for values that differ only in having different
numbers of trailing zeroes. Now the numeric.c code is supposed to
suppress extra trailing zeroes on output, but
Sorry for fat-fingering the previous reply -- I wanted to add:
On Fri, 2007-04-27 at 10:02 -0400, Tom Lane wrote:
Perhaps a sufficiently robust way would be to form the hash as the
XOR of each supplied digit, circular-shifted by say 3 times the
digit's weight.
The only objection I have to
Neil Conway [EMAIL PROTECTED] writes:
For any two numerics that compare equal, we need to compute the same
hash value for both datums, even if their bit patterns differ.
I feel uncomfortable about this proposal because it will compute
different hashes for values that differ only in having
I wrote:
I feel uncomfortable about this proposal because it will compute
different hashes for values that differ only in having different
numbers of trailing zeroes. Now the numeric.c code is supposed to
suppress extra trailing zeroes on output, but that's never been a
correctness property
