Neil Conway <[EMAIL PROTECTED]> writes:
> 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 ~
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
On Sun, 2007-06-05 at 21:30 -0400, Tom Lane wrote:
> You can do it always if you simply decrement the weight for each leading
> zero removed.
On reflection, the patch as given was wrong anyway: if two Numerics are
identical except for the presence of leading zeroes, we can't consider
the weight wh
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 patc
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 implements this idea. Since leading or t
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 sub
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 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 m
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
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, b
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 prope
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 di
There is currently no support for hashing numerics. This prevents
numerics from being hash indexed or used in a hashed aggregation. This
patch makes the necessary changes to the catalogs to enable hashing for
numerics, and implements a first sketch at a hash function for numerics.
For any two nume
13 matches
Mail list logo
