Value comparison of numbers and groups of chars

[sritcp]

Playing around with the operators, I noticed

put empty > 20200120 - - false
put space > 20200120 - - false
put space > empty - - true
put -1 > space - - true
put "text" > 20200120 - - true
put (space & "text") > 20200120 - - false
put ("text" & space) > 20200120 - - true
put (space & 20200121) > 20200120 - - true

Am I correct that the ASCII values of the first char of each is compared? (except with numbers, where redundant spaces are removed)

This would mean that I should remove the spaces and make sure the two candidates are actually numbers before I compare them. (Retrieving a number from a file, the program sometimes returns an error message - which is text).

I couldn't find a relevant discussion in the user manual.

Regards,
Sri

[bogs]

Well, "empty" means "nothing", so I don't find the following (in bold) to be of any surprise -

1.) put empty > 20200120 - - false # something is greater than nothing...
2.) put space > 20200120 - - false
3.) put space > empty - - true # a space is a character, empty is not...
4.) put -1 > space - - true
5.) put "text" > 20200120 - - true
6.) put (space & "text") > 20200120 - - false
7.) put ("text" & space) > 20200120 - - true
8.) put (space & 20200121) > 20200120 - - true

As to the ones *not* in bold, my thinking would be (and i could be wrong) -

* space > 20200120 - - false # space is 1 character, 20200120 is 8 characters, therefore 8 would be greater than 1...
* -1 > space - - true # again, you have a - and 1 character, equaling 2 characters...
* put "text" > 20200120 - - true # not sure, unless quoted strings have greater weight than numbers...

Again, my take *might* not be accurate, as I see a quoted string in a few more, but the order of operation is different. It could also be general weirdness caused by non-nonsensical operations, as I don't think I've ever seen someone comparing relative values between text and digits before, so the engine spits up 'potluck' answers.

Hopefully one of the longer timers will chime in heh, it is an interesting question.

[dunbarx]

Hi.

Operators, like ">", compare two values character by character, using the ASCII values at each step. That is why "b" is greater than "a", "5" > "4", and "abs" > "abc". The caseSensitive property is important if you compare "A" to "a", since "A" is ASCII 65, whereas "a" is ASCII 97.

"Empty" has ASCII, er, empty, which is less than 1.

Do you have a particular issue?

Craig

[sritcp]

Do you have a particular issue?

Hi Craig:

My program required comparing two numbers, each stored in a file.
put URL tRemoteFileURL into t1
put URL tLocalFileURL into t2
If t1>t2 then .......
etc., etc.

When the remote file access returned an error (which was in text form) instead of the file contents, it passed the t1>t2 condition (which is not what I wanted)! This led me to experiment a little bit, and I was somewhat nonplussed by the results, that's all.

I have changed the code to check if the file content is a number before carrying out the comparison.

Thanks,
Sri