Jump to content
Search Community

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

Learning test
Moderator Tag

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?

Link to comment
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.  

  • Like 2
Link to comment
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.

Link to comment
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. 🤷🏻‍♀️

Link to comment
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? 

Link to comment
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);

 

  • Like 2
  • Thanks 1
Link to comment
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? 

Link to comment
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. 

Link to comment
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). 

Link to comment
Share on other sites

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.
×
×
  • Create New...