custom hashCode() method outputs integers DIFFERENT than the String class

[Nim]

Here is my code; the algorithm is taken from the Java API here

	public int hashCode()
	{
		int code = 0;
		for (int i = 0; i < length; i++) // where length is the length of the string.
			code += chars[i]*Math.pow(31, length - 1 - i); // where "chars" is a char array.
		return code;
	}

A quote from the previously-linked API page on the String class:

Returns a hash code for this string. The hash code for a String object is computed as

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

As you can see, I used this algorithm correctly. However, the outputs are still different. Consider these outputs (where my custom implementation of a String is called MyString) (you can verify them yourself if you wish...):

(new MyString("WHAT")).hashCode() returns 2663108
(new String("WHAT")).hashCode() returns 2663108

(new MyString("HOWEVER")).hashCode() returns 2147483647
(new String("HOWEVER")).hashCode() returns 1819945294

(new MyString("ABSOLUTELY INCORRECT")).hashCode() returns 2147483647
(new String("ABSOLUTELY INCORRECT")).hashCode() returns -1874695255

Ok, if you haven't already noticed (I just did), for some reason the integer returns is the same for "HOWEVER" and "ABSOLUTELY INCORRECT". I have no idea why; the odds seem unlikely.

Hold on, isn't 2147483647 the largest positive integer? Is there some sort of cap that is imposed on the add function when the result overflows?

And this leads me to ask ... How can I emulate the String class correctly, to provide overlap so that the addition overflows to negative integers (as I know they will, since we all do math with a 2's-complement system).

[Nim]

I think it is because of the implicit casting that happens when I add an integer to a double.I will have to implement a more complex loop that deals with numbers larger than 2147483647. I will post my implementation afterward.

Edit:

I'm not posting it. I found out the current operand mod 2147483647 and "inverted" the code that number of times. Finding how many times 2147483647 goes into an extremely large number takes an extreme number of loops. It's not fast enough, so I'm discarding it.

I'd like to know how the String class really computes the hash code...

[@tul]

String class computes hash code as follows.

                if str is String then 

                hash = 0;
	value = str.toCharArray();
	offset = 0;
	count  = value.length;


	 public int hashCode() {
			int h = hash;
			if (h == 0) {
			    int off = offset;
			    char val[] = value;
			    int len = count;

		            for (int i = 0; i < len; i++) {
		                h = 31*h + val[off++];
		            }
		            hash = h;
		        }
		        return h;
		    }

[keang]

I'd like to know how the String class really computes the hash code...

You can download the Java source code and look for yourself. I often search through the source to see how things have been implemented.

[dlorde]

I think it is because of the implicit casting that happens when I add an integer to a double.
...
I'd like to know how the String class really computes the hash code...

If you read the String hashCode docs carefully, you'll see they specifically state they use int arithmetic.

Strictly speaking, you shouldn't expect any particular result from hashCode() - the contract doesn't require the same value to give the same hashCode from one run to the next. Basically, all you can expect is that equal objects should give equal hash codes and the hash code should not change for a given object value during a run.

Simplicity is the soul of efficiency...
A. Freeman

[Nim]

You can download the Java source code and look for yourself. I often search through the source to see how things have been implemented.

That is awesome and exactly what I was looking for thanks!