❔ Best way to create a unique key made out of x y integer coordonates for a dictionary
Hello, i want to create a unique key to access values in a Dictionary, this key has to be unique and able to be created using just simple x y integer type coordonates. Any help is appreciated. Thank you
47 Replies
why not make
TKey
the coordinatenot sure i follow
Dictionary<Coordinate, Whatever>
but let's say i make a Coordonate(1, 2) and then create a new Coordonate(1, 2) object to access that value, would it work?
if they return the same hash code then yes
but would they retun the same hash code? like if i do
Coordonate(1, 2)
Coordonate(1, 2)
would both have same hash?
i mean you should override
GetHashCode
If you implement the method, sure
or preferably make it a record
Definitely make it a record
A ValueTuple might just be enough
But less concrete
but don't i have to manually generate the hash myself to always get a unique one based on the coordonates?
GetHashCode
is a method from object
you just override it in the class/struct
or use a record
which does it for you, as well as implementing value equality and other thingsokay sure, i get that, but my issue is how do i generate that hash so it's unique but also recreatable from the coordonates
also if it's a struct you're already done; as long as the values match it's equal
you dont,
Dictionary
doesThe whole point is that it is recreatable
You implement the creation
Hashcodes are kindof a whole separate thing that you don't really need to know anymore because of records
Just use a struct, or a record, and it'll do the job
not exactly
? That's how value types work, right? And structs are always value types?
Only if they're unmanaged
As in, fit the unmanaged constraint
If the struct contains a reference type, it won't work
Oh yeah, that's fair
Cyberrex#8052
REPL Result: Success
Console Output
Compile: 462.573ms | Execution: 68.553ms | React with ❌ to remove this embed.
String is the exception of course
Though I think the real answer to this question is, don't use a Dictionary, use a 2d array. There's no advantage to using a Dictionary for this, I don't think? Since there is a known lower and upper bound, and it's already integers, the 2d array lookup would be just as fast as a dictionary (or faster, since you're not making a Coordinate)
not really, it depends on what theyre trying to do
(a 2d array also means you could do things like, binary search to find the entity that is closest to a given coordinate...? Maybe. I've been thinking about a similar implementation)
hmm, how much slower would be iterating through a 100000x100000 array vs a dictionary with a much smaller list of coordonates?
how are they an exception in this case?
cause i have to iterate through the whole thing
probably faster than a dictionary
I've been told you should never iterate a dictionary, but I don't know how bad it is if you do
oh wait smaller?
depends, benchmark it
i mean yeah a dictionary isnt meant to be iterated
If you're iterating it, why do you need to be able to lookup the value?
iterating it will be relatively slow
huge mostly empty array vs a dictionary with lets say 20% of the values in the 2d array
to remove values from it
and also add
i think having a coordinate type and a dictionary makes more sense
and also build something from it, that's why i have to iterate through all of it
still why do you need to iterate it?
String already implements Equals and GetHashCode
yeah but the default struct.GetHashCode doesnt use that
Then a HashSet is probably your best bet; constant time add/remove/contains, iteration is fine. That's the point where you need to make sure what you're storing has good Equals and GetHashCode implementations for a HashSet
this might be an xy problem
... well, idk. Dictionary is fine. The other answers are fine. Just pointing out other options, but it does depend on what you're doing with it and all that
I would go with a simple record (struct?) for the coordinates, if Coordinate doesn't already implement value comparisons
yeah id make coordinate a record struct
Also just btw, dictionaries and hashsets don't use the hash for a real equality check; looking up something with the same hash (but different Equals) won't give you a result. The hashes are just the fast way it can look things up, if there aren't many collisions in the hashes, but it still checks the Equals too
thanks guys, i'll look into this further to see that's optimal, your support is appreciated 👍
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.