Exposed randi_range to global funcs + renamed rand_range to randf_range

[Chaosus]

I see a lot of user help requests in Discord which has troubles with randi_range usage. Currently, it required to create an instance of RandomNumberGenerator, which may be uncomfortable for simple use cases. So I've added randi_range to GDScript global functions, and renamed rand_range to randf_range (for logic compatibility with other functions + @akien-mga asked me to do that a while ago).

The last change will probably break a lot of user scripts, so it's all up for @reduz and other core contributors decision

[aaronfranke]

This change makes sense, except that it would also make sense to go in the other direction, removing methods from global scope. Personally I like having these methods available due to how common they can be in projects, but it's worth a discussion. See also godotengine/godot-proposals#1590 for a discussion about removing the seed methods from global scope.

[Chaosus]

@aaronfranke I agreed with both directions, so either we choose one or another - I would be happy, I think @reduz should decide :)

[akien-mga]

If you're up for one last refactoring, it would be good to use the opportunity to change the order here:

MATH_RANDI
MATH_RANDF
MATH_RANDI_RANGE
MATH_RANDF_RANGE

(i.e. int first, then float for the ranged version too)

And then adapt the order in all places where these enums are used to keep the same order as the enum.

[akien-mga]

Or the other way around (float, then int) if we want alphabetical order instead:

MATH_RANDF
MATH_RANDI
MATH_RANDF_RANGE
MATH_RANDI_RANGE

[Chaosus]

@akien-mga I could make a randi_range exclusive, the advantage of inclusiveness - it's a more intuitive for raw usage, the disadvantage: things like arrays indexes or enums need to be cast down by 1 like randi_range(0, array.size() - 1) in order to generate value within its range.

[akien-mga]

I could make a randi_range exclusive, the advantage of inclusiveness - it's a more intuitive, the disadvantage: things like max array sizes or enum need to be cast down like randi_range(0, array.size() - 1) in order to correct processing.

Yeah I'm not sure what's best myself, exclusive would be like range(n) which gives n values between 0 and n - 1, but maybe the use case for getting 1 random number in a range is not exactly the same. You have a good point about getting a random index in an array though, but I think programmers are quite used to doing array.size() - 1 for indexing, so keeping it inclusive might be best?

[Chaosus]

@akien-mga Also, I think the description of randf is incorrect - it actually exclusive and not inclusive - it generates value from 0.0 to 0.999999 (but never hits 1.0).

[akien-mga]

Also, I think the description of randf is incorrect - it actually exclusive and not inclusive - it generates value from 0.0 to 0.999999 (but never hits 1.0).

That's probably due to the conversion from uint32_t to float which introduces precision errors (at least in the !defined(CLZ32) implementation (float)(rand() & 0xFFFFFF) / (float)0xFFFFFF;).

But yeah, I don't think a range in floating point can ever be expected to be inclusive anyway.

[akien-mga]

Thanks!