equals and hashcode

[inland charm]

so I'm studying class stuff, can someone explain to me the use of hashcode in simple terms? if it's gonna give a unique value based on the fields you use to return it a value, why not just use it in the equals method? I guess it wouldn't work if the object is from another class but somehow returns the same hashcode, or if it's equal to null. I would like to know what the general concept behind hashcode is

[tall nova]

<@&987246399047479336> please have a look, thanks.

[tall nova]

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

[digital crescent]

its not necessarily unique btw

in fact, u cant use it to compare two objects

its not the same as equals

its allowed to have two different objects with the same hashcode

in fact, its impossible to prevent that

that said, it enables u to represent an object by a number

and if u have two different numbers, the objects behind them must be different as well

so lets say u have two person objects, john and bob

its allowed that they both have the hashcode 5

eventhough they are different

however, if they have a different code

lets say bob is 5 and john is 7

then its given that they are in fact different

use cases for hashcodes are mostly the pretty clever idea of a hashtable

suppose u have an array with 100 slots

and suppose u have a hand full of persons and their hashcode can only go from 0 to 100

lets say we want to store the persons in that array

instead of just putting them in the array in random order, we could put them at the slot corresponding to their hashcode

so array[5] = bob and array[7] = john

now, whats the benefit of that...

well, suppose u want to test whether ur person-storage contains john

conceptionally u want if (array.contains(john)) { ... }

how could such a method work?

in an ordinary array, u would have to iterate the whole damn thing and test each element with equals

that takes long if ur array is huge

really long

but the hashcode idea speeds that up extremely

instead of iterating the whole damn thing

u know, if john is in the array, he must be at index 7

since thats johns hashcode

[inland charm]

oh ok so hashcode is basically just a number that you assign to an object, if 2 objects' hashcodes are different, you know the objects are different, but you can't use it to determine if its the same object or not, it's just a number given to each object roughly

[digital crescent]

so u can just lookup the element at index 7 in ur array, test that single element with equals and then ur done

[digital crescent]

exactly

and pretty much all use cases go in the same direction than that hashtable idea

in java, u have that in HashSet and HashMap and also some other classes that work in a similar way

[inland charm]

interesting, but wouldn't you wanna make sure the hashcode is unique for each object, if you're gonna place them in an array? what if bob and john are both 5, what are you gonna find at 5, if you're gonna store 2 objects with the same hashcode into a "hashtable", how would you deal with it? I understand that question is offtopic since it's more related to hashtable but I'm getting curious

[digital crescent]

its not possible

its desireable, but not possible

there are only finite many integers

but infinitely many object combinations

but yes, in practice u want to be able to prevent collisions as much as possible

to overcome this problem in hashmap/set, java stores a list of objects per-bucket

and then simply iterates everyone in that list, using equals

but the lists are typically super small, as collisions are fairly uncommon

[inland charm]

bucket?

[digital crescent]

yeah array[7]

it doesnt contain "one person"

but "a list of persons"

[reef violet]

Btw the reason why hashcode cannot be unique, is because a hashcode is in an integer of a certain size, if your integer has a size of 32 bits, then it can only have 4 billion different values, and so if your object can represent more than 4 billion values, then it simply can't be unique.
Another reason could be that you want to easily generate a hashcode from an object, but if you had unique ids, then you would need a manager to verify that the ids are unique, you wouldn't be able to generate an id from an object

[digital crescent]

each person with that hashcode

[inland charm]

so like an array of lists, each containing the elements with a hascode corresponding to the index?

[digital crescent]

exactly

and technically, since hashcodes can range from like -2 billion to +2 billion (all ints), its also not directly the hashcode

but the hashcode after a simple mapping into a smaller range

but thats details

[inland charm]

I'm kinda confused about that last part but maybe I'm just dumb

[digital crescent]

suppose u want to create unique ids each time u create an object

how can u ensure its really unique?

u have to keep track of all already generated IDs

not nice

thats what ala was referring to

[inland charm]

