[Computer Choice: Part 2] Instruction mistake?


#1

If computerChoice is between 0 and 0.33, make computerChoice equal to "rock".
If computerChoice is between 0.34 and 0.66, make computerChoice equal to "paper".
If computerChoice is between 0.67 and 1, make computerChoice equal to "scissors"

I think above instruction is poorly written. Above rule does not cover 0.332, 0.66594938, etc.
Actually else{ } will cover them.
Since there won't be error messages, it will silently ruin the whole program.

Edit: On second thought, it won't really ruin the program. Computer will choose scissors with slightly higher probability. If this was homework, you would lose few points.

It may sound like splitting hairs, but I hope you fix above wording or round random number to 2 decimal places.

Best.

return null

Summary

This text will be hidden


#2

Yes, it actually does cover 0.66594938 & 0.332, so not sure what you're problem is there. Else does not fix the problem.

If it was homework you would lose a few points... Um not really, since that is what the instructions want...

Hope I helped explain some...

Sean


#3

Hi. Sean
Thank you for your response. Let me first apologize for replying late.
Could you please explain how the instruction covers 0.66594938 & 0.332 ?

The following is my logic. Correct me if I am wrong.
For example, 0.332 is...
Not between 0 and 0.33, so it cannot be "rock".
Not between 0.34 and 0.66, it cannot be "paper".
Not between 0.67 and 1, it cannot be "scissors"
0.332 is between 0.33 and 0.34, which instruction does not cover.

However, since else statement would cover those gaps, I assumed that computer would choose scissors with slightly higher probability. That is why I suggested fixing the wording or rounding random number to 2 decimal places.

Thank you in advance for your time.
Best.


#4

Hello :slight_smile:

From what I learned in math, 0.33 to 0.66 would cover 0.332. Just because they use two decimal places doesn't mean that it goes farther than two decimal places, if you understand what I mean. If you've noticed, the RPS game has no errors, there are times when the # would be 0.2376789 or whatever, yet it doesn't break. Why? Because the computer knows 0.2376789 is greater than 0, but smaller than 0.33 :).

If I was wrong however, else would be awful. The chances of the computer getting a random number with more than two decimal places is so high, you could win just by typing rock.

I hope this has somewhat helped,
happy coding!
Sean B


#5

From what I learned in math, 0.33 to 0.66 would cover 0.332. Just because they use two decimal places doesn't mean that it goes farther than two decimal places, if you understand what I mean.
- chesswithsean

Hi, Sean.
Unfortunately, you've misread my point. I don't know from where you got "0.33 to 0.66."
The instruction says,

If computerChoice is between 0 and 0.33, make computerChoice equal to "rock".
If computerChoice is between 0.34 and 0.66, make computerChoice equal to "paper".
If computerChoice is between 0.67 and 1, make computerChoice equal to "scissors"

It does not say between 0 and 0.33, between 0.33 and 0.66, and so on, as you've claimed.

As you can see from above capture, there are gaps between each statements. That is why I used 0.66594938 and 0.332 as examples to show the flaw of above instruction.

If you follow the instruction, your program has to have a logic error. It won't tell you there is an error, because 'else' statement would cover those gaps and assign "scissors." That is why I said that program will run, but "scissors" will have slightly higher probability of being picked.

That is why I suggested fixing the wording or rounding random number to 2 decimal places.

Best.


#6

Yea I agree there is an error in the instructions as it doesn't cover some numbers. Another error that I find in instructions for another lesson was the FizzBuzz condition order (but I fixed that by changing the order myself in my code).

However, I agree with @chesswithsean in that putting an else just to include those numbers isn't a good idea. I would just change the range in the conditions. For example:
(computerChoice >= 0 && computerChoice < 0.34), (computerChoice >= 0.34 && computerChoice < 0.67), and an else that covers the rest.


I didn't check if these ranges are equal. It's just rough ranges for now.


#7

Hi.
Just wanna let you know that I've never suggested putting an else.

From the beginning, from the original post, I've suggested following two solutions:

It may sound like splitting hairs, but I hope you fix above wording or round random number to 2 decimal places.

Best.


#8

Yes, I know you didn't suggest it. Maybe I should change my wording to say that I agree with you and Sean about the logic flaw of else and therefore, scissors having a higher chance.

Perhaps the instructions need to be updated. I'm still fiddling around with the numbers here to make sure all three possibilities have the same probability.

This can be done on your own: Math.round(Math.random())/100 :slight_smile:
Could be a useful idea!


#9

Thank you for rapid reply.

Did you mean Math.round(Math.random() * 100)/100?
It doesn't work for some cases, though.

var x = 1.005
Math.round(x * 100) / 100 // retruns 1 rather than 1.01

From googling, Math.random().toFixed(2) seems to work. However it returns string rather than float.
It is weird that there isn't easy way to round number to specific decimal places in JS.

Best.


#10

Hm...perhaps use Math.ceil then. And yea, I meant that, oops.

var computerChoice = Math.ceil(Math.random()*100)/100; ->2 decimal places
console.log(computerChoice);
console.log(Math.ceil((1.005)*100)/100); -> 1.01

I was fiddling around.
Now, rounding floats are tricky and not always accurate. It is because floats are actually not numbers like integers! They are binary and floating point arithmetic is a bit different (this applies to many languages).

If we just focus on numbers between 0 and 1, then it's alright to use either Math.ceil or Math.round. Other situations may be different, especially if you have something like 2.405 or 3.9403.

Therefore, I think just changing the ranges in your conditional statements is the better idea to avoid inaccurate representations. The ranges I suggested passed.

This has been some brain exercise! All in all, this course is actually going to be taken down soon (Summer 2017) as there exists a new JavaScript course with (hopefully) better instructions. I believe since this course is really old, there were some flaws like this one. I didn't try the new JS course yet.


#11

I see. Thanks for the info.

Hope more people sign up for Pro version with new courses.

Best.


#12

You're right, I misunderstood :confused:


#13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.