Scratch-vm: Variable stops increasing eventually, but should go up to "infinity"

[jwzimmer]

Expected Behavior

The value should go up until it displays "infinity"; it shouldn't get stuck at a specific numerical value and stop increasing.

Actual Behavior

The value gets fairly large quickly in the stack as shown, then slows down in its rate of increase. If you edit the value in the forever loop for how much the value is increasing by, you can lower the value to get the increase of the variable to speed up again. Eventually the value of the variable stops increasing at all, even if you lower the rate of change back to 1. However, you can get to a much larger value if you change what values are in the loop.

Steps to Reproduce

• Add a new variable
• Drag out the blocks as shown in the screenshots for Stack 1
• Click to start the stack
• While the stack is active, edit the values in the pick random block to change how quickly the variable value increases
• Eventually the value will get "stuck"
• Then even if you lower the values in the pick random block, it will remain stuck
• If you change to Stack 2, note you can get to a much larger value
  
  
  
  • We should probably be consistent
  
  

Stack 1

Stack 2
Increasing the number of 0's in the divisor:

I may have hit some kind of limit eventually - after I dropped the block stack in the toolbox and it was deleted, I noticed the variable value was "infinity":

Operating System and Browser

_Mac OS El Capitan, Chrome 59_

[mrjacobbloom]

I'd prefer no limit until JS hits infinity -- that's the same as it is in 2.0, and it allows for more precise math. Maybe show fewer significant digits if it's in e-notation?

[jwzimmer]

I did eventually hit "Infinity" as a value with Stack 2, so maybe the question in this case shouldn't be whether there should be a size limit (it should just be "infinity"), but instead to investigate why Stack 1 stops increasing the variable value at some point - maybe that's just the bug...

[SillyInventor]

This is because, for int input, random returns:
return low + parseInt(Math.random() * (high + 1 - low), 10);
But to quote the JS specs for parseInt:

Because some numbers include the e character in their string representation (e.g. 6.022e23), using parseInt to truncate numeric values will produce unexpected results when used on very large or very small numbers. parseInt should not be used as a substitute for Math.floor().

To solve this problem you must deal with it as a string.

[CatsAreFluffy]

Wait, why is parseInt being used for rounding?