hold up, I mean, isn't every unique id system capped by some sort of max value? if that's the case, then how is hashcode any less capable of producing a unique value, then, say, an id

[digital crescent]

hashcode is supposed to run super fast. otherwise it defeats the whole purpose

most unique ID systems arent either actually promising to be unique, or are slow bc they need to keep track of everything

also, there is sth u have to keep in mind. u dont actually want that each object has a different hashcode

it depends on the properties

if u create two johns

even though they are different objects, they are equal

and hence also need the same hashcode

so the hashcode is supposed to be generated based on the properties (similar to how equals works)

so its not just "unique id per object"

its "value that represents the combination of properties"

[inland charm]

oh right, so hashcode just generates a number quickly, while an id has to make sure it's different from other id's

[digital crescent]

yeah, but even there collisions are usually possible

just very rare

most "unique ID" systems used in practice arent collision-free

[inland charm]

right, it's a value that represents all the properties, but similar properties can still have the same hashcode

[inland charm]

damn, I mean, I always thought making a unique id system would've been easy as fuck, I guess I underestimated it. what's stopping you from just adding 1 to a variable each time you make a new instance and just set the id to that variable

[digital crescent]

yeah, that works for some situations. but in many, u cant work with such a system

for example, its not "repeatable"

[inland charm]

I guess the limitations of the variable type is an issue for sure

[inland charm]

repeatable?

[digital crescent]

well, that system is based on the "current counter"

what if u lose that counter

or the order of object generation changes

then everyone gets a new id

like, if john asks for a number, it depends on who else asked for a number that day already

and if he asks the next day, the ID will be totally different as well

its not always the same for john

ur idea works in a lot of places and is used (maybe with some slight modifications) a lot. but there are still plenty of situations that require a different system

[inland charm]

right, but like, why would you id a person more then once? like, you'd just give them an id based on a counter, and assuming that counter is properly updated, there should be no discrepencies right?

I see, damn

[digital crescent]

also, that system has a trust issue

it cant be used for any verification based topics

like, lets say john asks for a number and gets 5

now, everyone has to trust john saying "my number is 5"

since no one can repeat the process to verify it

no one can re-compute the number

systems like UUID, SHA, MD5, ... are repeatable

[inland charm]

ohh right, in terms of code, there isn't really a process behind the result that you can recreate to verify his id I guess

[digital crescent]

yeah

[inland charm]

right so I guess a good id system would make sure there's always a process that leads to that same result, the same way a hashcode would

[digital crescent]

yeah. it just really depends on ur requirements

databases for example use such a simple incrementing counter to assign each entry a unique ID

cause it has no need for anything extra

[inland charm]

damn this is much more complicated then I thought, both making sure you give a unique id and have it be consistent each time you do it, without using a counter

[inland charm]

right I guess if you don't need to trace back the process, you can just use the counter method

[digital crescent]

yeah. and u can also get rid of the "problem" that each number is adjacent

like, suppose ur at some customer service and have number 93

then usually ur the 93th person at that day

and the next person is number 94

so u can deduct information from the number

but u can get rid of that while keeping the simple idea of an incrementing counter

by using pseudorandom number generators, LCGs to be precise

for example javas Random class

Random rng = new Random();

[inland charm]

waitt, wym?

oh right right nvm

when you see your number, you're deducting the process behind its generation

[digital crescent]

yeah

it can be a problem

for example if u get an order number from amazon 101031239

u would be able to try out to check others orders

by just -1 or +1 it

[inland charm]

oh jesus I see

[digital crescent]

so for such a system its better if the order numbers are far apart

and appear "random"

[inland charm]

so you would want a more complicated id system for security reasons

[digital crescent]

yeah. so for order numbers u would want to generate an id that cant be guessed

a good system for that is called UUID

in java, u can do that with UUID.randomUUID()

[inland charm]

I see, damn, I learned a shit ton from this from just asking about hashcode, thanks for that!

but yeah imma keep studying classes, see ya