Change:
"Here's the formula we'll use. Take a moment to read it and try to understand what this code is doing:", "<code>Math.floor(Math.random() * (max - min + 1)) + min</code>", "Define two variables: <code>myMin</code> and </code>myMax</code>, and set them both equal to numbers.", <del> "Then create a function called <code>myFunction</code> that returns a random number that's greater than or equal to <code>myMin</code>, and is less than <code>myMax</code>." </del> <ins> "Then create a function called <code>myFunction</code> that returns a random number that's greater than or equal to <code>myMin</code>, and is less than or equal to <code>myMax</code>." </ins> ], "tests": [ "assert(myFunction() >= myMin, 'message: The random number generated by <code>myFunction</code> should be greater than or equal to your minimum number, <code>myMin</code>.');",

Discussion:
Challenge has an issue. User Agent is: <codeMozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36</code. Please describe how to reproduce this issue, and include links to screenshots if possible. My code: The instructions for this way point say: (emphasis ) However, the formula provided () is inclusive of the upper bound. The correct formula for an exclusive max is It may be intended that campers should catch this and change the formula, but using the inclusive formula will still pass the tests. I believe that either the description of the task should be changed, or the tests should be more stringent and there should be an indication that the formula needs to be modified.
!
Your code does not match the provided sample. You removed the from after .
Yes I know that,because the random number by myFunction should be less than or equal to your maximum number Remember: or equal
The is what makes it inclusive (less than or equal too). To be strictly less-than, you would omit the . Now that the instructions have been fixed, the is appropriate. That was the premise of this Issue.
Became aware of this while discussing the in chat. It appears that while the wording was changed to be for an inclusive range the tests still pass for an exclusive range. ! may have been referencing this but it appears his code was not passing back then but it would now. !
This is very difficult to test. Previously we had a horrible massive Regex that tried to look for the explicit code, which caused no end of trouble. Here are the current tests: The only way I could see to improve this would be to write a loop in the "tail" section (which executes after the user code) that, for example, did 100 or 1000 calls to the random function and collected min and max values. Now, there is no gaurentee that we'd always get a min and max . . . But that's pretty much the only way I can think of testing this "for real". I'd like to hear what the other have to say - is it worth the risk to do some sort of looping structure, or do we just want to leave it as is?

As the function is random, it won't necessarily catch the min or max values. One thing you could do is accept this "feature" and just educate the camper as much as possible on what the function is really doing. So to do so, I suggest first adding a note as a reminder on the specifics on what the function does. Secondly, you can then reference the if they get stuck, as it gives some really good examples on how it builds up the given equation. The downside to this approach is that you really could just copy-paste the example from MDN and not really learn. However, I believe in the honesty and curiosity of FCC coders trying to learn :) And if these changes are made, we could change it back to making the upper end exclusive and noting you will have to change the original formula. Given all these additional hints and instructions, it'll hopefully make it more clear on what needs to be changed to the original given formula with the .
Doesn't that cover it? I'm pretty sure we've re-written all 3 random number challenges since this issue was opened.
It does, but it would have been two challenges ago. I think it would just be a friendly reminder of that small detail.
I could see a full explanation of this formula: Probably needs some wordsmithing and may be too complex.
it looks like your suggestion to loop through 100 iterations in the "tail" section . On side note, it looks like the instructions are a little redundant with the "inclusive" and "or equal to" part:
I believe the instructions got updated as well. I'm going to close this as resolved.
just "return ()" is ok!