That is true but you should look at the two above comments. Thank you.

Not you, the one on the previous page.

duckboycool wrote:

This is also case sensitive allowing for 22 different character types, but you can't check or decode for that on the other side.

Yes you can. https://wiki.scratch.mit.edu/wiki/Case_Sensing_(2.0)

BASIC4U wrote:

duckboycool wrote:

This is also case sensitive allowing for 22 different character types, but you can't check or decode for that on the other side.

Yes you can. https://wiki.scratch.mit.edu/wiki/Case_Sensing_(2.0)

I didn't know of those methods. Learn new stuff.

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

TheLogFather wrote:

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

That isn't reliable though, as 100000000 is 0x5F5E100 so if you'd join it it'd be 0x5F5E1005F5E100 which results in some obsurd number… right?

Hexadecimal on Scratch only works on letters a-f. You have to work around that…

f1lip wrote:

Hexadecimal on Scratch only works on letters a-f. You have to work around that…

I have already, making things hexadecimal was the easy part… the hard part is making it work for large numbers as scratch hates large numbers

asivi wrote:

http://thestarman.pcministry.com/asm/6to64bits.htm

I took a look at that and it's exactly what I need, arbitrary precision base 16… I found a converter for it here with open source code: http://www.danvk.org/hex2dec.html but I can't figure out how to implement it into scratch…. any tips?

GizzB wrote:

TheLogFather wrote:

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

That isn't reliable though, as 100000000 is 0x5F5E100 so if you'd join it it'd be 0x5F5E1005F5E100 which results in some obsurd number… right?

If you're storing more than one number you can either use a fixed number of digits per value or precede each value with its length so you know how many digits it has.

deck26 wrote:

GizzB wrote:

TheLogFather wrote:

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

That isn't reliable though, as 100000000 is 0x5F5E100 so if you'd join it it'd be 0x5F5E1005F5E100 which results in some obsurd number… right?

If you're storing more than one number you can either use a fixed number of digits per value or precede each value with its length so you know how many digits it has.

Not accurate for hex though, for example, the last digit of the first block could be 1 and the first digit of the second block could be 5… so it would be stored as xxxxxxxx1 5xxxxxxxx and pieced like that… when actually it could've meant F

GizzB wrote:

deck26 wrote:

GizzB wrote:

TheLogFather wrote:

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

That isn't reliable though, as 100000000 is 0x5F5E100 so if you'd join it it'd be 0x5F5E1005F5E100 which results in some obsurd number… right?

If you're storing more than one number you can either use a fixed number of digits per value or precede each value with its length so you know how many digits it has.

Not accurate for hex though, for example, the last digit of the first block could be 1 and the first digit of the second block could be 5… so it would be stored as xxxxxxxx1 5xxxxxxxx and pieced like that… when actually it could've meant F

Of course it's accurate. Let's assume I want no hex value with more than 20 hex digits but in my string I may have values of different lengths.

05xxxxx10yyyyyyyyyyyyyyyy07zzzzzzz is clearly specified as a 5 digit value, then a 16 digit value and then a 7 digit value. I can even choose to use decimal for the lengths if I prefer which in this case would just mean changing that hex value 10 to 16. What's the problem?

deck26 wrote:

GizzB wrote:

deck26 wrote:

GizzB wrote:

TheLogFather wrote:

Scratch uses double-precision floating-point to store numerical values. That means you have a maximum of 16(ish) digits for an integer.

As deck26 said, you must NOT use mathematical operations on such large strings of digits, but you should use string operators instead (which will also mean you can drop the leading one, as deck26 said).

If you want to convert to hex using mathematical operators, you must only do it on smaller ‘chunks’ of digits, not the whole thing.

For example, don't convert the 18 digit string “102030405060708090” to hex. Instead, split it into, say, two chunks of 9 digits, and convert each of those chunks, padding each conversion with leading zeros if necessary (to get to some fixed length), and then join.

(Also, there's really no difference between converting to hex and converting to case-sensitive hex, except the range of ‘digits’ it has. You just need a case-sensitive digit detector when converting back to decimal.)

Hope that helps!

That isn't reliable though, as 100000000 is 0x5F5E100 so if you'd join it it'd be 0x5F5E1005F5E100 which results in some obsurd number… right?

If you're storing more than one number you can either use a fixed number of digits per value or precede each value with its length so you know how many digits it has.

Not accurate for hex though, for example, the last digit of the first block could be 1 and the first digit of the second block could be 5… so it would be stored as xxxxxxxx1 5xxxxxxxx and pieced like that… when actually it could've meant F

Of course it's accurate. Let's assume I want no hex value with more than 20 hex digits but in my string I may have values of different lengths.

05xxxxx10yyyyyyyyyyyyyyyy07zzzzzzz is clearly specified as a 5 digit value, then a 16 digit value and then a 7 digit value. I can even choose to use decimal for the lengths if I prefer which in this case would just mean changing that hex value 10 to 16. What's the problem?

You just blew my mind xD

Wow, I missed all of this – didn't follow this topic. (Pity, since I would've answered your question straight away.)

As deck was saying above (and as I was meaning before), you can work in ‘chunks’ of hex digits of known, limited lengths, and you just convert back and forth as much as you want for each chunk.

I do this all the time in my case-sensitive-hex-based cloud encode/decode project. There really is no difficulty here.

TheLogFather wrote:

Wow, I missed all of this – didn't follow this topic. (Pity, since I would've answered your question straight away.)

