Number Guesser - An oversight feedback

I think it would be best to warn the student that the human input value is stored as a string. If like me someone solves the exercise by using just a series of ifs with a strict operator in the compareGuesses function, some results won’t return true.
I had to go to game.js and change
const currentHumanGuess = parseInt(humanGuessInput.value);
Took me a lot of time to figure that out but hey, at least I finally learned how to use the browser’s Debugger feature. Yay for me.

That was not the prescribed approach. This problem is solvable without even knowing that file exists. We should definitely not be changing it, or even need to for our solution to work.

4 Likes

I know that. But the point I’m trying to make is that with my approach it makes it impossible to work without knowing that the input is stored as a string and needs to be converted to int if a strict comparison is to be used. Even if the parsing is done inside the compareGuesses function and not on game.js, one needs to be aware that it will have to be done. Here’s my solution:

const compareGuesses = (humanNumber, computerNumber, secretNumber) => {
  if ((humanNumber === computerNumber) && (humanNumber === secretNumber)) {
    return true;
  } else if ((humanNumber === computerNumber) && (humanNumber !== secretNumber)) {
    return true;
  } else if (humanNumber === secretNumber) {
    return true;
  } else if ((humanNumber > secretNumber) && (humanNumber < computerNumber)) {
    return true;
  } else if ((humanNumber < secretNumber) && (humanNumber > computerNumber)) {
    return true;
  } else {
    return false;
  }
};

Sorry if I didn’t solve the way you guys wanted. I’m still learning and I’m trying my best. Different people with different skill levels will come up with different solutions. I don’t think it’s unreasonable to ask that others be at least warned of that.

3 Likes

We are permitted to expect perfect world scenarios when writing code for a lesson. That’s why the game.js module is there, to ensure it. We assume that our inputs will be accepted, but also have mental constraints on what those inputs will be. In other words, given valid inputs, the code will work as expected.

We do not at this stage even need to understand the minutia or finer details, just accept that our code is getting the correct support, whatever that may entail.

Our own variations or derivations are actually not of much interest in this particular case, but better suited to general discussion on the ideas and themes one derives from the courses.

Bottom line, solve the problem as the SCT expects, and keep learning. Bookmark the lesson and come back when ready to flex one’s wings and explore in greater detail. Post one’s findings in the General forum to foster further discussion, but that is outside of the focused forum of the lessons, proper. Make sense?

1 Like

And it fails at that by not either:

  1. Storing the game.js’ currentHumanGuess variable value as an Integer
    or
  2. Warning the student in the script.js that the human parameter in the compareGuesses function is being stored as a string and needs parsing

That’s a technical flaw, you’re expecting the student to solve a problem he/she doesn’t and won’t even know it exists.

No, it doesn’t. I don’t even think we’re on the same page here. You’ve been giving me blanketed and vague answers. It makes me think you’re not even familiar with the exercise’s code and what I’m referring to; from the get-go you - consciously or not - have been trying to discredit my feedback by pointing out I edited game.js even though that’s not the point of my feedback.

I’m trying to show that if one of those two points I stated earlier are not implemented, some potential solutions to the exercise that a student might come up with(for example mine, that uses just a series of strict comparisons) won’t give the correct output and the student won’t know why since the code works for most cases but not all and it doesn’t return any error messages.

I was just trying to help and make the exercise better by covering more ground but I guess the staff here are not very open to feedback.

Sorry, I’m not staff and have no control over curriculum. Lacking a link to the exercise, I opined. You caught me out.

Typically, CC does not respond to feedback given in the forums. Many of these types of posts go unanswered.

Please post a link and I’ll invite somebody to examine the lesson.

https://www.codecademy.com/practice/projects/number-guesser-independent-practice

Sorry, I didn’t get an e-mail notification and I only saw your reply now.

I’d be very appreciated if you could contact the staff and pass along this message:

The exercise states that the student shouldn’t need to modify or even look at game.js for the game to work as intended, however, because humanGuessInput.value is stored as a String and not an Integer, it could happen - as it did with me - that the student might solve the exercise by doing strict comparisons on the compareGuesses function. That would make the game fail only those specific results since different data types are being compared and there’s no implicit conversion. More importantly, no error is displayed, so a student might not do a very thorough testing and move on while under the impression everything is working as intended.

I propose to solve this issue by either:

  1. Parsing and storing the game.js’ currentHumanGuess variable value as an Integer
    or
  2. Warning the student in the script.js that the human parameter in the compareGuesses function is being stored as a string and might need parsing

Hello @renanmdp.

I would propose that the simpler, and more appropriate solution would be to warn the learner against using the strict equality operator since the input from the player will be stored as a string by default. There is no reason to use the strict equality operator for the comparison. The equality operator == does the conversion for us. From the documentation:
" The equality operator converts the operands if they are not of the same type , then applies strict comparison."

Hello.

I wouldn’t have used a strict equality operator if I had known of that. The reason I went with strict operators in the first place is because given the project’s name, Number Guesser, I reasonably assumed that every number input would be, well, a number.

Anyway, be as it may, that’s my feedback. Thanks for listening to me and sorry If I inconvenienced anyone. I was genuinely just trying to help.

1 Like

No worries. You should feel good that you encountered a problem, did research, came up with a solution, and completed the project. It wasn’t the way most people would have done it, but you were determined to do it your way, and you did. You learned a few things along the way. You’ve now got a few more tools in your bag than you had before. Keep up the good work, and thanks for caring enough to offer suggestions! Happy coding!

1 Like

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