What kind of device are you using?: iPad 6th gen, iPadOS 15.0.1
1 sentence description of the problem (I was doing _________, and then __________ happened): I was coding when i noticed “NaN” (not a number) is considered as a number.
Steps that the Hopscotch team can take to reproduce my problem every time:
Create a set text block
Write NaN in it
Quit the block
Click on it to edit the text again and it considers not a number as a number
….
I expected this to happen: not a number is not a number
But instead this happened: not a number is a number
Hopscotch’s webplayer uses the programming language JavaScript, which (ironically) considers “NaN”/Not a Number to have the same type as “regular” numbers. This means that it is the same for everyone using the language, but it is still possible that THT could implement some checks to get around this since JavaScript contains functions for checking if a number is NaN. I’m not sure what they currently do, though.
Here’s a demonstration of how JavaScript treats NaN. It’s a bit technical but some may understand:
NaN in JavaScript is considered a number because statements like "hello" * 839 still have a to return a number, but JavaScript can’t multiply with strings and still end up with a number. So they return NaN.
But this is hopscotch and JavaScript features shouldn’t be used, tht should probably make a workaround for this lol
If the number under the radical is less than 0, then return as
((√(abs(number))) + (i)) // √(-4) would return 2i instead of NaN like it normally does in this case. I made a system like this in my Advanced Function Calculator.
While NaN is considered to be type number in most programming languages, Hopscotch doesn’t really have an intended way to show NaN, and the player parses it as a string type [1], not a number type. This should be consistent in the editor.
example: NaN + 3 = NaN in most languages, but Hopscotch treats NaN like a string, so it results in NaN3 ↩︎
I think this behaviour probably makes sense in the editor, since they are number types.
The bug/unexpected behaviour is in the player, which should treat NaN as a number. Perhaps a separate bug report can be made for this issue in the webplayer.
So, does that mean we want to parse the strings NaN and Infinity as numbers if a user sets variables to those strings? If that’s the case, I agree and we should file an issue in the webplayer for that. Otherwise, if they’re still going to be treated as normal strings when a user enters those, then the bug is in the editor.