Page 1 of 3
Text string bug
Posted: Wed Dec 22, 2021 4:01 am
by 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
Re: Text string bug
Posted: Wed Dec 22, 2021 9:19 am
by jmburnod
Hi,
Welcome to this forum
Congratulations !
I confirm this strange result
Best regards
Jean-Marc
Re: Text string bug
Posted: Wed Dec 22, 2021 10:54 am
by 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".
Re: Text string bug
Posted: Wed Dec 22, 2021 1:57 pm
by 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
Re: Text string bug
Posted: Wed Dec 22, 2021 6:36 pm
by jacque
I think it would also work if you put the strings in quotes, which forces a string comparison.
put "000" = "0E0"
Re: Text string bug
Posted: Wed Dec 22, 2021 8:04 pm
by 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.
Re: Text string bug
Posted: Wed Dec 22, 2021 9:04 pm
by 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.
Re: Text string bug
Posted: Wed Dec 22, 2021 9:10 pm
by SparkOut
Re: Text string bug
Posted: Wed Dec 22, 2021 10:27 pm
by 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
Re: Text string bug
Posted: Thu Dec 23, 2021 7:39 am
by LCMark
dunbarx wrote: ↑Wed Dec 22, 2021 10:27 pm
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?
Re: Text string bug
Posted: Thu Dec 23, 2021 2:53 pm
by 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
Re: Text string bug
Posted: Thu Dec 23, 2021 3:38 pm
by stam
LCMark wrote: ↑Thu Dec 23, 2021 7:39 am
dunbarx wrote: ↑Wed Dec 22, 2021 10:27 pm
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.
Re: Text string bug
Posted: Thu Dec 23, 2021 4:34 pm
by FourthWorld
stam wrote: ↑Thu Dec 23, 2021 3:38 pm
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...
Re: Text string bug
Posted: Thu Dec 23, 2021 4:38 pm
by dunbarx
And just like that xTalk fans began to appreciate declared data types...
Richard.
Re: Text string bug
Posted: Thu Dec 23, 2021 4:47 pm
by 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
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