Reconsider half-open ranges

[theScottyJam]

This is a continutation of #20

I would find it very unfortunate if the random APIs for picking integers go against the design of every other function in the language, and went with fully-open ranges instead of half-open ones.

(half-open would mean Random.int(0, 3) -> 0 or 1 or 2 and full-open would mean Random.int(0, 3) -> 0 or 1 or 2 or 3).

There's a couple of reasosn to use half-open APIs.

• When I program, I don't want to be required to remember which APIs are half-opened and which ones are full-open. I'd like to be able to just assume that everything is half-open.
• Programmers are very used to writing out logic using half-open APIs. It's natural for us. Not only that, half-open APIs tend to "lego" together very well without requiring off-by-one twiddling. I venture one of the most common uses of Random.int() would be to pick a random element from an array (at least, until the language gets its own function to do it). Compare these solutions and notice how well the "half-open" version just legos into it:

// With half-open
items[Random.int(0, items.length)]

// With full-open
items[Random.int(0, items.length - 1)]

Or, here's a slightly more complicated example - say we're given an array and an index, and we need to find a random element in the first half of the array (below the index) and another in the second half of the array (at or after the index).

// With half-open
function (items, index) {
  return [
    items[Random.int(0, index)],
    items[Random.int(index, items.length)],
  ];
}

