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():

where:
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[0] 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.

There are no dangerous weapons. There are only dangerous people. R.A. Heinlein
If you aren't part of the solution, then you obviously weren't properly dissolved.

If you want to see what post TheMasterCaver is referring to in the beginning of the thread that BigAlanM links to at the bottom of his post, use this link:

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.

There are no dangerous weapons. There are only dangerous people. R.A. Heinlein
If you aren't part of the solution, then you obviously weren't properly dissolved.

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).

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():

where:

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[0] 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.

See:

https://www.minecraftforum.net/forums/minecraft-java-edition/seeds/2229720-can-two-different-seeds-produce-identical-worlds

There are no dangerous weapons. There are only dangerous people. R.A. Heinlein

If you aren't part of the solution, then you obviously weren't properly dissolved.

If you have questions about the maps I post as attachments or Amidst and the like read this thread:

Using Amidst type programs to map and research Seeds

The latest release of Amidst, version 4.3 can be found here:

https://github.com/toolbox4minecraft/amidst/releases

You should probably also read this:

https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-tools/2970854-amidst-map-explorer-for-minecraft-1-14

You can find me on the Minecraft Forums Discord server.

https://discord.gg/wGrQNKX

~~The link at the bottom of that post doesn't work since the subforum got renamed when Bedrock stole the "Minecraft" name.~~~~This works:~~~~https://www.minecraftforum.net/forums/minecraft-java-edition/seeds/2229720-can-two-different-seeds-produce-identical-worlds~~If you want to see what post TheMasterCaver is referring to in the beginning of the thread that BigAlanM links to at the bottom of his post, use this link:

https://www.minecraftforum.net/forums/minecraft-java-edition//seeds/298943-seed-science-what-makes-a-good-map?comment=151

Just testing.

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.

For example, this https://minecraft.gamepedia.com/World_seed

was in error when it said that a random seed is related to the PCs system time.

I just corrected that page to remove the references to system time.

There are no dangerous weapons. There are only dangerous people. R.A. Heinlein

If you aren't part of the solution, then you obviously weren't properly dissolved.

If you have questions about the maps I post as attachments or Amidst and the like read this thread:

Using Amidst type programs to map and research Seeds

The latest release of Amidst, version 4.3 can be found here:

https://github.com/toolbox4minecraft/amidst/releases

You should probably also read this:

https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-tools/2970854-amidst-map-explorer-for-minecraft-1-14

You can find me on the Minecraft Forums Discord server.

https://discord.gg/wGrQNKX

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).

TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.

TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.

Why do I still play in 1.6.4?