Re: This is disturbing!
> Bob S wrote:
> There is already a string keyword.
>
True. ‘Stringify()’ or ‘’evaluateAsString()’
It’s easy enough to write a function to force string comparisons for those rare
edge cases like "6. " is equal to "6.” where the engine automatically converts
the strings to numbers.
function compareAsStrings string1, string2
return string1 & "a" = string2 & "a"
end compareAsStrings
compareAsStrings("6. ","6.") returns FALSE.
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Yes. Bob S > On Sep 6, 2018, at 13:07 , Richmond Mathewson via use-livecode > wrote: > > I wonder is the reason "6" and "6." are treated as the same is because "6." > is read as "6.0"? > > Late to the party, I know . . . > > Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
There is already a string keyword. Bob S > On Sep 6, 2018, at 21:53 , Jim Lambert via use-livecode > wrote: > > >> RichardG wrote: >> Any suggestions for a new operator token to specify numeric equivalence? > > Or maybe to specify string equivalence. > >> Did anyone know that "6. " is equal to "6."??? > > string( "6. “) is not equal to string( "6.”) > > where the function string() would tell LC not to try to convert the string > into a number, but simply leave it as a literal string for comparison > purposes. > > Of course, another way to prevent LC from converting a textual number into an > actual number is to append a string to the textual number: > > whereas "6. “ = "6.” returns TRUE > "6. “ & “a” = "6.” & “a” returns FALSE. > > Jim Lambert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Hi We had the same "problem" in Foxpro because of the Dbase legacy. Here is a partial list of comparisosn with the SET EXACT switch setting OFF ON OFF or ON "abc" = "abc" Yes Yes Yes -- 1 "ab" = "abc" No No No -- 2 "abc" = "ab" Yes No No -- 3 "abc" = "ab_" No No No -- 4 "ab" = "ab_" No Yes No -- 5 "ab_" = "ab" Yes Yes No -- 6 "" = "ab" No No No -- 7 "ab" = "" Yes NoNo -- 8 ... You get the picture the reason that 7 and 8 look weird is because (I believe) that the comparison scans the length of the operand which in this case is zero length, so the strings match up upto the zeroth character So why this list? Because without breaking any code we can have a setting - no different to itemdelimiter or numeric format etc like SET EXACT on or off and the engine could do the "right thing". But the right thing to me is not the right thing to you, it's an edge case and the programmer should know his data.. So here is the simplest way out of any pickle, and changes to the docs to explain this to knew programmers function EQ p1, p2 return (space & p1 = space & p2) end EQ On Mouseup local s1, s2 put "6." into s1 put "6. " into s2 answer "S1 = s2 is " & (s1 = s2) answer "S1 = s2 is " & EQ(s1 = s2) end Mouseup And why doesn't my Python Program work - oh "You have an extra space"!! If there ever was the most stupid design decision of ANY language that must have been indentation as part of the syntax - and the second - Case sensitivity - because I want to Use "NAME" and "name" to help me differentiate Adults from children Oh and while in Rant mode don'y get me stated on PHP ... Case sensitive variables, constants, array keys, class properties, class constants Case insensitive functions, class constructors, class methods, keywords and constructs (if, else, null, foreach, echo etc.) So count your blessings ... Regards Lagi On Fri, 7 Sep 2018 at 03:42, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Mike Kerner wrote: > > I like the is vs = idea. > > Me too, but I'm afraid decades of code across the entire xTalk world > form a substantial enough legacy to render the change prohibitive. > > Any suggestions for a new operator token to specify numeric equivalence? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
> RichardG wrote: > Any suggestions for a new operator token to specify numeric equivalence? Or maybe to specify string equivalence. > Did anyone know that "6. " is equal to "6."??? string( "6. “) is not equal to string( "6.”) where the function string() would tell LC not to try to convert the string into a number, but simply leave it as a literal string for comparison purposes. Of course, another way to prevent LC from converting a textual number into an actual number is to append a string to the textual number: whereas "6. “ = "6.” returns TRUE "6. “ & “a” = "6.” & “a” returns FALSE. Jim Lambert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Mike Kerner wrote: I like the is vs = idea. Me too, but I'm afraid decades of code across the entire xTalk world form a substantial enough legacy to render the change prohibitive. Any suggestions for a new operator token to specify numeric equivalence? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Bob Sneidar wrote: > Yes, but it's the kind of thing that can bite a new programmer in the > butt. HyperTalk had a reputation for being difficult to learn. ;) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
"bite a new programmer in the butt" . . . well, as a person who was a
new programmer in 1975 and found
things very difficult to understand at first (FORTRAN IV) I certainly
don't remember having a sore bottom!
I do know, that is numerical calculations empty spaces are exactly that:
empty space.
While in string variables empty spaces are text.
The problem might arrise because LiveCode seems not to differentiate (on
the surface at least) between
numerical variable and string variables.
Richmond.
On 6/9/2018 10:47 pm, Bob Sneidar via use-livecode wrote:
Yes, but it's the kind of thing that can bite a new programmer in the butt. And the trouble with
your comparison is that length("7. ") IS equal to length("6. "). So multiple
comparisons have to be made. But this is an edge case I admit. I was only trying to maintain an
index number for a TreeView widget, since the arrayData is not numerically indexed making sorting
by order added a pain. I ended up using a datagrid anyway.
Bob S
On Sep 6, 2018, at 12:34 , Jim Lambert via use-livecode
wrote:
Did anyone know that "6. " is equal to "6."???
It’s somewhat similar to
value(“h “) is equal to value(“h”),
while
“h “ is not equal to “h”.
I’m not disturbed but appreciative that the engine tries to convert both sides
to numbers when doing a comparison. Just must remember that and use more
“string-y” ways to compare strings as only strings.
For example other functions can reveal the strings “6. “ and “6.” are not the
same string, such as length(“6. “) is not equal to length( “6.”).
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
I wonder is the reason "6" and "6." are treated as the same is because "6." is read as "6.0"? Late to the party, I know . . . Richmond. On 6/9/2018 10:34 pm, Jim Lambert via use-livecode wrote: Did anyone know that "6. " is equal to "6."??? It’s somewhat similar to value(“h “) is equal to value(“h”), while “h “ is not equal to “h”. I’m not disturbed but appreciative that the engine tries to convert both sides to numbers when doing a comparison. Just must remember that and use more “string-y” ways to compare strings as only strings. For example other functions can reveal the strings “6. “ and “6.” are not the same string, such as length(“6. “) is not equal to length( “6.”). Jim Lambert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Yes, but it's the kind of thing that can bite a new programmer in the butt. And
the trouble with your comparison is that length("7. ") IS equal to length("6.
"). So multiple comparisons have to be made. But this is an edge case I admit.
I was only trying to maintain an index number for a TreeView widget, since the
arrayData is not numerically indexed making sorting by order added a pain. I
ended up using a datagrid anyway.
Bob S
> On Sep 6, 2018, at 12:34 , Jim Lambert via use-livecode
> wrote:
>
>> Did anyone know that "6. " is equal to "6."???
>
> It’s somewhat similar to
> value(“h “) is equal to value(“h”),
> while
> “h “ is not equal to “h”.
>
> I’m not disturbed but appreciative that the engine tries to convert both
> sides to numbers when doing a comparison. Just must remember that and use
> more “string-y” ways to compare strings as only strings.
> For example other functions can reveal the strings “6. “ and “6.” are not the
> same string, such as length(“6. “) is not equal to length( “6.”).
>
> Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
> Did anyone know that "6. " is equal to "6."??? It’s somewhat similar to value(“h “) is equal to value(“h”), while “h “ is not equal to “h”. I’m not disturbed but appreciative that the engine tries to convert both sides to numbers when doing a comparison. Just must remember that and use more “string-y” ways to compare strings as only strings. For example other functions can reveal the strings “6. “ and “6.” are not the same string, such as length(“6. “) is not equal to length( “6.”). Jim Lambert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
I like the is vs = idea. I disagree with Paul that this is a price of it being typeless. No other whitespace character in LC seems to cause this behavior. It's not really true that it's typeless e.g. a blob (even though technically a blob is a type). It's just that the typing is implied and the coercion is also implied. On Thu, Sep 6, 2018 at 1:52 PM Tom Glod via use-livecode < use-livecode@lists.runrev.com> wrote: > I have come across this before . I think what I encountered was "" = > 0 > > I had to do a workaround, figured it was a a decision based on other engine > factors. > > I can see it being ok in 99% of cases. > > > On Thu, Sep 6, 2018 at 1:25 PM Mike Kerner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Ignoring the leading or trailing whitespace is weird and > counterintuitive. > > If the language was more perfect, I think it would first not ignore the > > other characters in the string no matter what they look like, then do the > > implicit type coercion and then the comparison, even though there are > > definitely use cases where 1≠1.0≠1.00, but those sorts of edge > > cases perhaps better left documented and not handled. > > In all cases, where intuition and behavior are not in line, the manual > > should fill in the gap. > > > > > > On Thu, Sep 6, 2018 at 1:02 PM Mark Waddingham via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > On 2018-09-06 18:52, Mike Kerner via use-livecode wrote: > > > > Right. If the explanation is clear then it's not an issue (even if > it > > > > is a > > > > little weird - "6.abc"="6.xyz" is false but "6." is "6." is > > > > true) > > > > > > Well the explanation can be fixed :) > > > > > > Its hard to say whether the language would be better or worse if only > > > 'strict' numeric strings were considered equal. After all you'd still > > > have that "1.0" is "1" is "1.0" is ... which whilst more obvious > > > perhaps, still means you have to work harder to do strict string > > > equality checking (or comparison). > > > > > > Warmest Regards, > > > > > > Mark. > > > > > > -- > > > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > > > LiveCode: Everyone can create apps > > > > > > ___ > > > use-livecode mailing list > > > use-livecode@lists.runrev.com > > > Please visit this url to subscribe, unsubscribe and manage your > > > subscription preferences: > > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > > > > > -- > > On the first day, God created the heavens and the Earth > > On the second day, God created the oceans. > > On the third day, God put the animals on hold for a few hours, > >and did a little diving. > > And God said, "This is good." > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
I have come across this before . I think what I encountered was "" = 0 I had to do a workaround, figured it was a a decision based on other engine factors. I can see it being ok in 99% of cases. On Thu, Sep 6, 2018 at 1:25 PM Mike Kerner via use-livecode < use-livecode@lists.runrev.com> wrote: > Ignoring the leading or trailing whitespace is weird and counterintuitive. > If the language was more perfect, I think it would first not ignore the > other characters in the string no matter what they look like, then do the > implicit type coercion and then the comparison, even though there are > definitely use cases where 1≠1.0≠1.00, but those sorts of edge > cases perhaps better left documented and not handled. > In all cases, where intuition and behavior are not in line, the manual > should fill in the gap. > > > On Thu, Sep 6, 2018 at 1:02 PM Mark Waddingham via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > On 2018-09-06 18:52, Mike Kerner via use-livecode wrote: > > > Right. If the explanation is clear then it's not an issue (even if it > > > is a > > > little weird - "6.abc"="6.xyz" is false but "6." is "6." is > > > true) > > > > Well the explanation can be fixed :) > > > > Its hard to say whether the language would be better or worse if only > > 'strict' numeric strings were considered equal. After all you'd still > > have that "1.0" is "1" is "1.0" is ... which whilst more obvious > > perhaps, still means you have to work harder to do strict string > > equality checking (or comparison). > > > > Warmest Regards, > > > > Mark. > > > > -- > > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > > LiveCode: Everyone can create apps > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, >and did a little diving. > And God said, "This is good." > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Ignoring the leading or trailing whitespace is weird and counterintuitive. If the language was more perfect, I think it would first not ignore the other characters in the string no matter what they look like, then do the implicit type coercion and then the comparison, even though there are definitely use cases where 1≠1.0≠1.00, but those sorts of edge cases perhaps better left documented and not handled. In all cases, where intuition and behavior are not in line, the manual should fill in the gap. On Thu, Sep 6, 2018 at 1:02 PM Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > On 2018-09-06 18:52, Mike Kerner via use-livecode wrote: > > Right. If the explanation is clear then it's not an issue (even if it > > is a > > little weird - "6.abc"="6.xyz" is false but "6." is "6." is > > true) > > Well the explanation can be fixed :) > > Its hard to say whether the language would be better or worse if only > 'strict' numeric strings were considered equal. After all you'd still > have that "1.0" is "1" is "1.0" is ... which whilst more obvious > perhaps, still means you have to work harder to do strict string > equality checking (or comparison). > > Warmest Regards, > > Mark. > > -- > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 9/6/2018 11:46 AM, Bob Sneidar via use-livecode wrote: > Did anyone know that "6. " is equal to "6."??? > > THAT is disturbing! So now we have to check the length of a string as well to > make sure there is an exact match??? > This is the price of having a "type-less" programming language. "6." get evaluated to see if it is numeric, which it is an is treated as the number 6. Likewise with "6. " and 6 does equal 6. Now, in typed language, you would have declared both things as STRINGs and you would get a false. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
By way of rehtoric, and by no means a suggestion of any change in the engine, it might have been better if "is" did a strict string comparison, while "=" or "is equal to" attempted a numerical type conversion, and reverted to a string comparison if either arguement failed. What *might* be possible is adding support for "exactly equal to" or "==" where 1.0 == 1 is still true, but "1.0" == "1" is not. Bob S > On Sep 6, 2018, at 10:01 , Mark Waddingham via use-livecode > wrote: > >> Right. If the explanation is clear then it's not an issue (even if it is a >> little weird - "6.abc"="6.xyz" is false but "6." is "6." is true) > > Well the explanation can be fixed :) > > Its hard to say whether the language would be better or worse if only > 'strict' numeric strings were considered equal. After all you'd still have > that "1.0" is "1" is "1.0" is ... which whilst more obvious perhaps, > still means you have to work harder to do strict string equality checking (or > comparison). > > Warmest Regards, > > Mark. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 2018-09-06 18:52, Mike Kerner via use-livecode wrote: Right. If the explanation is clear then it's not an issue (even if it is a little weird - "6.abc"="6.xyz" is false but "6." is "6." is true) Well the explanation can be fixed :) Its hard to say whether the language would be better or worse if only 'strict' numeric strings were considered equal. After all you'd still have that "1.0" is "1" is "1.0" is ... which whilst more obvious perhaps, still means you have to work harder to do strict string equality checking (or comparison). Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Right. If the explanation is clear then it's not an issue (even if it is a little weird - "6.abc"="6.xyz" is false but "6." is "6." is true) On Thu, Sep 6, 2018 at 12:43 PM Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > On 2018-09-06 18:21, Mark Wieder via use-livecode wrote: > > Yeah. IMO automatic type conversion is one of the failure points of > > the xtalk paradigm, but it's always been thus. > > To be fair, in the days of HyperCard when everything was strings (and > numbers were decimal strings) the rules worked absolutely fine I think. > > However, the use of doubles as the internal rep for numbers, and > introduction of arrays broke a few invariants a consistent > implementation of the above view relies upon - hence the annoying points > of friction. > > I don't think implicit type conversion is the problem per-se - just the > precise details of what gets converted to what, and the inability to say > 'at this point, this needs to actually be a '. > > If you want to be abstract about it then you can view a programming > language as a compression algorithm - it is a way to express a set of > possible outcomes in a linear sequence of text. With that point of view, > they suffer exactly the same problem as any compression algorithm > suffers - all compression algorithms will expand some input. > > i.e. What you might gain in some places in terms of ease / clarity / > ability; you will lose elsewhere - the hard bit is making sure that such > cases are 'edge' cases and easily avoided. > > Warmest Regards, > > Mark. > > -- > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 2018-09-06 18:21, Mark Wieder via use-livecode wrote: Yeah. IMO automatic type conversion is one of the failure points of the xtalk paradigm, but it's always been thus. To be fair, in the days of HyperCard when everything was strings (and numbers were decimal strings) the rules worked absolutely fine I think. However, the use of doubles as the internal rep for numbers, and introduction of arrays broke a few invariants a consistent implementation of the above view relies upon - hence the annoying points of friction. I don't think implicit type conversion is the problem per-se - just the precise details of what gets converted to what, and the inability to say 'at this point, this needs to actually be a '. If you want to be abstract about it then you can view a programming language as a compression algorithm - it is a way to express a set of possible outcomes in a linear sequence of text. With that point of view, they suffer exactly the same problem as any compression algorithm suffers - all compression algorithms will expand some input. i.e. What you might gain in some places in terms of ease / clarity / ability; you will lose elsewhere - the hard bit is making sure that such cases are 'edge' cases and easily avoided. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 2018-09-06 18:14, Mike Kerner via use-livecode wrote: Dictionary: First, if you look in the operands, it says *The operands value1 and value2 can be numbers, literal strings of characters (delimited with double quotes), or any sources of value, including arrays.* The example for comparing two strings is "ABC" = "abc" -- true if and only if caseSensitive is false To be fair, the 'is' entry it doesn't say anything about what is interpreted 'as a string' explicitly - it just says 'literal strings of characters (delimited by double quotes)' - however as worded it is a little misleading. All the comparison operator docs could do with some revision to make the actual behavior crystal clear :D Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 09/06/2018 09:06 AM, Mark Waddingham via use-livecode wrote: P.S. The engine has *always* worked like this - as have xTalks in general. It's why you never have to put any explicit type conversion anywhere when you are interchanging anything and things still work as expected. Yeah. IMO automatic type conversion is one of the failure points of the xtalk paradigm, but it's always been thus. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
so the description seems to imply that the comparison should be as strings if double-quotes are included around the literals. On Thu, Sep 6, 2018 at 12:14 PM Mike Kerner wrote: > Dictionary: > First, if you look in the operands, it says > *The operands value1 and value2 can be numbers, literal strings of > characters (delimited with double quotes), or any sources of value, > including arrays.* > The example for comparing two strings is > > "ABC" = "abc" -- true if and only if caseSensitive is false > > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
Dictionary: First, if you look in the operands, it says *The operands value1 and value2 can be numbers, literal strings of characters (delimited with double quotes), or any sources of value, including arrays.* The example for comparing two strings is "ABC" = "abc" -- true if and only if caseSensitive is false ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
On 2018-09-06 18:02, Mike Kerner via use-livecode wrote: dictionary says when comparing strings we go char by char, and says that quotes around the literal causes it to be evaluated as a string. Where in the dictionary? That should be revised. Quotes make no difference - numbers and strings which look like numbers are treated the same... When doing comparisons, the engine tries to convert both sides to numbers before comparing, if both sides are numbers they are compared as numbers. Both '1 is 1.0' or '"1" is "1.0"' have the same result. Warmest Regards, Mark. P.S. The engine has *always* worked like this - as have xTalks in general. It's why you never have to put any explicit type conversion anywhere when you are interchanging anything and things still work as expected. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
It seems as long as all characters in the string can be numerical values, they are treated as such. Space is treated as whitespace or empty. My guess for «6» + «6» to return 12 was right. Tore Nilsen --- This mail contains no viruses or bacteria as it is electronically produced and untouched by human hands. Once printed it may or may not contain various microorganisms that can cause diseases. Print and hand out at own risk. Unsolicited distribution of this mail is prohibited. > 06. sep. 2018 kl. 18:02 skrev Tore Nilsen via use-livecode > : > > I think this is because the dot is also the decimal sign. Therefore it > interprets the strings as numerical values. And = and is are synonyms. > I guess if you write something like put «6» + «6» you will get 12 as the > result. > > Best regards > Tore Nilsen > > --- > This mail contains no viruses or bacteria as it is electronically produced > and untouched by human hands. Once printed it may or may not contain various > microorganisms that can cause diseases. Print and hand out at own risk. > Unsolicited distribution of this mail is prohibited. > > > > > > > >> 06. sep. 2018 kl. 17:57 skrev Mike Kerner via use-livecode >> : >> >> If I put anything else in place of the dot, I get a fail, but with the dot, >> i get true >> >> On Thu, Sep 6, 2018 at 11:55 AM Tore Nilsen via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> It seems to only compare the integer part of the statements. If you >>> substitute the integer with a letter, then it reports false. But still >>> strange as the quotation marks should indicates that this is a string. >>> >>> Best regards >>> Tore Nilsen >>> >>> --- >>> This mail contains no viruses or bacteria as it is electronically produced >>> and untouched by human hands. Once printed it may or may not contain >>> various microorganisms that can cause diseases. Print and hand out at own >>> risk. Unsolicited distribution of this mail is prohibited. >>> >>> >>> >>> >>> >>> >>> 06. sep. 2018 kl. 17:46 skrev Bob Sneidar via use-livecode < >>> use-livecode@lists.runrev.com>: Did anyone know that "6. " is equal to "6."??? THAT is disturbing! So now we have to check the length of a string as >>> well to make sure there is an exact match??? Bob S ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode >>> >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >> >> >> -- >> On the first day, God created the heavens and the Earth >> On the second day, God created the oceans. >> On the third day, God put the animals on hold for a few hours, >> and did a little diving. >> And God said, "This is good." >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
dictionary says when comparing strings we go char by char, and says that quotes around the literal causes it to be evaluated as a string. On Thu, Sep 6, 2018 at 11:57 AM Mike Kerner wrote: > If I put anything else in place of the dot, I get a fail, but with the > dot, i get true > > On Thu, Sep 6, 2018 at 11:55 AM Tore Nilsen via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> It seems to only compare the integer part of the statements. If you >> substitute the integer with a letter, then it reports false. But still >> strange as the quotation marks should indicates that this is a string. >> >> Best regards >> Tore Nilsen >> >> --- >> This mail contains no viruses or bacteria as it is electronically >> produced and untouched by human hands. Once printed it may or may not >> contain various microorganisms that can cause diseases. Print and hand out >> at own risk. Unsolicited distribution of this mail is prohibited. >> >> >> >> >> >> >> >> > 06. sep. 2018 kl. 17:46 skrev Bob Sneidar via use-livecode < >> use-livecode@lists.runrev.com>: >> > >> > Did anyone know that "6. " is equal to "6."??? >> > >> > THAT is disturbing! So now we have to check the length of a string as >> well to make sure there is an exact match??? >> > >> > Bob S >> > >> > >> > ___ >> > use-livecode mailing list >> > use-livecode@lists.runrev.com >> > Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> > http://lists.runrev.com/mailman/listinfo/use-livecode >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, >and did a little diving. > And God said, "This is good." > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
I think this is because the dot is also the decimal sign. Therefore it interprets the strings as numerical values. And = and is are synonyms. I guess if you write something like put «6» + «6» you will get 12 as the result. Best regards Tore Nilsen --- This mail contains no viruses or bacteria as it is electronically produced and untouched by human hands. Once printed it may or may not contain various microorganisms that can cause diseases. Print and hand out at own risk. Unsolicited distribution of this mail is prohibited. > 06. sep. 2018 kl. 17:57 skrev Mike Kerner via use-livecode > : > > If I put anything else in place of the dot, I get a fail, but with the dot, > i get true > > On Thu, Sep 6, 2018 at 11:55 AM Tore Nilsen via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> It seems to only compare the integer part of the statements. If you >> substitute the integer with a letter, then it reports false. But still >> strange as the quotation marks should indicates that this is a string. >> >> Best regards >> Tore Nilsen >> >> --- >> This mail contains no viruses or bacteria as it is electronically produced >> and untouched by human hands. Once printed it may or may not contain >> various microorganisms that can cause diseases. Print and hand out at own >> risk. Unsolicited distribution of this mail is prohibited. >> >> >> >> >> >> >> >>> 06. sep. 2018 kl. 17:46 skrev Bob Sneidar via use-livecode < >> use-livecode@lists.runrev.com>: >>> >>> Did anyone know that "6. " is equal to "6."??? >>> >>> THAT is disturbing! So now we have to check the length of a string as >> well to make sure there is an exact match??? >>> >>> Bob S >>> >>> >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, > and did a little diving. > And God said, "This is good." > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
If I put anything else in place of the dot, I get a fail, but with the dot, i get true On Thu, Sep 6, 2018 at 11:55 AM Tore Nilsen via use-livecode < use-livecode@lists.runrev.com> wrote: > It seems to only compare the integer part of the statements. If you > substitute the integer with a letter, then it reports false. But still > strange as the quotation marks should indicates that this is a string. > > Best regards > Tore Nilsen > > --- > This mail contains no viruses or bacteria as it is electronically produced > and untouched by human hands. Once printed it may or may not contain > various microorganisms that can cause diseases. Print and hand out at own > risk. Unsolicited distribution of this mail is prohibited. > > > > > > > > > 06. sep. 2018 kl. 17:46 skrev Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com>: > > > > Did anyone know that "6. " is equal to "6."??? > > > > THAT is disturbing! So now we have to check the length of a string as > well to make sure there is an exact match??? > > > > Bob S > > > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
wow. that's not cool. I just tried "is" and yep. is. On Thu, Sep 6, 2018 at 11:47 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Did anyone know that "6. " is equal to "6."??? > > THAT is disturbing! So now we have to check the length of a string as well > to make sure there is an exact match??? > > Bob S > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: This is disturbing!
It seems to only compare the integer part of the statements. If you substitute the integer with a letter, then it reports false. But still strange as the quotation marks should indicates that this is a string. Best regards Tore Nilsen --- This mail contains no viruses or bacteria as it is electronically produced and untouched by human hands. Once printed it may or may not contain various microorganisms that can cause diseases. Print and hand out at own risk. Unsolicited distribution of this mail is prohibited. > 06. sep. 2018 kl. 17:46 skrev Bob Sneidar via use-livecode > : > > Did anyone know that "6. " is equal to "6."??? > > THAT is disturbing! So now we have to check the length of a string as well to > make sure there is an exact match??? > > Bob S > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
