My latest project, The Catenative Doomsday Dice Cascader, uses a lot of random numbers to function. It only has whole numbers for the number generators. However, when the numbers get really big, such as if the initial roll was a 5 or 6, one of the numbers will be a decimal. I checked the scripts and made it generate some more numbers using the same parameters, and it still gave me decimals. I checked what the range of the number generator was, and there were no decimals. This is really bothersome and I would appreciate help with fixing the problem.

This is nothing wrong with your script. My guess is that scratch simply can't handle the large numbers. Anything over 10^10 in a pick random block seems to output a number with decimals. If you don't want decimals, either use smaller numbers or use the round block

DD-8861 wrote:

This is nothing wrong with your script. My guess is that scratch simply can't handle the large numbers. Anything over 10^10 in a pick random block seems to output a number with decimals. If you don't want decimals, either use smaller numbers or use the round block

Apologies, but neither solution seems like it would work. The first one (smaller numbers) would mean I would have to sacrifice the project being exactly like the Catenative Doomsday Dice Cascader from Problem Sleuth. The second one (rounding) would work if it weren't for the fact that sometimes it rolls higher than the maximum with the decimals for some reason. I can still use that one, but it won't completely fix the problem.

You can try dividing you max number by 2 and add it back together so if it is 0-100 then set a to pick ramdom 0-50 ,set b to pick ramdom 0-50 then add a and b together

When you want to display the number you could use the join operator which may convert it to text and remove the decimal places.

The text you join at the start is empty, not a space.
You can still do maths if you joined an empty piece of text.

When you put values into the “pick random” block, Scratch checks to see if they are both integers. If not then it returns a decimal random instead of an integer random.

However, the internal “int” type only goes from -2^31 to 2^31-1, which means if you give anything outside this range then Scratch will decide it's not an integer…


Furthermore, Scratch's “pick random” block is based on Flash's Math.random() function (which itself is likely based on some OS RNG) that gives floating-point values in the range zero to one.

To return an integer in some range, Scratch simply multiplies the value returned by Math.random (that was in range zero to one) by the range requested in the “pick random” block (i.e. end minus start), and then adds the start value – and then rounds it, if it's meant to be an integer (which it thinks it isn't if one of the values is too large).

However, the way the standard OS RNGs are implemented means they only actually return a total of 2^31 possible values – they basically find a random integer in range zero to 2^31-1 and then it's divided by 2^31 to get a value in range zero to one(-ish) for Math.random().

Consequently, there's no point trying to pick a random integer out of a range that's greater than 2^31, since it'll have some bias due to the limited resolution of the internal random function. –In fact, even a considerably smaller range will start to have bias, because of the resolution (so a range of 2^31 / 10, with non-integers, can only give a decimal part that's heavily related to the integer part).


You can see some implications of the above in the following investigation project:

https://scratch.mit.edu/projects/96080245/


My advice would be to write your own ‘pick random’ custom block that can deal with larger values.

I'd suggest something like this:

You should note that above is limited to a range of 10^14 – and you can't really go much beyond that anyway, since Scratch's numerical values are limited to ~15 decimal digits of accuracy (since they are internally stored as double-precision floating-point values).

Hope that helps!

TheLogFather wrote:

When you put values into the “pick random” block, Scratch checks to see if they are both integers. If not then it returns a decimal random instead of an integer random.

However, the internal “int” type only goes from -2^31 to 2^31-1, which means if you give anything outside this range then Scratch will decide it's not an integer…


Furthermore, Scratch's “pick random” block is based on Flash's Math.random() function (which itself is likely based on some OS RNG) that gives floating-point values in the range zero to one.

To return an integer in some range, Scratch simply multiplies the value returned by Math.random (that was in range zero to one) by the range requested in the “pick random” block (i.e. end minus start), and then adds the start value – and then rounds it, if it's meant to be an integer (which it thinks it isn't if one of the values is too large).

However, the way the standard OS RNGs are implemented means they only actually return a total of 2^31 possible values – they basically find a random integer in range zero to 2^31-1 and then it's divided by 2^31 to get a value in range zero to one(-ish) for Math.random().

Consequently, there's no point trying to pick a random integer out of a range that's greater than 2^31, since it'll have some bias due to the limited resolution of the internal random function. –In fact, even a considerably smaller range will start to have bias, because of the resolution (so a range of 2^31 / 10, with non-integers, can only give a decimal part that's heavily related to the integer part).


You can see some implications of the above in the following investigation project:

https://scratch.mit.edu/projects/96080245/


My advice would be to write your own ‘pick random’ custom block that can deal with larger values.

I'd suggest something like this:

You should note that above is limited to a range of 10^14 – and you can't really go much beyond that anyway, since Scratch's numerical values are limited to ~15 decimal digits of accuracy (since they are internally stored as double-precision floating-point values).

Hope that helps!

Yes, I suppose I should use your script to make things easier, considering that my project can go up to 6^32 due to its die-rolling properties. Thanks!

Firephantom105 wrote:

Yes, I suppose I should use your script to make things easier, considering that my project can go up to 6^32 due to its die-rolling properties. Thanks!

Double-precision floating-point arithmetic will not be accurate for integers as large as 6^32. (The limit, of ~15 digits, comes out at a bit under 6^20.)

If you want to work with such large integers then you will have to either create your own arithmetic operations that can work with such things, or you will have to rethink how your project works.

Perhaps you can explain a bit more exactly what it's meant to be doing? What are the operations you want to do? What are your goals/aims?

You can do this: