I'm trying to make a game that uses 43 numbers on a cloud variable and subtracts a number for data. But then I looked at the value and it contained e+46. Since my game contains a number loading system (which is 1 and 0) it messes it up and stops loading. Anyway to bypass it?
Project

cloud variables are down rn.

Jareddddddd wrote:

cloud variables are down rn.

oh. didn't know.

But if you want multiple digits that will trigger scientific notation it sounds like you don't want to treat the variable as a number - you need to rebuild it from its component parts using join after adjusting any of the contained values.

deck26 wrote:

But if you want multiple digits that will trigger scientific notation it sounds like you don't want to treat the variable as a number - you need to rebuild it from its component parts using join after adjusting any of the contained values.

?????? didn't understand anything. all i'm trying to do is remove e+(number) and put a normal number.

Math operators (like the subtract block) have limited precision, because they store numbers in 64 bits. With really big numbers the difference between two adjacent number can be much higher than 1. Numbers that are this large are displayed in scientific notation, that's the format that has “e+” in it.
If you want to keep more than 16 digits of a number, then use string operators only (like the join block)

nembence wrote:

Math operators (like the subtract block) have limited precision, because they store numbers in 64 bits. With really big numbers the difference between two adjacent number can be much higher than 1. Numbers that are this large are displayed in scientific notation, that's the format that has “e+” in it.
If you want to keep more than 16 digits of a number, then use string operators only (like the join block)

thanks! I'll go see if it works

oh, forgot to point something out: I want to remove e+ from this calc:

alboxer2000 wrote:

nembence wrote:

Math operators (like the subtract block) have limited precision, because they store numbers in 64 bits. With really big numbers the difference between two adjacent number can be much higher than 1. Numbers that are this large are displayed in scientific notation, that's the format that has “e+” in it.
If you want to keep more than 16 digits of a number, then use string operators only (like the join block)

thanks! I'll go see if it works

oh, forgot to point something out: I want to remove e+ from this calc:

How big can variable2 and INDEX get? Is it ok to just chop the e+ part off the end?

Anytime you use a minus, plus, or other math block on a really big number, it is going to turn into an e+ number. That means you will have to either find a way to do everything without the math blocks or split the cloud variable into smaller numbers.

Usually, you can split up variables with something like the below. This script will let you extract a small number with a specific number of digits. So long as the number is small enough, you can safely do some math with it. Then, you have to put it back in the cloud variable using similar code.

imfh wrote:

alboxer2000 wrote:

nembence wrote:

Math operators (like the subtract block) have limited precision, because they store numbers in 64 bits. With really big numbers the difference between two adjacent number can be much higher than 1. Numbers that are this large are displayed in scientific notation, that's the format that has “e+” in it.
If you want to keep more than 16 digits of a number, then use string operators only (like the join block)

thanks! I'll go see if it works

oh, forgot to point something out: I want to remove e+ from this calc:

How big can variable2 and INDEX get? Is it ok to just chop the e+ part off the end?

variable2 goes up to 43 numbers, and chopping off e+ is bad, because it consists of 1's and 0's of data that get loaded. The max number I need of data is 300 numbers and I use 7 cloud variables.

A whole number or integer (not the same thing, I know, but you get the idea) in Scratch cannot have 43 digits - Scratch will discard some of the less significant digits. That is normal in computing languages since an integer, for example, might only be allocated 2 or 3 bytes of storage. Even 4 bytes of storage would only store values from approx -2 billion to +2 billion so 10 digits. This is what you have to understand.

If you handle the number as a string of digits instead you can have as many digits as you want but you have to handle any operations yourself. Otherwise Scratch takes the text string and converts it to a number and immediately you hit the problem above.

So if you actually need such large numbers you're going to have to treat them as text. If the value changes you'll need modify the text string which in Scratch terms means rebuilding the string.

This can be done but is a lot more work than sticking to values within the allowed range. One option is ot split your value into sections so the value 1234567898642 could be split into 1234567 and 898642 and if you're adding or subtracting something with 6 digits or fewer you add to the second value and deal with any overflow - eg adding 200000 would make the second value 1098642 and you'd want to add the leading 1 to the first number instead but that does leave a value that starts with a 0 as the second part and Scratch will store the value 98642 so you also need to handle that (when you join the numbers you add leading zeroes to the second number until it is of length 6).

Part of coding is understanding how the language you're using stores numbers unless you're only working with numbers it can store without issue. The same applies with rounding error in the storage of non-integer values.