librelist archives

« back to archive

hash function for Entity::Id

hash function for Entity::Id

From:
Shaun Reich
Date:
2014-10-03 @ 16:22
me again :)

is it possible for entityx to get a definition of a hash function for
Entity::Id?

I require this to store it in an unordered map. it seems to already
have all the various comparison operators defined well, so of course
this would make it more trivial to create a mapping of entities to
whatever else..

idk the internals enough to decide on a good hash function..


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: [entityx] hash function for Entity::Id

From:
Alec Thomas
Date:
2014-10-04 @ 00:12
I don't have one handy but if you can use a 64-bit key then you can use 
the ID itself?



> On Oct 4, 2014, at 2:22 AM, Shaun Reich <sreich@kde.org> wrote:
> 
> me again :)
> 
> is it possible for entityx to get a definition of a hash function for
> Entity::Id?
> 
> I require this to store it in an unordered map. it seems to already
> have all the various comparison operators defined well, so of course
> this would make it more trivial to create a mapping of entities to
> whatever else..
> 
> idk the internals enough to decide on a good hash function..
> 
> 
> -- 
> Shaun Reich,
> KDE Software Developer (kde.org)

Re: [entityx] hash function for Entity::Id

From:
Shaun Reich
Date:
2014-10-04 @ 02:52
On Oct 3, 2014 8:12 PM, "Alec Thomas" <alec@swapoff.org> wrote:
>
> I don't have one handy but if you can use a 64-bit key then you can use
the ID itself?

Hm I thought about this right away as well.
But, wouldn't this have poor distribution? Given that I believe the hash
function get modulo'd by the # of buckets. So, even for non huge sets it'd
have really bad distribution id guess.

but then I realized that it has the version stuff, so the hashing wouldn't
be restricted to just one key input, but could be mixed with additional
(hopefully entropy) given via entity.version(), which I'd assume would help
the distribution fluctuate much better.

Anyways, I guess it's just fine to use the id, at least until someone comes
up with something better/realizes it's an issue.

Chances are it won't be I'd guess.. Of course, they could always override
with their own hash function.

Just the main idea being to make it easy to use unordered_map, which people
*should* be using, and this making it easier to do so.

I'll whip up a simple patch/merge request in the next week or so if I find
time, so I can get rid of duplicated code on my end :)
Side note, I'm a bit surprised that nobody has said anything this far, but
guessing that most people who use this library wouldn't likely be aware of
using that vs. map, *and* actually needing to store an entity id. (I happen
to because of my spatial hash, for one. As well as for maybe one or two
much smaller less interesting cases).

--
Shaun Reich,
KDE Software Developer (kde.org)

Sent from Android phone.