Do positive coordinate locations give more ore in Minecraft?

I've heard that due to a bug in the terrain generation locations in the positive direction (i.e. (3,5),(100,200)) give more materials such as iron. I can't find any proof this claim, however. Is this true?

As of 1.6, this has been fixed.

• Fixed ore density varying per quadrant from the center of the world

Begin Original Answer

Okay, the original link comes from this answer here.

This, in turn, links to this reddit article, from which the following image is drawn.

In addition, one of the reddit comments explains why this appears to be the case, quote:

The bug occurs because of how all ore (and dirt and gravel) are spawned in the game. The game rounds everything towards to 0 (instead of just down), and then adds +0.5 when determining if a block has ore or not. It works for positive numbers (which is the southwest), and doesn't work as well for negative numbers (which is everything in the northeast). They just need to fix the rounding they do.

This thread discusses the details of this bug, and there is a fix starting from this post - quote below. This was implemented in v1.6:

* Fixed ore density varying per quadrant from the center of the world

I've been looking more closely at the code. I think the culprit actually lies in one of two blocks a short ways below:

int j = (int)(d7 - d11 / 2.0D);
int k = (int)(d8 - d12 / 2.0D);
int m = (int)(d9 - d11 / 2.0D);

int n = (int)(d7 + d11 / 2.0D);
int i1 = (int)(d8 + d12 / 2.0D);
int i2 = (int)(d9 + d11 / 2.0D);

Which amount to truncated start and end indexes for x, y, and z. The source coordinates to the function are absolute block coordinates, so if we're in the SW we're dealing with positive X and Z, and when we're in the NE, we're dealing with negative X and Z.

Or

double d13 = (i3 + 0.5D - d7) / (d11 / 2.0D);
if (d13 * d13 < 1.0D) {
...
double d14 = (i4 + 0.5D - d8) / (d12 / 2.0D);
if (d13 * d13 + d14 * d14 < 1.0D) {
...
double d15 = (i5 + 0.5D - d9) / (d11 / 2.0D);
if ((d13 * d13 + d14 * d14 + d15 * d15 < 1.0D)

Which is computing and testing threshold values for a given block. The computation takes the block coordinate/index, adds a positive offset of 0.5, and subtracts a floating-point position. The 0.5 offset may be the culprit, working as intended for positive position values, but off for negative. I'm even more inclined to believe this when you consider that in the above block we're flooring positive values but ceiling negative ones, which creates a kind of off-by-one condition that could be at play here.

The original thread that investigates the distribution of ores is found here, and contains various images of the distribution.

Quote from the same post:

You can clearly see the different densities, although it's obvious that the number of deposits is about the same. (They should be almost exactly the same.) You can also see the lack of clumping that indicates a non-random distribution.