This is just something that bites me every once in a while (even though I know better!) and I just thought I'd mention it.

Consider needing random integer values of -1,0,1 (say you need movement deltas for a brownian motion -type walker or something, but any inclusive range of integer values will have the same issue, this range just used for example)

I realize that random(-1f,1f) implies "-1f+random(2f)" and returns [-1,1) so that if you did "(int)(random(-1,1))" you'd get only the values -1,0.

And the correct way to write it would be:
(int)(random(-1f,2f))
-1+(int)(random(3f))
(int)(-1f+random(3f))
(int)(random(3f)-1f)
etc

Problem is, none of those are likely to be intuitive for a beginner.  So just makes me wonder if there might be an opportunity for some other variant of the random() function that would help clarify the issue?

...especially because if you actually try to use (int)(random(-1,1)) the only value that ever comes out is 0:

Code:

for (int i=0; i<100; i++){
  println( (int)(random(-1,1)) );
}
 

(int) always rounds towards zero, which is a tricky gotcha - there was a bug in the core a while back because (int) was being used to round floating point values for pixel-based clipping, and it was very subtle because it only worked incorrectly when the floating point value was between -1 and 0.

You could either use Ben's suggestion, or floor(random(-1,2)) to get what you want.  I like floor because it explicitly acknowledges what you're trying to do.

I don't know that I agree about removing the ranged version, I find it very useful whenever I need a random floating point value.  What I might agree with is decoupling the Processing random() function from the Java implementation, which in my opinion is crummy and slow, like most built in random functions in programming languages...(actually, I feel this way about a lot of the Math.* functions, for that matter - I encourage you to actually try writing the obvious versions of simple math functions and comparing the performance versus the Math.* versions, you might be surprised!  Some of this is because Math.* uses doubles instead of floats, so you end up with a cast in and a cast out, but I suspect some of it is that Java's core developers have never taken mathematical speed to be very important, always preferring a slow, correct, and simple math library to a fast or complete one).