-4

What I've gathered up till now is that hash codes are integers that help finding data from an array faster. Look at this code:

string x = "Run the program to find this string's hash code!";
int hashCode = x.GetHashCode();

for(int i = 0; i<100; i++)
{

// the hash code that is printed is always different
Console.WriteLine("Hash Code is: {0}", hashCode);

Console.ReadKey();

My question is: Why does it give me a different Hash code everytime it iterates through the loop? Why does the Hash Code for x keep changing even though the string isn't changed?

Ixcioran35
  • 21
  • 6
  • 2
    You say two contradictory things: `it gives me the SAME set of random numbers` and `Why does it give me a different random number every time it iterates through the loop`. What are you actually asking? – Eric J. Oct 09 '15 at 16:51
  • [MSDN HashCodes and what a hash code does](https://msdn.microsoft.com/en-us/library/system.object.gethashcode(v=vs.110).aspx) – MethodMan Oct 09 '15 at 16:52
  • Dont give me link to msdn, you think i didnt go there, and no i said it right it means that the 100 numbers are random(no one specified them), but the are always the same 100 numbers – Ixcioran35 Oct 09 '15 at 16:54
  • 2
    Which question do you want answered? Why `Random` generates the same numbers when you provide the same seed [has been answered many times already](http://stackoverflow.com/a/22712505/634824), and is [in the MSDN](https://msdn.microsoft.com/en-us/library/ctssatww.aspx). How hashcodes work is a separate question, and has also been answered many times already. – Matt Johnson-Pint Oct 09 '15 at 16:54
  • you are not being very respectful of people who are trying to help. If you read the MSDN page, you will see what Matt says is true. If you start with the same seed, you will get the same output from Random. The hash of a fixed string will always be the same, hence you get the same sequence of random numbers. – nycdan Oct 09 '15 at 16:56
  • 3
    @nycdan `The hash of a fixed string will always be the same` That's not strictly true. It's only true *within the context of a single execution of the program*, a constraint which is not applied in this context. – Servy Oct 09 '15 at 16:59
  • I meant no disrespect. I think its just the way wrote it. The thing is I know how random works. I was asking why the hash code is changing – Ixcioran35 Oct 09 '15 at 17:00
  • you need to understand hashcodes also if you want to get a different set of random numbers then either declare the ` Random random = new Random();` or change the random next also running your code of course the hashcode will remain the same.. once again read the link or do more research on HashCodes and you will quickly put your own attitude in check.. – MethodMan Oct 09 '15 at 17:00
  • @servy - Good point. – Matt Johnson-Pint Oct 09 '15 at 17:02
  • @Servy yes given the scope that's correct.. but I am running his code 10 times already and the hashcode has not changed perhaps the question needs to be edited in regards to eliminating the `Confusion` – MethodMan Oct 09 '15 at 17:02
  • 2
    @Ixcioran35 can you please update your post than to remove unrelated `Random` code than? "Why hashcode changing" is already well addressed by Servy's answer, but it is very hard to see how that answer is related to your post in current state. – Alexei Levenkov Oct 09 '15 at 17:03
  • @MethodMan The hash code *can in fact change* upon subsequent executions of the same program. It is only guaranteed that a given string always generate the same hash code *within the scope of a single execution of the program*. – Servy Oct 09 '15 at 17:03
  • @AlexeiLevenkov Well, we can see how it's relevant to him in that he thinks that he can use a string to create a seed for a RNG, possibly storing it in a database or having a user remember it or whatever, but the problem is that this is out of the scope of `GetHashCode`. I agree it's irrelivant to his core question, but it *is* clear how knowing that `GetHashCode` isn't stable across program invocations is relevant to him (even if it's not relevant to us). – Servy Oct 09 '15 at 17:05
  • @MethodMan The fact that `GetHashCode` isn't guaranteed to be stable across program executions doesn't mean that its guaranteed to change across program executions either. It's also worth noting that the actual algorithm used by .NET has changed a number of times over time, so your runtime could easily be using an entirely different algorithm than the OP's. – Servy Oct 09 '15 at 17:13
  • Amazing how people flock towards the downvote button :( – Ixcioran35 Oct 09 '15 at 17:15
  • @Ixcioran35 Had you edited your question in response to the confusion of many of the users, rather than just complaining about the fact that they're confused, it would have a much more positive effect on your question's score. The fact that the question is decipherable with great effort doesn't mean it's a quality question. You've had more than enough time to improve it to address the concerns in the comments, and yet you still haven't. – Servy Oct 09 '15 at 17:18
  • There we go. That should remove anymore confusion – Ixcioran35 Oct 09 '15 at 17:22

2 Answers2

4

It's vitally important for the hash code to remain the same for a given object throughout the lifetime of that program's execution. The hash code of a given object should not be relied on to remain the same across multiple executions of the program, which is what you're doing. Many implementations will happen to remain the same in different program invocations, but the .NET string implementation does not.

Servy
  • 197,813
  • 25
  • 319
  • 428
  • Should be +"more than nine thousand" for figuring out what OP actually wanted to ask behind Random code :) – Alexei Levenkov Oct 09 '15 at 17:05
  • Thankyou. But that much i deduced from observation. If you can. please elaborate – Ixcioran35 Oct 09 '15 at 17:07
  • @Ixcioran35 What's there to elaborate on? You expect `GetHashCode` to be the same across program invocations. The documentation *specifically* tells you not to do that as it is not something that you can rely on remaining stable. If you need that functionality you'll have to write your own hash function, rather than using `GetHashCode`, so that you can reliably use a fixed hashing algorithm that suits your needs. You're using a tool that isn't designed for the job you have, so don't do that. – Servy Oct 09 '15 at 17:09
0

What I've gathered up till now is that hash codes are integers that help finding data from an array faster

No, they help find data in a hash based collection faster. An array is just a sequence of items; there is no reliance on, or benefit from using, hash codes in a normal array.

What are Hash Codes exactly

It is a 32-bit integer that is used to insert and identify an object in a hash-based collection like a Hashtable or Dictionary

and how are they generated (if necessary)?

There is not one algorithm that all objects use to generate a hash code. The only restrictions are that 1) two "equal" objects must generate the same hash code, and 2) an object's hash code must not change over the life of that object. There is no restriction that two "equal" objects in different programs return the same hash code.

The default implementation uses the location of the object in memory. Classes such as string that define "equality" as sometihng other that "a reference to the same object in memory" override this default behavior to honor rule 1 above.

If you want a hash code that can be persisted and is guaranteed to be the same each time you ask for it, then use a standard hashing algorithm like SHA1 or MD5.

D Stanley
  • 144,385
  • 11
  • 166
  • 231
  • With respect to the first question, hash tables *are implemented using arrays*, so the hash code *is* actually used to find the index of the item in an array, it's just that the hash table is responsible for doing that translation for you. – Servy Oct 09 '15 at 17:11
  • The `string` implementation of `GetHashCode` has nothing to do with the object's location in memory. Given that different string objects in entirely different locations can be equal, it's essential that the location of the reference have nothing to do with it. – Servy Oct 09 '15 at 17:16
  • @Servy I was referring to the base `object` implementation. I have clarified that classes that define "equality" differently use a different algorithm. – D Stanley Oct 09 '15 at 17:24