Learning Posted December 13, 2020 Posted December 13, 2020 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?
GreenSock Posted December 13, 2020 Posted December 13, 2020 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
Learning Posted December 13, 2020 Author Posted December 13, 2020 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.
Learning Posted December 13, 2020 Author Posted December 13, 2020 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. ??♀️
GreenSock Posted December 13, 2020 Posted December 13, 2020 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?
Learning Posted December 14, 2020 Author Posted December 14, 2020 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?
ZachSaucier Posted December 14, 2020 Posted December 14, 2020 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
Learning Posted December 15, 2020 Author Posted December 15, 2020 @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. ??♀️
GreenSock Posted December 15, 2020 Posted December 15, 2020 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
Learning Posted December 15, 2020 Author Posted December 15, 2020 @GreenSock Omg, that sounds awesome. It makes the ocd in me super happy. Hehehe.
ZachSaucier Posted December 15, 2020 Posted December 15, 2020 @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?
GreenSock Posted December 15, 2020 Posted December 15, 2020 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?
ZachSaucier Posted December 15, 2020 Posted December 15, 2020 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.
GreenSock Posted December 15, 2020 Posted December 15, 2020 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).
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now