Rock Paper Scissors: opportunity to teach evaluation of fractions, possibly dig deeper into randomization?

Boodac commented 1 week ago

Checks

[X] This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
[X] I have thoroughly read and understand The Odin Project Contributing Guide
[ ] Would you like to work on this issue?

Describe your suggestion

In the "hint" of step 2 of the assignment for Rock paper Scissors, there's a valuable lesson that can be taught to new coders:

If users do something like:

If math.random > 0.6 return rock if math.random > 0.3 return paper else return scissors

They will actually put a fairly significant mathematical skew into their results. Naturally, they'll do something more like >0.66 or >0.333, but even these can induce a significant skew in the results that will favor one result more heavily than another (you know, every hundred or thousand times, or so). The more significant digits you go, the closer you'll get to true random. This caps out at 16 digits in 64-bit encoding, where (e.g) 0.6666666666666666 === 2/3 exactly.

Obviously, this isn't mission critical for a rock paper scissors game, but it's certainly helpful to get people thinking about what their statements are actually evaluating to when they're directing black-box default functions to do things.

If possible, this would be a great opportunity to maybe link an article about floating points and when it's appropriate to use fractions. Certainly would be a great opportunity for the existing hint to be expanded.

Just a note.

Path

Foundations

Lesson Url

https://www.theodinproject.com/lessons/foundations-rock-paper-scissors

(Optional) Discord Name

boodac

(Optional) Additional Comments

To wit, if you check the code submissions, you'll find this is a COMMON error. Many people are doing things like Math.random*100 and checking it against 66 and 33, which will actually create a pretty significant break from true random.

Rajaravi99 commented 1 week ago

Hi, i am happy to work on this issue

MaoShizhong commented 1 day ago

Thanks @Boodac for the proposal.

My thoughts are that it's not really necessary for the aim of the project and that step, and we want to make sure we're deliberate in what we include in the instructions. Sure, some people might try to solve it via skewed probability but we don't really need it to be true random (after all, Math.random isn't even cryptographically secure). Plus, instead of fractions, what'd be more appropriate would be to use random integers, which the docs we link to even have an example of. Some people will come across that and adopt that approach, some won't and that's okay.

The primary purpose of that step is simply to get some random value then use conditionals with that random value to select and return a specific string. What probabilities someone uses isn't a concern here. I'm very sure that later when it comes to things that people might actually want more uniform probabilities, they can discover stuff on their own.

Paging @TheOdinProject/foundations for any additional/differing thoughts

Rajaravi99 commented 1 day ago

@MaoShizhong , yes probably you are right in that aspect. I agree.

TheOdinProject / curriculum