This is because 0.9999999999999999 is possible in JS, but 1.9999999999999999 is not. The later rounds to 2.

console.log(0.9999999999999999); // 0.9999999999999999
console.log(1.9999999999999999); // 2
console.log(1.9999999999999998); // 1.9999999999999998

The large bounds have nothing to do with it. So the statement could be, "It's possible in extremely rare cases(when Math.random() returns 0.9999999999999999) the returned random number to reach the usually excluded upper bound."

Or the function could be written as:

const almost_1 = 0.9999999999999999;
Math.random = () => almost_1;

// Example from page, supposedly always returns numbers less than max
function getRandomArbitrary(min, max) {
  return (Math.random() - 0.0000000000000001) * (max - min) + min;
}

console.log(getRandomArbitrary(1, 3)); // Logs 2.9999999999999996

The large bounds have nothing to do with it. So the statement could be, "It's possible in extremely rare cases(when Math.random() returns 0.9999999999999999) the returned random number to reach the usually excluded upper bound."

Well, not quite. As the bounds get larger, the more common it becomes for a rounding error to cause the upper bound to be reached. I'd guess the probability doubles as the bounds doubles.

Or the function could be written as:

const almost_1 = 0.9999999999999999;
Math.random = () => almost_1;

// Example from page, supposedly always returns numbers less than max
function getRandomArbitrary(min, max) {
  return (Math.random() - 0.0000000000000001) * (max - min) + min;
}

console.log(getRandomArbitrary(1, 3)); // Logs 2.9999999999999996

No, that won't work if Math.random returns 0:

Math.random = () => 0;

// Adjusted example, I disagree with
function getRandomArbitrary(min, max) {
  return (Math.random() - 0.0000000000000001) * (max - min) + min;
}

console.log(getRandomArbitrary(1, 3)); // Logs 0.9999999999999998

This might be better:

Math.random = () => 0.9999999999999999;

// Adjusted example, with special check
function getRandomArbitrary(min, max) {
  const result = Math.random() * (max - min) + min;
  if (result >= max) return min; // Handle floating point rounding error
  return result;
}

console.log(getRandomArbitrary(1, 3)); // Logs 1 now.

As the bounds get larger, the more common it becomes for a rounding error to cause the upper bound to be reached.

You are right. My point is that the possibility exists across the range, not just with larger bounds.

if (result >= max) return min; // Handle floating point rounding error

Returning min is the best tradeoff 🙂. But the probability of returning min would increase with bigger bounds.

How about the following?

function getRandomArbitrary(min, max) {
  let result = max;
  while(result >= max) {
     result = Math.random() * (max - min) + min;
  }
  return result;
}

Fixing the code blocks would be better than explaining the rounding error cases.

As the bounds get larger, the more common it becomes for a rounding error to cause the upper bound to be reached.

You are right. My point is that the possibility exists across the range, not just with larger bounds.

That's true. We probably shouldn't be too specific since I don't think we really know.

if (result >= max) return min; // Handle floating point rounding error

Returning min is the best tradeoff 🙂. But the probability of returning min would increase with bigger bounds.

That might be true.

How about the following?

function getRandomArbitrary(min, max) {
  let result = max;
  while(result >= max) {
     result = Math.random() * (max - min) + min;
  }
  return result;
}

Good in theory, but it would be nicer if it would handle min >= max gracefully. If a beginner tries the wrong way around they would get an infinite loop.

Fixing the code blocks would be better than explaining the rounding error cases.

Hmm, I disagree. I think accurate documentation is more important. Example code is nice and useful, but not required.