There's a lot of stuff that been said about how seeds are calculated from text strings using the java procedure string.hashcode() and also how numeric seeds are handled by the MC world generator that is no longer true.
Especially much of what was stated back in 2011.
Here's the way things stand as of 1 July, 2013 as far as I can tell.
Java's string.hashcode() routine is definitely being used to Hash, or if you will convert, a text string into a numeric seed.
Any text that is entered into MC in the input window labeled "Seed for the World Generator" that contains something OTHER than +-0123456789, those 12 characters ONLY, will be considered a text string, NOT a number. So if you accidentally put a space anywhere in that window you will not get what you expected.
The string.hashcode() routine uses 32 bit math and the output is a 32 bit signed integer and this is exactly the same as doing a X=mod(x,2^32) calculation after EVERY math operation.
FYI: Mod(X,n) means divide X by n, throw away the quotient and keep the remainder.
ie Mod(17,5) = 2. Because 17 divided by 5 results in 3 with a remainder of 2. So the 3 is discarded and the answer is 2.
Because of this 32 bit math entering a text string as a seed limits the seeds available to MC to the range of -2,147,483,648 thru 2,147,483,647.
These NUMERIC seeds are what will be displayed as the world's seed if you type in "/seed" while playing MC. Even if you entered a text string originally to create the world.
Note that MC does NOT store the original text string entered as a seed so it's a very good idea to store or write down any text string that you use as a seed if you ever expect to use it again. Of course you can use the numeric equivalent but that's not near as much fun.
The number 32 crops up again for some reason (unrelated to the above I'm sure) in that the MC seed input window in the latest versions of MC will accept a MAXIMUM of 32 characters and no more. At one time it would only display 32 characters but would actually pass on much more to the string.hashcode() routine.
If you're interested, here's the formula for string.hashcode():
h(s) is the hash code for string s
n is the length of s
s is the ascii code for the ith ;character in string s, s being the first character and s[n-1] being the last
Example: For the string "abcd" we first look up the decimal ascii code values for those letters.
(Only the decimal codes from 32 through 126 on the above table3 produce printable characters that the input window will accept.)
(Actually the MC input window will take ANY printable unicode character, not just those in the above table.)
a=97, b=98, c=99, d=100
the length, n, of "abcd" is 4 so our equation will be:
h = 97*31^(4-1-0) + 98*31^(4-1-1) + 99*31^(4-1-2) + 100*31^(4-1-3) or
h = 97*31^3 + 98*31^2 + 99*31^1 + 100*31^0 or
h = 97*29791 + 98*961 + 99*31 + 100*1 or
h = 2889727 + 94178 + 3069 + 100 or
h = 2987074
If anyone is interested I've developed an Excel spreadsheet that will take a text string and produce the same result that java's string.hashcode() produces. I'll upload the file and post a link if someone shows an interest. Unfortunately, Excel only takes ASCII codes through decimal 255.
MC's random seed generator, as far as I can tell, will produce a random 64 bit signed integer seed.
This will occur whenever the seed input window is left blank or a 0 (zero) is entered.
The range of these seeds is -9,223,372,036,854,775,808 through 9,223,372,036,854,775,807.
This same range without the commas (-9223372036854775808 through 9223372036854775807) is the acceptable input range for numeric seeds in the MC seed input window.
Seeds within this range can be entered manually in the seed input box.
I'm pretty sure that a statement made over two years ago that the MC code only uses the lower 48 bits of these seeds is no longer true. My experiments show no truncation of numeric seeds. Truncation to 48 bits may have occurred in earlier versions of MC but definitely not lately.
EDIT (6/24/19) The above statement is partially true.
Thanks, I mean to fix that and also edit/fix the errors in the OP that TheMasterCaver pointed out to me.
It seems that the Wiki is in error.
That post was originally posted in the deleted Seed FAQ in about 2014 and has needed editing.
It should also be mentioned that randomly generated seeds do not represent every possible 64 bit value since the game uses a random number generator that only has 48 bits of state (the game uses Random.nextLong() to get a random seed, which is used if you don't enter a seed, enter 0, or a text seed), meaning that only one out of 65536 seeds can be randomly generated (for example the seed "TMCWv4", numerically "-1816924181", cannot ever be randomly generated despite the fact that there are only 2^32 possible values for a text-based seed. In fact, only 65536 numerical values between -2147483648 and 2147483647 can be expected to be able to be randomly generated).
Also, the use of the same random number generator to generate everything other than the biome map is also why most non-biome related features will be the same for any seed that has the same 48 bit "base seed" (the biome generator uses a custom 64 bit RNG; presumably, early versions used Java's Random here as well but they never considered changing it elsewhere, which is easily possible as I made my own 64 bit RNG class which I use in most parts of world generation. Either way, as long as Random is used to generate a random seed you'll never get two different worlds that share the same 48 bit base seed without being the same overall).