Scratch

IPurdie · 2012-06-26 07:37:59

More a curiosity than a bug!

Using simple blocks, try entering:

say <[heoll] = [hello]>

(gives false)

say <[heoll] < [hello]>

(gives false)

say <[heoll] > [hello]>

(gives true)

So heoll and hello are obviously evaluated somehow numerically if one can be larger than the other. Fine, but...

set [TEST1 v] to [heoll]
set [TEST2 v] to [hello]
say <(TEST1) + (TEST2)>

(gives zero)

OK, so maybe hello evaulates to -1 and heoll evaluates to 0 ? Nope:

set [TEST1 v] to [heoll]
say <(TEST1) + [2]>

(result = 2)

set [TEST2 v] to [hello]
say <(TEST2) + [2]>

(result = 2)

So heoll and hello *are* the same. But at the same time heoll > hello.

I know there's some technical reason in there for this to happen (maybe they're different by very, very small amounts?), and it's a silly little thing to spot but it does give a perfect example for my classes as to why they should be using variable types with proper definitions when we move onto Visual Basic! smile

777w · 2012-06-26 07:43:07

hmm very interesting

Wes64 · 2012-06-26 08:18:09

They are both undefined values, which when put into numerical functions such as equals and greater than, report 0. I don't know why the > one reports true, but it doesn't matter.

This isn't really a bug because you aren't supposed to use those functions that way anyways.

operationDEADTREE · 2012-06-26 08:34:42

Wes64 wrote:
They are both undefined values, which when put into numerical functions such as equals and greater than, report 0. I don't know why the > one reports true, but it doesn't matter.

This isn't really a bug because you aren't supposed to use those functions that way anyways.

why not?

Wes64 · 2012-06-26 08:37:47

operationDEADTREE wrote:
Wes64 wrote:
They are both undefined values, which when put into numerical functions such as equals and greater than, report 0. I don't know why the > one reports true, but it doesn't matter.

This isn't really a bug because you aren't supposed to use those functions that way anyways.
why not?

There is no mathematical solution for something like this.

<[apple] > [pie]>

scimonster · 2012-06-26 08:44:38

It's not an error at all, but rather some complicated casting. When you compare strings in the <> operators, it evaluates alphabetically, so that a<b, and g>e. When you use a string, any string, in a numerical insert, it treats it as having a value of 0.

Scratch

archived forums

#1 2012-06-26 07:37:59

Logic error

#2 2012-06-26 07:43:07

Re: Logic error

#3 2012-06-26 08:18:09

Re: Logic error

#4 2012-06-26 08:34:42

Re: Logic error

Wes64 wrote:

#5 2012-06-26 08:37:47

Re: Logic error

operationDEADTREE wrote:

Wes64 wrote:

#6 2012-06-26 08:44:38

Re: Logic error

Board footer