Raphaël Jakse wrote:
> Is compressing for performance reasons?
Hopefully. Because in the general case the distribution of the
keys is unknown, no function used for computing the hash value
can be guarenteed to indeed spread the hash values uniformly
over the hash interval.
Compressing would ha
Le 11/11/2012 12:38, Manfred Nowak a écrit :
Jakse wrote:
It would also be interesting to have ideas for the general
case
Yes, ideas might be interesting. :-)
A root of "good" hashing is incorporated in algorithm2 of your
posting:
spread the values produced by the hash function uniformly ov
=?UTF-8?B?QWxpIMOHZWhyZWxp?= wrote:
> but the hash buckets are probably singly-linked lists
They are unbalanced binary search trees, which indeed turn to
singly-linked lists on sorted input.
-manfred
On 11/11/2012 07:40 PM, Ali Çehreli wrote:
I think std.container.RedBlackTree can take that responsibility but if you don't
need the elements to be in any particular order, then it may be seen as an
overkill as well.
I know, and I probably should give that a go, but as I've got working code rig
On 11/11/2012 01:11 AM, Joseph Rushton Wakeling wrote:
> So where classes are concerned there's a definite need to
> override opHash if you want the _values_ to be the basis of the
> association, rather than the object itself ... this would also have
> potential implications for memory blow-up wh
Jakse wrote:
> It would also be interesting to have ideas for the general
> case
Yes, ideas might be interesting. :-)
A root of "good" hashing is incorporated in algorithm2 of your
posting:
spread the values produced by the hash function uniformly over
the interval size_t.min .. size_t.max.
On 11/11/2012 02:35 AM, Ali Çehreli wrote:
For classes, because they are reference types, it is the object identity that
determines the hash value (probably the pointer of the actual object). As a
result, even when the values of the members are the same, two objects have
different hash values.
F
On 11/10/2012 05:37 AM, Joseph Rushton Wakeling wrote:
> On 11/07/2012 07:38 AM, "Raphaël.Jakse"
> "@puremagic.com wrote:
>> We want to be able to get the hash of s. Therefore, we re-implement
>> the toHash
>> method of the Student class :
>
> OK, now I'm curious. Assuming I don't write a custom r
On Saturday, 10 November 2012 at 18:18:07 UTC, Joseph Rushton
Wakeling wrote:
On 11/07/2012 07:38 AM, "Raphaël.Jakse"
"@puremagic.com wrote:
We want to be able to get the hash of s. Therefore, we
re-implement the toHash
method of the Student class :
OK, now I'm curious. Assuming I don't writ
On 11/07/2012 07:38 AM, "Raphaël.Jakse" "@puremagic.com
wrote:
We want to be able to get the hash of s. Therefore, we re-implement the toHash
method of the Student class :
OK, now I'm curious. Assuming I don't write a custom re-implementation, how
would a custom struct or class be hashed? (W
On Saturday, 10 November 2012 at 07:55:18 UTC, Raphaël Jakse
wrote:
Hello,
Thanks for this complete answer. I will take a look to your
code.
Ok - good. I've been using 2.061 which I just realized allows
"dup" on an associative array, a feature which was not available
in 2.060. So mixin(Dup)
Hello,
Thanks for this complete answer. I will take a look to your code.
Additionally, Ali gave me a really interesting link about hashing, good
practices, what is efficient, etc. If you didn't read it, it might
interest you. Here it is:
http://eternallyconfuzzled.com/tuts/algorithms/jsw_tut_
On Wednesday, 7 November 2012 at 06:38:32 UTC, Raphaël Jakse
wrote:
==
override size_t toHash() const
{
return (typeid(firstName).getHash(&firstName) +
typeid(lastName).getHash(&lastName));
}
==
Isn't the real problem the addition. You want to mix the bits
Hello everybody,
we had a conversation with Ali Cehreli about the right ways of
hashing values / objects. This is related to the D language when
using associative arrays but applies for any language as well.
One of the points was, we have the following class:
==
class Student // class repres
14 matches
Mail list logo