As deck was saying above (and as I was meaning before), you can work in ‘chunks’ of hex digits of known, limited lengths, and you just convert back and forth as much as you want for each chunk.

I do this all the time in my case-sensitive-hex-based cloud encode/decode project. There really is no difficulty here.

Your project doesn't encode the data though?
Encoding “255255” results in encoded data of;

0x2255255F

GizzB wrote:

TheLogFather wrote:

Wow, I missed all of this – didn't follow this topic. (Pity, since I would've answered your question straight away.)

As deck was saying above (and as I was meaning before), you can work in ‘chunks’ of hex digits of known, limited lengths, and you just convert back and forth as much as you want for each chunk.

I do this all the time in my case-sensitive-hex-based cloud encode/decode project. There really is no difficulty here.

Your project doesn't encode the data though?
Encoding “255255” results in encoded data of;

0x2255255F

It uses different ways to encode different data types, with a different prefix for each type.

Positive numerical values are encoded with a prefix of “2” (negative with prefix of “a”), and then it keeps the subsequent digits of the string the same (but it encodes a non-digit character, such as +, -, space, dot, into some hex character), with “F” marking end of the data.

Some others it encodes much more tightly (for example, zero is encoded as a single “0”, “Infinity” is encoded as a single “4”, and boolean “False” is encoded as a single “5”), so their prefix is the whole of the data too.

Strings are encoded with a prefix of “8”, then using a pair of case-insensitive hex digits for each character (allowing nearly 500 possible characters), up until it reaches “FF” which marks end of the data.


The point is, you're thinking in a far too restricted way. You're thinking about hex all the time, as if you need to convert between decimal and hex, etc.

You don't. All you need to do is *encode* (each chunk of) data in such a way that you know how to get it all back, i.e. how to decode (each chunk of data). And you can do that however you see fit for your purposes!

TheLogFather wrote:

GizzB wrote:

TheLogFather wrote:

Wow, I missed all of this – didn't follow this topic. (Pity, since I would've answered your question straight away.)

As deck was saying above (and as I was meaning before), you can work in ‘chunks’ of hex digits of known, limited lengths, and you just convert back and forth as much as you want for each chunk.

I do this all the time in my case-sensitive-hex-based cloud encode/decode project. There really is no difficulty here.

Your project doesn't encode the data though?
Encoding “255255” results in encoded data of;

0x2255255F

It uses different ways to encode different data types, with a different prefix for each type.

Positive numerical values are encoded with a prefix of “2” (negative with prefix of “a”), and then it keeps the subsequent digits of the string the same (but it encodes a non-digit character, such as +, -, space, dot, into some hex character), with “F” marking end of the data.

Some others it encodes much more tightly (for example, zero is encoded as a single “0”, “Infinity” is encoded as a single “4”, and boolean “False” is encoded as a single “5”), so their prefix is the whole of the data too.

Strings are encoded with a prefix of “8”, then using a pair of case-insensitive hex digits for each character (allowing nearly 500 possible characters), up until it reaches “FF” which marks end of the data.


The point is, you're thinking in a far too restricted way. You're thinking about hex all the time, as if you need to convert between decimal and hex, etc.

You don't. All you need to do is *encode* (each chunk of) data in such a way that you know how to get it all back, i.e. how to decode (each chunk of data). And you can do that however you see fit for your purposes!

I see, well my idea is to make it all hex as it's very efficient at compressing… the only issue is I need to get arbitrary hex in scratch as opposed to normal hex.

GizzB wrote:

TheLogFather wrote:

GizzB wrote:

TheLogFather wrote:

Wow, I missed all of this – didn't follow this topic. (Pity, since I would've answered your question straight away.)

As deck was saying above (and as I was meaning before), you can work in ‘chunks’ of hex digits of known, limited lengths, and you just convert back and forth as much as you want for each chunk.

I do this all the time in my case-sensitive-hex-based cloud encode/decode project. There really is no difficulty here.

Your project doesn't encode the data though?
Encoding “255255” results in encoded data of;

0x2255255F

It uses different ways to encode different data types, with a different prefix for each type.

Positive numerical values are encoded with a prefix of “2” (negative with prefix of “a”), and then it keeps the subsequent digits of the string the same (but it encodes a non-digit character, such as +, -, space, dot, into some hex character), with “F” marking end of the data.

Some others it encodes much more tightly (for example, zero is encoded as a single “0”, “Infinity” is encoded as a single “4”, and boolean “False” is encoded as a single “5”), so their prefix is the whole of the data too.

Strings are encoded with a prefix of “8”, then using a pair of case-insensitive hex digits for each character (allowing nearly 500 possible characters), up until it reaches “FF” which marks end of the data.


The point is, you're thinking in a far too restricted way. You're thinking about hex all the time, as if you need to convert between decimal and hex, etc.

You don't. All you need to do is *encode* (each chunk of) data in such a way that you know how to get it all back, i.e. how to decode (each chunk of data). And you can do that however you see fit for your purposes!

I see, well my idea is to make it all hex as it's very efficient at compressing… the only issue is I need to get arbitrary hex in scratch as opposed to normal hex.

In your other topic I've explained why you're only saving about 1 digit in 6 so it's not that efficient actually.

For anyone who wants to convert hexadecimal to decimal, I have created the shortest possible code for doing so, available at https://scratch.mit.edu/projects/356320752/

How do you open
hex