Jump to content

Search In
• More options...
Find results that contain...
Find results in...

# Does gsap.utils.random include or exclude its min/max?

## Recommended Posts

Hi guys,

I'm wondering if gsap.utils.random include its min/max values, or it's only between both. If I'm doing between 0, 1.

Will it only give 0.00001 and 0.99999 on its extreme ends?

'm asking this because most random functions exclude its min but includes its max, etc.

Is there a way to include both or choosing either as options?

##### Share on other sites

According to this, I think you've got it backwards - it's typically inclusive of the min, but exclusive of the max. GSAP uses Math.random() under the hood for its gsap.utils.random() method, of course, so it'd follow that behavior.

And no, there isn't a way to change that behavior. I'm curious why you'd ever want to. What's the use case? In my 15-ish years of programming, I don't think I've ever come across the need for that, so I'm curious. I bet there's another way to solve the problem you're facing.

• 2
##### Share on other sites

Oops, yes I think I got it backwards. Ah, actually I'm asking this not because of a problem I'm facing. It's also more due to curiosity and a little bit of OCD.

In spoken language terms if you say a number is 'between' 1 and 5. It would mean it's either 2, 3 or 4.
And if you say a number is 'from' 1 to 5. It would mean it's either 1, 2, 3, 4 or 5.

But in the case of performing a gsap.utils.random( 1, 5 ). It actually means it's either 1, 2, 3 or 4. ( According to your answer and also the Math.random() doc. )
It has always felt weird to me that it doesn't fit neither the language of 'between' or 'from'.

When I'm using Math.random I usually do up a small utility like the last example in the doc you linked to where I can include both min and max. So I just thought maybe for gsap.utils.random() it's something like that or have an option to do so.

##### Share on other sites

Oh and speaking of the use case, I'm wondering, if you random() an object's position from 0 to the screen's width. It means that there is a small chance of it being at 0 position but no chance of it being in the xwidth of the screen no? Isn't that like a 0.0000001% left leaning random result? But yea it's more OCD than actual practical reason I guess. 🤷🏻‍♀️

##### Share on other sites

10 hours ago, Learning said:

In spoken language terms if you say a number is 'between' 1 and 5. It would mean it's either 2, 3 or 4.
And if you say a number is 'from' 1 to 5. It would mean it's either 1, 2, 3, 4 or 5.

Actually, I don't think that's true because we perform rounding in that case anyway. In other words, if you're asking for a random integer between 1 and 5, it'll get a range between 1 and 4.999999999 and then do the rounding, thus there's still very much a chance you'll get 5 because anything 4.5 and above would get rounded there. See what I mean?

##### Share on other sites

But if you do rounding, then that means from 1 - 1.49 gets 1, and 1.5 to 2.49 gets 2... etc. It's still not a fair result. 1 and 5 gets a smaller range of results than the rest of the numbers no?

##### Share on other sites

That's quite a testable hypothesis:

```const counts = {1: 0, 2: 0, 3: 0, 4: 0, 5: 0};
for(let i = 0; i < 10000; i++) {
const num = gsap.utils.random(1, 5, 1);
counts[num]++;
}
console.log(counts);```

You're correct - 1 and 5 would be chosen less.

But that's the correct behavior since you're telling it to round and giving it those bounds. If you don't want that to happen (you want 1 and 5 to be chosen just as often) then you can easily adjust your range to accommodate for the rounding:

`const num = gsap.utils.random(0.5, 5.49999, 1);`

• 2
• 1
##### Share on other sites

@ZachSaucier Yup, that's what I was thinking, cos when people say random( 1, 5 ), they kinda thought it will be fairly evenly spread through the numbers, but because of the inclusion and exclusion, but not many people realise this. Or is it just me? Heh. 🤷🏻‍♀️

##### Share on other sites

Yeah, although I doubt it would actually matter in most real-world situations, I don't mind tweaking the code to spread the values more evenly toward the min/max. You can preview that in the upcoming release at https://assets.codepen.io/16327/gsap-latest-beta.min.js 👍

• 3
##### Share on other sites

@GreenSock Omg, that sounds awesome. It makes the ocd in me super happy. Hehehe.

##### Share on other sites

@GreenSock That's potentially a breaking change for people who are already using GSAP's random functionality. Under what circumstances did you add the modified ranges?

##### Share on other sites

3 hours ago, ZachSaucier said:

@GreenSock That's potentially a breaking change for people who are already using GSAP's random functionality. Under what circumstances did you add the modified ranges?

I'm not sure I understand - could you describe a scenario in which this would cause something to break? My understanding (and intent) was that it merely solves the issue of the uneven spread at the very minimum and maximum values. Are you saying you think people wrote code that depends on it being uneven...and that we should continue to support that instead of making it more even?

##### Share on other sites

29 minutes ago, GreenSock said:

Are you saying you think people wrote code that depends on it being uneven...and that we should continue to support that instead of making it more even?

Yes, that's what I was saying.

As I explained above, the behavior that existed at the start of this thread is technically correct. The proposed new behavior is, I would argue, less technically correct. Instead it assumes what people are wanting. I would argue that it's better to stick with what was because GSAP makes no assumptions. Add on top of that that it could possibly mess up what people already have.

##### Share on other sites

5 minutes ago, ZachSaucier said:

the behavior that existed at the start of this thread is technically correct.

That's debatable. An argument could be made either way but frankly I find the new behavior more intuitive.

6 minutes ago, ZachSaucier said:

The proposed new behavior is, I would argue, less technically correct.

I don't really understand that claim. How is it less technically correct to have the spread be even instead of clumping toward the middle?

7 minutes ago, ZachSaucier said:

Add on top of that that it could possibly mess up what people already have.

Can you give me a practical example? I'm not saying it isn't true, but I'm really struggling to think of an actual case where this might happen. If anything, I'd guess that most developers would appreciate the "improved" even spread (if anyone even notices).

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now
• ### Recently Browsing   0 members

• No registered users viewing this page.
×