// With Full-open
function (items, index) {
  return [
    items[Random.int(0, index - 1),
    items[Random.int(index, items.length - 1),
  ];
}

By the way, notice how similar this example is to, say, an API where we need to partition an array into two halfs using a provided index.

function (items, index) {
  return [
    items.slice(0, index),
    items.slice(index, items.length), // Or omit items.length, I'm keeping it here to show the simularities
  ];
}

This goes back to my point that the rest of the language is half-opened - we're used to using .slice() in this sort of manner, and it would be nice if Random.int(), which has a very similar argument list didn't break our expectation in how it behaves.

Point is, any time you're dealing with random integers and arrays, you're going to be cursing the unnatrual full-openedness of it. This was a point that was already made in the previous thread I linked to, but I'm hoping to really express how damaging this is, as this is a very common use-case. In fact, I'd argue that more projects need to deal with picking random indicis vs picking random integers for other purposes.

Why was full-openedness picked?

I believe it mainly came from this argument.

If you're generating an int for a dice roll or similar, you often want a closed range - Random.int(1,6) to roll a die, for example, feels a lot more natural than Random.int(1, 7) (or Random.int(6)+1, for the langs that only offer a max).

This is true. But this is also true with any API in the language. Why should random integers be different?

You have a list of test scores sorted from best to worst, and you want to get the second item in the list. Well, you got to do scores[1]. Want the last item in the array? Before .at(-1) was an option, programmers were very used to doing scores[scores.length - 1]. And so on. Yes, Random.int(1, 7) is unnatural for picking a dice role, but we're already used to it. And there's ways to represent it so it's not so bad, such as const DICE_SIDES = 6; return 1 + random.int(0, DICE_SIDES);.

Middle ground?

If we're really worried about making it easy to pick random integers for dice rolls, perhaps we could find a way to support both half-opened and full-opened.

For example, an options bag to control opened-ness (This option seems appealing to me - I feel like most languages shy away from it because it's the exact same as doing a simple +1, but it's much more expressive and easier to understand to use "inclusive" instead of twiddling with off-by-one calculations).

Random.int(0, 3) -> 0 or 1 or 2
Random.int(0, 3, { inclusive: true }) -> 0 or 1 or 2 or 3

Another path would be to provide two functions. I'm a little less fond of this one though - I still don't love having a function out there with the default behavior of full-openedness, but it's an improvement:

Random.index(0, 3) -> 0 or 1 or 2
Random.int(0, 3) -> 0 or 1 or 2 or 3

Or, we just ditch full-openedness and let programmers deal with the off-by-one issues when rolling dice, like we're already used to doing.

[tabatkins]

First, just to note, it looks like you're only talking about the integer methods; hopefully my argument about you not actually being able to notice whether Random.number() was open or closed was convincing. ^_^

Second, the current proposed behavior for the int functions (closed ranges, inclusive of both ends) matches roughly half the languages I surveyed that had a "random int between two values" function. All of these shared the same array indexing behavior that JS (and frankly, everything but MatLab) has! So at least opinions are split in the language design community about which behavior is best. ^_^

For those that only offer a "random int between 0 and some value" function, it's universally half-open, which naively makes sense. And if they offer both types of random int method, they match, which explains some of the behavior leanings; but that implies that, absent the consistency pressure of having both methods, it's somewhat more intuitive for an int range to be closed.

That said, having a half-open int method makes sense, for exactly the reasons you gave. That's why this proposal has Random.range(), which is intended to match Iterator.range(), which has half-open behavior as you'd expect. Random.range(5) will generate values between 0 and 4; Random.range(5, 10) will generate between 5 and 9, etc. (Assuming that Iterator.range(), which is still just a proposal, retains this argument behavior, but I expect it will; it matches what everyone else does.) That's exactly the second behavior you're suggesting.

Another consideration is consistency with CSS, which funnily enough is gaining more advanced randomness before JS does. In random(0, 10, 1), you get 11 possible values, 0-10. Now, this makes a lot of sense for CSS, which is more likely to have min/max values that correspond to a desired length, and which doesn't have array indexing. But still, being consistent between the two languages helps learnability after all. (It is, of course, a complete coincidence that I'm also the author of the CSS random() functions. Self-consistency is still consistency. ^_^)

I also think this is just more consistent overall. In Random.number(0, 10), you can get any value between 0 and 10; as small as .000000001 and as large as 9.9999999999. (Whether you can actually get 0 or 10 exactly is undetectable in practice.) So, in practice, you have to be ready for any value up to and including your endpoints. Making that also true of the int functions means the random functions act consistently in all cases; Random.int(0, 10) also means you have to be ready for all (integer) values up to and including your endpoints.

Finally, I just want to make dice-rolling easy. ^_^ Like you say, there's already plenty of places where you have to remember to do arr.length - 1; using Random.int(0, arr.length-1) to select a random index will just be one more of those places. (Or just use Random.range(arr.length), or Random.sample(arr) from the other proposal.

[bakkot]

Strong second to everything @theScottyJam says (except the suggestion to have multiple functions which differ only in whether the endpoints are included, which I don't like).

I agree that in practice you aren't going to be able to tell whether you're sampling from a closed or open interval when sampling a continuous interval of reals. However, it's important that code be easy to reason about: it's not enough to get the right answer, it should be obvious that it's the right answer. That means matching the things they're familiar with.

This matters more for Random.int, since then it is very obvious whether it's closed or not. If you feel strongly that a Random.int(min, max) must be able to output max, I would consider that sufficient reason to not have a Random.int function. Better not to have it at all than to have it with that behavior.

[tabatkins]

it's not enough to get the right answer, it should be obvious that it's the right answer.

Fun fact: most languages that claim to have a half-open range for their "random float between two values" function are actually liars, and it's a fully closed range for some values. (They mostly just do the trivial Math.random*(max-min) + min transform, which is not float-safe and will sometimes round the top value to equal the max.)

Better not to have it at all than to have it with that behavior.

Do you think all the languages that offer a random int with a closed range are broken? Like I said, sampling all the major languages, if they offer a random int at all, roughly half are half-open and half are closed. (And I wouldn't trust, in general, that the half-open ones actually are; they're probably still doing the trivial transform listed above + a floor(), so they'll sometimes return the max value anyway.)

[theScottyJam]

hopefully my argument about you not actually being able to notice whether Random.number() was open or closed was convincing. ^_^

Yup, it was convincing :). As such, I'm not as concerned about random floats.

And if [other languages] offer both types of random int method, they match, which explains some of the behavior leanings; but that implies that, absent the consistency pressure of having both methods, it's somewhat more intuitive for an int range to be closed.

Perhaps you're right and it was more intuitive for these languages to use an open range.

Or maybe it could be a bad choice that got carried on from language to language. Similar to how switch statements with fallthrough behavior was unfortunately copied-pasted into so many languages.

Don't think I'll do it right now, but it would be interesting to dig deeper and see how people feel about these language decisions. Though I know it's difficult to gather objective information on that sort of thing - I'm sure one could find whatever opinions they wish to find.

That's why this proposal has Random.range(), which is intended to match Iterator.range()

Somehow I missed that, whoops. So I guess this does technically fit into that "middle ground" solution I proposed of introducing two separate functions for it. Though it is the one I said "I'm a little less fond of". I'd still rather only have one function, not two.

Another consideration is consistency with CSS

Consistency with CSS is nice, but CSS is also such a different beast. I've seen other conversations around consistency with CSS and how it's a fairly low-priority consideration compared to many other factors, and I tend to agree with that. CSS, to me, is such a different beast - if I'm ever trying to intuitively understand something new from JavaScript, my intuition will primarily be guided from my experiences with other programming languages. CSS typically has very little influence in how I expect JavaScript to behave. For example, CSS could introduce one-indexed arrays in the future, and it honestly wouldn't shock me that they went a different route from JavaScript.

I also think this is just more consistent overall. In Random.number(0, 10), you can get any value between 0 and 10; as small as .000000001 and as large as 9.9999999999. (Whether you can actually get 0 or 10 exactly is undetectable in practice.) So, in practice, you have to be ready for any value up to and including your endpoints. Making that also true of the int functions means the random functions act consistently in all cases; Random.int(0, 10) also means you have to be ready for all (integer) values up to and including your endpoints.

Let me see if I can try to rephrase this argument to make sure I understand it. With Random.number(0, 2), we don't really worry about the endpoints since they're extremely unlikely to be hit, but we do still have to worry about numbers close to 0, 1, or 2. So by making Random.int(0, 2) also require programmers to worry about the numbers 0, 1, and 2, we're providing some sense of consistency between these two functions. Is that what you're getting at?

---

Separately, I want to throw out this design question, as I'm not really sure how to answer it.

I prefer that Random.int() has a semi-open range because I imagine I'll often be using it to generate array indics.

But what about Random.bigint()? People generally don't use Bigints for array indices. Are there other common use-cases out there that would make a semi-open range for random bigints preferable to an open range? I feel like there probably are, but can't think of anything off of the top of my head. If not, it would be awkward to force an add-by-one every time someone needed to use Random.bigint(), but it would also be awkward if Random.bigint() behaved differently from Random.int().

[tabatkins]

I'd still rather only have one function, not two.

Wrt your other suggested resolution (adding a flag), you might also have missed that there's already an option flag (excludeMax) that does exactly this, too. Random.int(0, 10, {excludeMax:true}) returns a value between 0 and 9. (And if you want, {excludeMin} turns off the other side.) All of the methods use the exact same set of options: {step, excludeMin, excludeMax}. (Except .range(), which'll use the same options as Iterator.range(), instead.)

Consistency with CSS is [...] a fairly low-priority consideration compared to many other factors

Indeed, but "low" isn't "zero". It's nice when we can get it, just to make the web platform more consistent overall.

Let me see if I can try to rephrase this argument to make sure I understand it.

Yes, you've got it.

it would also be awkward if Random.bigint() behaved differently from Random.int().

Yes, Random.int() and Random.bigint() absolutely need to act identically to each other. (And so should Random.number(a, b, 1).)