Text string bug

[Andy01]

Im checking if character 1 to 3 of text string = 000 it returns true for the following sets of 3 characters 0E0 0E1 0E2 0E3 0E4 0E5 0E6 0E7 0E8 0E9
Example: put "0E0" = "000' returns true - this should return false

[jmburnod]

Hi,
Welcome to this forum
Congratulations !
I confirm this strange result
Best regards
Jean-Marc

[LCMark]

@Andy01: This isn't a bug - its a side-effect of the fact that comparison operators in LiveCode try to compare numerically and *then* as strings.

LiveCode understands exponential notation of numbers - so 0E0, 0E1, ... are all numbers - 0*10^0, 0*10^1, ... - all of which are zero.

LiveCode also allows arbitrary numbers of 0 digits to prefix a number - so 000 is also seen as zero.

As both sides are valid numbers, LiveCode will compare numerically and thus return true.

One way to ensure that you compare as strings is to prefix both strings with a non-numeric character when comparing - e.g.

Code: Select all

put ("_" & tLeft) is ("_" & tRight)

This will return false if tLeft is "000" and tRight is "0E0".

[Andy01]

Okay thanks, I see what's happening now thats very interesting. Thank you for showing me an example I was going to get around it by converting the 3 characters to ascii numbers but your example is heaps better. Cheers

[jacque]

I think it would also work if you put the strings in quotes, which forces a string comparison.

put "000" = "0E0"

[SparkOut]

No, that's the reason for the confusion.

FWIW I think quoted strings should be compared as, well, "strings". But I see where this differs from the engine comparison.

[jacque]

I'm at the computer now and you're right, is this the only instance where a quoted string isn't a string? That's pretty odd.

[SparkOut]

This reared its head here viewtopic.php?f=9&t=35244&start=15
And here https://quality.livecode.com/show_bug.cgi?id=23063

[dunbarx]

LCMArk said:

As both sides are valid numbers, LiveCode will compare numerically and thus return true.

"Compare numerically", eh? So the LC parser takes what it "sees" as numeric "strings" and ignores the quotes.

Thanks a lot, LC parser. I think that quotes around ANYTHING ought to be considered just as they appear, no strings attached. I would say that LC ought to transform the chars into their ASCII values and THEN see if they match.

I think this is, if not a bug, at the least poor thinking on the part of LC.

Craig

[LCMark]

I think this is, if not a bug, at the least poor thinking on the part of LC.

Hmmm - so you'd prefer if:

Code: Select all

put "100,200,300" into tList
if item 2 of tList < 300 then
    add 100 to item 2 of tList
end if

Didn't work and threw an error?

i.e. You had to explicitly say whether you wanted a string to be used as a number wherever you do?

[dunbarx]

Mark.

But when the "if" line is executed don't we have the simple three char string 300 (I left off the quotes for simple snarkiness ) essentially unquoted? In other words, the 300 is extracted naked from the list of items, even though those items were initially presented as a quoted string. It lives clearly as an unquoted string in that step.

In even different words, to show I appreciate the slippery slope, it seems reasonable to me that both of these lines beep:

Code: Select all

if "42" is a number then beep
if 42 is a number then beep

LC evaluates the quoted number in line 1 into a numerical string in order to decide to beep

Perhaps it is not fair to the parser to complain only in the case where comparisons are being made? But your kludge, to add an extra character to make a numerical string non-numerical in order to bypass the way things work seems to me untoward.

Craig

[stam]

I think this is, if not a bug, at the least poor thinking on the part of LC.

Hmmm - so you'd prefer if:

Code: Select all

put "100,200,300" into tList
if item 2 of tList < 300 then
    add 100 to item 2 of tList
end if

Didn't work and threw an error?

i.e. You had to explicitly say whether you wanted a string to be used as a number wherever you do?

Forgive me if i misunderstand, but even though tList is a string enclosed by quotes, item 2 of tList is not. In your example, this would be 200, not "200" and by that logic the code would work even if quotes denote a string.

I personally find it difficult having numbers in quotes being considered a number and not a string, as quotes denote text no matter what environment pretty much universally outside of LC.

[FourthWorld]

I personally find it difficult having numbers in quotes being considered a number and not a string, as quotes denote text no matter what environment pretty much universally outside of LC.

And just like that xTalk fans began to appreciate declared data types...

[dunbarx]

And just like that xTalk fans began to appreciate declared data types...

Richard.

[dunbarx]

I personally find it difficult having numbers in quotes being considered a number and not a string, as quotes denote text no matter what environment pretty much universally outside of LC.

If so, to be consistent, whatever that means, in the code:

Code: Select all

if "42" is a number then beep
if 42 is a number then beep

Line 1 really ought not to beep. That would solve all issues, no? Anything in quotes is just a string. LC need not declare variable types, (whew) and all is well.

The issue is that xTalks are, at heart, based on the engine resolving stuff, sometimes a couple of levels down, before executing that stuff. We have been nurtured on that paradigm since 1987, and cannot live any other way.

In that sense, one just has to be careful with "0E0". And maybe that is a special case that does not rear its head anywhere else?

Craig