Discuss Scratch

ECLIPSE-STUDIOS
Scratcher
100+ posts

[Fixed]

Hi,

I'm working on a project that requires Hexadecimal to Decimal conversions and I was using a list to do so when I came across the issue that, both online and offline, even when put directly in an <> = <> block, <0024> = <024E> always returns true, which is a little… not true?

After a bit of investigating, this happens when both numbers are the same (when you exclude the 0s in front, ie 0024 becomes 24 and 024E becomes 24E), and only with the letter E. So 000000096 = 096E too etc.

My browser / operating system: Windows NT 10.0, Chrome 57.0.2987.133, Flash 25.0 (release 0)

Last edited by ECLIPSE-STUDIOS (April 8, 2017 17:05:25)


3D, Isometric Game Engine!
Make your own Isometric game easily using our engine by clicking here!

^^ Full How-To documentation included in the Notes & Credits
TheLogFather
Scratcher
1000+ posts

[Fixed]

Scratch looks at those strings and decides they are both numerical values.

The left one is just 24, while the right one is, in “E” notation, 24e0, which is also 24.
For “e” simply read as “times ten to the power of”. So 5e3 means 5 x10^3, i.e. 5000.

In Scratch if you want to be sure that two strings are really compared as strings, not as numbers, then you have to ensure the comparison *cannot possibly* be considered to be numerical.

I usually do this by prepending a letter, for example:
<(join [a] (var1)) = (join [a] (var2))>

If you start to store long strings of digits (e.g. for cloud), and you start to compare these long strings, then you'll run into this too (since a long string of digits is a numerical value, but numerical value can only be accurate to ~16 digits, so two different strings of digits will be ‘equal’ if the first 16 digits are the same and they are the same length – or, worse, if they are both longer than ~310 digits then Scratch will consider them to both be Infinity [and so equal] no matter what digits they contain!)

There's an argument could be made that Scratch could make better decisions here. But the problem is that you're always likely to eventually find a case that it *doesn't* manage to catch, and understanding the exact situation that causes it to happen becomes more and more convoluted the more ‘clever’ you try to make it at catching these cases, so it's arguably worth finding out about this issue, and learning how to work around it, sooner rather than later.

Last edited by TheLogFather (April 8, 2017 14:36:33)


Siggy the Kumquat slayer:
Main account: DadOfMrLog –– Frameworks for basic pen-rendered 3D in scratch (see studio). Examples:

- - - - 3D Text - - - - - - Simple shapes - - - Controllable structures - - - On the ground - - - - - - In space - - - -

ECLIPSE-STUDIOS
Scratcher
100+ posts

[Fixed]

TheLogFather wrote:

Scratch looks at those strings and decides they are both numerical values.

The left one is just 24, while the right one is, in “E” notation, 24e0, which is also 24.
For “e” simply read as “times ten to the power of”. So 5e3 means 5 x10^3, i.e. 5000.

In Scratch if you want to be sure that two strings are really compared as strings, not as numbers, then you have to ensure the comparison *cannot possibly* be considered to be numerical.

I usually do this by prepending a letter, for example:
<(join [a] (var1)) = (join [a] (var2))>

If you start to store long strings of digits (e.g. for cloud), and you start to compare these long strings, then you'll run into this too (since a long string of digits is a numerical value, but numerical value can only be accurate to ~16 digits, so two different strings of digits will be ‘equal’ if the first 16 digits are the same and they are the same length – or, worse, if they are both longer than ~310 digits then Scratch will consider them to both be Infinity [and so equal] no matter what digits they contain!)

There's an argument could be made that Scratch could make better decisions here. But the problem is that you're always likely to eventually find a case that it *doesn't* manage to catch, and understanding the exact situation that causes it to happen becomes more and more convoluted the more ‘clever’ you try to make it at catching these cases, so it's arguably worth finding out about this issue, and learning how to work around it, sooner rather than later.


Aaaahhhhh. That makes sense. I've stuck a letter in front than my workaround, since I fixed mine by checking the last letters were the same (since 0024 did equal 024E, but 0 does not equal just the letter E), which was bit longer.

Thanks!

3D, Isometric Game Engine!
Make your own Isometric game easily using our engine by clicking here!

^^ Full How-To documentation included in the Notes & Credits
naazsimra
New to Scratch
6 posts

[Fixed]

TheLogFather wrote:

Scratch looks at those strings and decides they are both numerical values.

The left one is just 24, while the right one is, in “E” notation, 24e0, which is also 24.
For “e” simply read as “times ten to the power of”. So 5e3 means 5 x10^3, i.e. 5000.

In Scratch if you want to be sure that two strings are really compared as strings, not as numbers, then you have to ensure the comparison *cannot possibly* be considered to be numerical.

I usually do this by prepending a letter, for example:
<(join [a] (var1)) = (join [a] (var2))>

If you start to store long strings of digits (e.g. for cloud), and you start to compare these long strings, then you'll run into this too (since a long string of digits is a numerical value, but numerical value can only be accurate to ~16 digits, so two different strings of digits will be ‘equal’ if the first 16 digits are the same and they are the same length – or, worse, if they are both longer than ~310 digits then Scratch will consider them to both be Infinity [and so equal] no matter what digits they contain!)

There's an argument could be made that Scratch could make better decisions here. But the problem is that you're always likely to eventually find a case that it *doesn't* manage to catch, and understanding the exact situation that causes it to happen becomes more and more convoluted the more ‘clever’ you try to make it at catching these cases, so it's arguably worth finding out about this issue, and learning how to work around it, sooner rather than later.

ok thanks

Last edited by naazsimra (Aug. 15, 2020 06:57:33)

Powered by DjangoBB