1. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 26, 2003
- 426 views
Hello there, In addtion to the other interesting posts... match("",s) cant return a number greater then zero because that interpretation of the match command would only be valid when you assume that the first element of s is a null sequence, and that's not really true at all. Lets say we allow match to return a 1 for this case, then this would lead to code like this: s="xyz" i=match("","xyz") --i is now equal to the number 1 printf(1,"%s",s[i]) which would print the first character of the sequence s, which would not be the null sequence "". If we had found the correct sequence, the printf statement would have printed the null sequence, which is not the same as printing an 'x'. In the remainder of this post, i'll show why the function match(s1,s2) with either or both args equal to the null sequence "" should return a zero. A sequence, in it's more basic definition, is a container just like any other variable. It can be an empty container, or a container with something inside it. If it's an empty container, it cant hold anything of whatever is inside of a container that is NOT empty. This means that an empty container can NEVER contain anything that a non empty container contains. This applies even if the containers themselves can contain other containers. If there is nothing within the internal containers, then the most external container also contains nothing. In the case of 'match', we want to know what is the best value to return for cases when one or both operators are null, or empty containers: retv=match(container1,container2) Since an empty container cant possibly have anything that a non empty container has in it, match("abc","") already returns a zero in Euphoria. This leaves the two cases, match("","") which is almost like match("abc","") which should both return a zero, because you cant find anything within a container that doesnt have anything in it, even if the first container also doesnt have anything in it, and match("","abc") which should also return a zero because you cant find the lack of anything inside of a container that already contains something. In spite of this clear viewpoint, it might be still possible to argue against the simple conclusions drawn from this on the basis that calling the sequences 'containers' is still just another abstraction, no better than: -------------------------------------------------------------------------- match("abc","") "If you dont find something within that which has nothing, you havent found anything, and so you have found zero of anything". match("","") It's questionable if we could really find nothing among nothing, so: "If you couldnt find nothing within that which already has nothing, you have still found nothing, which is still zero of anything", and "Even if you could find nothing among that which has nothing, you would have still found nothing, which is indeed still zero of anything". match("","abc") "If you are looking for nothing within that which has something, you wont find it, and so you have found zero of anything" -------------------------------------------------------------------------- So i'll present more conclusive evidence why match("","abc") and match("","") should both also return a zero. Main reasons for a change: 1. match("abc","") already returns a zero. 2. 'nothing' is not part of 'something', so it cant be there. Validating supplementary statement: 3. no existing code would break. [1] match("abc","") returns a zero already. This means the language already admits that 'nothing' is a valid argument, otherwise it would also trigger an error. This means as it stands right now, "It's ok to look for something within nothing and not find it, but it's not ok to look for nothing within something". [2] 'nothing' is not part of 'something' in the computer world, so it cant ever be found and so a zero return value is warranted. [3] No immediate existing code would break, nor would any simply modified code break if it was written correctly in the first place. Existing code cant contain sequences which ever reach null "" (match("","abc")) or else an error would have stopped their program and they would have corrected it. Slightly modified code might then reach a state where at least one variable reaches the value "" within a match() call, which would then return a zero. Since the code would have to be able to respond to a case where match("abc","") could come up, it would already be able to respond to a zero returned from match() for the new case of "" for the first op. Really though, match(object1,object2) should be the ultimate goal of the language. I cant think of a reason why you shouldnt be able to look for 'a' in "abc" can anyone else? Especially since you can fool it: i=match('a'&"","abc") -- haha, fooled you 'match()' ! --i comes out to 1 I am therefore asserting two things to be correct: 1. Changing 'match' to return a zero when its first member is "" is the best way to handle the return value. 2. Changing 'match' as #1 states wont break any existing code. Note that im not just saying "change the match function because it's better", Im also asserting that this change wont break any existing code. For one last note, the function: global function Match(sequence a, sequence b) if length(a)<1 then return 0 end if return match(a,b) end function can be used as a replacement for match() and also wont break any existing code! Any arguments? Take care for now, Al
2. RE: match() (not short, he he)
- Posted by gertie at visionsix.com May 26, 2003
- 414 views
On 26 May 2003, at 16:00, Al Getz wrote: A nice post. But i just thought of something. All the previous posts i read on this (mine included) worked with *strings*, not nested sequences. What about: match("",{"k","","at"}) ? Kat
3. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 26, 2003
- 407 views
gertie at visionsix.com wrote: > > > On 26 May 2003, at 16:00, Al Getz wrote: > > A nice post. But i just thought of something. All the previous posts i > read on > this (mine included) worked with *strings*, not nested sequences. What > about: match("",{"k","","at"}) ? > > Kat > Hello again, I think you meant match({""},{"k","","at"}) right? I meant to mention that i noticed that match works for match({""},{"k","a","t"}) but not for match("","kat") which says that not that much thought went into the match function to begin with. The point that you brought up is useful when you want to find, say, maybe an already empty sequence within a sequence of sequences, so that you can store something there. This means we couldnt declare outer most sequences as empty if they at least contain an empty sequence. In other words, the sequence {""} cant be said to be empty, because this sequence contains an empty sequence which is something in this case, unlike when we only have "". Indeed, length({""}) returns 1, which says something is there also, while length("") returns 0, which says nothing is there at all. In light of the previous post, this means a sequence that has at least one empty sequence in it "has something contained within it and so there is indeed something that can be not only searched for, but also that can be found". I was therefore incorrect when i stated something to the contrary. As far as "" by itself goes, as in match("",something) this should always return a zero because "" implies a null character and for the reasons in the last post, so i dont change any of my assertions from the last post. match({""}, something) will have to stay the same as it is, contrary to what can be concluded from the statement that 'an empty sequence within a sequence is still an empty sequence'. If you are saying that match("",{"a","","c"}) should return the number 2, then i would argue that match("c",{"a","","c"}) would return the number 3, which it really shouldnt because match("c","axc") returns the number 3. When we deal with sequences, i would think we should have to deal with them level by level, comparing a level of one string only to a level of another string unless we have the luxury of declaring a new, more advanced function to handle a level switch or return multiple values. If you are instead saying that match("c",sequence) should search the entire sequence for a 'c', regardless of level, then you also have to return more then one value to indicate where the 'c' was actually found, and this, again, requires a more sophisticated function. Granted, it would be very useful i would think, especially since you could then use the results to access the character or string. If match returned a sequence like {1,2} you could use that to access the sequence by thing=seq[1][2] perhaps. That would be pretty interesting, except it would take lots of time to find some things in a complex nested sequence. ------> What it boils down too is the replacement of the match function with the Match function in the last post. All this does to modify the current match() is to check the first value for "", and if it's lenght is equal to zero, return a zero. Everything else stays the same. If it's length isnt zero (even contains an empty inside another sequence) then it defaults to call match(). I like your idea of being able to look for empty sequences very much, but i dont think it could apply for the empty sequence "" unless the match function suddenly gets more sophisticated as i was saying. Any other interesting ideas like that? I hope you have some more, i'd like to hear them too Take care for now, Al
4. RE: match() (not short, he he)
- Posted by gertie at visionsix.com May 26, 2003
- 398 views
On 26 May 2003, at 18:49, Al Getz wrote: > > > gertie at visionsix.com wrote: > > > > > > On 26 May 2003, at 16:00, Al Getz wrote: > > > > A nice post. But i just thought of something. All the previous posts i > > read on > > this (mine included) worked with *strings*, not nested sequences. What > > about: match("",{"k","","at"}) ? > > > > Kat > > > > Hello again, > > I think you meant > > match({""},{"k","","at"}) > > right? > > I meant to mention that i noticed that match works for > match({""},{"k","a","t"}) Because as you point out later, {""} isn't an empty or null {}. > length({""}) > returns 1, which says something is there also, while > length("") > returns 0, which says nothing is there at all. I use length() a lot, just for this sort of fault tolerance in "" strings/sequences. > Any other interesting ideas like that? > I hope you have some more, i'd like to hear them too Yes, strangely enough, i have other ideas. i'd prefer match('a',"something") to not fail because of the alledgedly abhorent reason that 'a' isn't a sequence. It's too late to change, but i'd prefer match('a',"kat") to return 2, since the 'a' in "kat" is an atom. And match("b",{"a",'b',"b","c"}) to return 3, because the third element "b" in the second parameter of match is a sequence, and the 2nd parameter isn't. I haveto test parms in match() for that first parm being a sequence all the time too. Kat
5. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 27, 2003
- 420 views
>Kat wrote: > >Yes, strangely enough, i have other ideas. > >i'd prefer > >match('a',"something") > >to not fail because of the alledgedly abhorent reason that 'a' isn't a >sequence. >It's too late to change, but i'd prefer > >match('a',"kat") > >to return 2, since the 'a' in "kat" is an atom. And > >match("b",{"a",'b',"b","c"}) >to return 3, because the third element "b" in the second parameter of >match >is a sequence, and the 2nd parameter isn't. I haveto test parms in >match() for >that first parm being a sequence all the time too. > >Kat > Hello again Kat, I dont think any of your ideas have been strange, rather, i think they hint on what all Euphoria users want in the language in one form or another. I dont think i made it quite that clear why i was saying match("b",{"a","b","c"}) should return 0 and not the number 3 though. The main reason is that match now returns a single number, which is a single dimensional quantity. The reason it has to be single dimensional is because match works on only one level of the sequence at a time. The level it searches in the second sequence is always the same as the level of the first sequence. It has to be this way, or else we wouldnt know where it was looking, and the number it returned would be meaningless to us. A simple example: match("b",{"abc"}) match("b",{"a","b","c"}) match("b",{"ab","c","d"}) match("b",{{"a","b","c"}}) These cant all return the number 2, can they? To find out, all we have to do is try using the proposed new results in a program and see what happens. In the following code, all i have done is forced match to return the number 2 for every case which i 'think' you want to see the number 2 returned. I did this simply by setting i=2 AFTER the match calls. By inspecting these results below, you will see that there is only one case where match truely returns the number 2, and it does appear to be correct. Let's try these one at a time and see... [1] s="abc" i=match("b",s) --returns 2 i=2 ?s[i] --prints >98< --works fine! [2] s={"a","b","c"} i=match("b",s) --returns 0 i=2 ?s[i] --prints >{98}< --is this correct? [3] s={"ab","c","b"} i=match("b",s) --returns 0 i=2 ?s[i] --prints >{99}< --this is clearly incorrect! [4] s={{"a","b","c"}} i=match("b",s) --returns 0 i=2 ?s[i] --subscript value 2 is out of bounds, reading from a sequence of length 1 Nobody seems to be saying that #1 above isnt correct, and that is the only one that works correctly, really. match returns 2 anyway. In #2, match returns 0 and when we force it to be a 2 we end up printing the correct number, 98, but it's inside of a sequence. Arguably, this may be interpreted to be correct in some cases, but in #3, when we apply the same idea, we get a totally incorrect result, as now we end up printing the number 99 inside a sequence, which is totally wrong. We end up printing the 'c' instead of what we were really looking for, the 'b'. in #4, we get really bad results, but again it is arguable that ?s[i] with i=0 would have done the same thing. This says that our code has to be able to handle the possibility of match returning a zero, but we still havent found the "b" nested inside of s in this example, so this fails also. The reason why some of these tests fail and some return incorrect results is because match, right now, only returns a single number. If match could return a sequence, this would change and what you want to do would work. Repeating #4 allowing match to return a sequence: [4r] s={{"a","b","c"}} i=match("b",s) --returns 0 ss={1,2,1} --'force' match to return sequence --now let's use this sequence to try to print the b: ?s[ss[1]][ss[2]][ss[3]] --prints >98< --yeahhh! Finally, we found the correct value within {{"a","b","c"}} but it took three dimensions to do it. Granted this would work, but match would have to be seriously updated Also, once found, it would be hard as heck to find the next occurance of "b" wouldnt it? Try that match() would also have to be updated to accept a starting point in the sequence, something i have always wanted in "find()". That's another story though -------> All i was asking for is that match to return a zero when the first sequence is null "" (exactly) with no regard for the second sequence. Without this, we can never use the following line in our code: while match(s1,s2) do for fear that s1 might become the null sequence at some point, as in: while match(s1,s2) do --reduce length of s1 and do other stuff end while Take care for now, Al
6. RE: match() (not short, he he)
- Posted by gertie at visionsix.com May 27, 2003
- 420 views
On 27 May 2003, at 8:39, Al Getz wrote: > > > >Kat wrote: > > > >Yes, strangely enough, i have other ideas. > > > >i'd prefer > > > >match('a',"something") > > > >to not fail because of the alledgedly abhorent reason that 'a' isn't a > >sequence. > >It's too late to change, but i'd prefer > > > >match('a',"kat") > > > >to return 2, since the 'a' in "kat" is an atom. And > > > >match("b",{"a",'b',"b","c"}) > > >to return 3, because the third element "b" in the second parameter of > >match > >is a sequence, and the 2nd parameter isn't. I haveto test parms in > >match() for > >that first parm being a sequence all the time too. > > > >Kat > > > > Hello again Kat, > > I dont think any of your ideas have been strange, rather, > i think they hint on what all Euphoria users want in the > language in one form or another. > > I dont think i made it quite that clear why i was saying > match("b",{"a","b","c"}) > should return 0 and not the number 3 though. You mean 2 ? I believe it should return 2, because match() currently looks at the top layer of the top sequence, and no deeper, which makes sense. The { } is the top layer, and it contains as it's atoms the three sequences "a" , "b", and "c". You are looking for a "b", and there is a "b" laying right there, plain as day. I can see it, i'd expect match() to see it. If i were looking for a 'b' in that example, i'd expect a 0 to be returned, because there is no top layer atomic 'b' there, it's inside a sequence, which is like another { }, which you agree(?) should not be looked into. There is, however a 'b' in "abc", because that is like an {'a','b','c'}. > The main reason is that match now returns a single number, > which is a single dimensional quantity. The reason it has > to be single dimensional is because match works on only > one level of the sequence at a time. The level it searches > in the second sequence is always the same as the level > of the first sequence. It has to be this way, or else we > wouldnt know where it was looking, and the number it returned > would be meaningless to us. I agree. > A simple example: -- I put in what i would expect > match("b",{"abc"}) -- 0 -- the "abc" is sitting on the top layer of the { }, and is the one and only element of the { }, and it's not a "b". {"abc"} is a list of one sequence. -- and, match('b',{"abc"}) = 0 -- for the same reason -- but, match('b',"abc") = 2 -- because you are looking for an atom in a list of atoms, one of which is a 'b'. > match("b",{"a","b","c"}) -- 2 --why? because the { } makes one object level, the top level, and holds it's contents. The "b" in the { } is the same as the "b" you are looking for. > match("b",{"ab","c","d"}) -- 0 because that b inside the "ab" is in an obvious sequence, and even tho it is an atom, you are looking for a "b", not a 'b'. > match("b",{{"a","b","c"}}) -- 0 There you simply have it nested too deeply. And you know that. > These cant all return the number 2, can they? Only one of those examples should. <snip> > In #2, match returns 0 and when we force it to be a 2 we end > up printing the correct number, 98, but it's inside of a sequence. > Arguably, this may be interpreted to be correct in some cases, but but it is a sequence that is exactly what you are looking for. > in #3, when we apply the same idea, we get a totally incorrect > result, as now we end up printing the number 99 inside a sequence, > which is totally wrong. We end up printing the 'c' instead of what > we were really looking for, the 'b'. No, no, no! In #3, you are looking for a sequence, and there is no "b" in #3. Your first param is a "b", you are looking for a top level object that is a sequence. The "ab" is a top level object inside the { } that forms the 2nd param, but it isn't "b". You cannot pick {"ab"} as finding "b", any more than you can do this: atom x x = 65 OR 128 ? match('A',x) and see 'A' printed out, since the bit pattern for 'A' is in x. Besides, again, in {"ab"} that b is an atom, and you are looking for a sequence. > in #4, we get really bad results, but again it is arguable that > ?s[i] with i=0 would have done the same thing. Well, i'd like to see that return a null or nil or "" or '' or something, rather than crash the interpreter. > This says that > our code has to be able to handle the possibility of match returning > a zero, but we still havent found the "b" nested inside of s in this > example, so this fails also. > > The reason why some of these tests fail and some return incorrect > results is because match, right now, only returns a single number. > If match could return a sequence, this would change and what you > want to do would work. Too confusing. Interesting, but then you would be parsing the reply from match(), even if you didn't want to drill down into a deep nest. If i want to run match() on a level deeper than the top, it's just as easy to spec the level i want searched thru, easier than allowing for endless levels of nesting in a match() return. <snip> > All i was asking for is that match to return a zero when > the first sequence is null "" (exactly) with no regard > for the second sequence. Without this, we can never > use the following line in our code: > > while match(s1,s2) do > > for fear that s1 might become the null sequence at some point, > as in: > > while match(s1,s2) do > --reduce length of s1 and do other stuff > end while I agree, extra tests must be written each time i use match(), because sure as heck it will crash at the worst time, in unforeseen conditions, with parameters that any human would figure out instantly. Kat
7. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 27, 2003
- 411 views
Hello again Kat, >Kat wrote: >match("b",{{"a","b","c"}}) -- 0 >There you simply have it nested too deeply. And you know that. > Yes i know that and you know that, but the language doesnt. It doesnt matter how deeply you nest something, the language has to have a way of conveying the result to the program that makes sense for ALL possible cases, not just some... i=match("b","abc"}}) -- ret 2 i=match("b",{"a","b","c"}) --ret 2 i=match("b",{{"a","b","c"}}) --ret 2 i=match("b",{{{"a","b","c"}}}) --ret 2 Is this what you would like to see?? or are you saying you only want to see this: i=match("b","abc"}}) -- ret 2 i=match("b",{"a","b","c"}) --ret 2 i=match("b",{{"a","b","c"}}) --ret 0 i=match("b",{{{"a","b","c"}}}) --ret 0 ?? You really have to stick your result into some code to find out what really happens next, once you think you have determined a better return result. Set i equal to whatever you think it should be for several cases and see what happens. Take care, Al
8. RE: match() (not short, he he)
- Posted by gertie at visionsix.com May 27, 2003
- 402 views
On 27 May 2003, at 11:16, Al Getz wrote: > > > Hello again Kat, > > > >Kat wrote: > >match("b",{{"a","b","c"}}) -- 0 > >There you simply have it nested too deeply. And you know that. > > > > Yes i know that and you know that, but the language doesnt. It doesn't??? When i run it, it returns zero! And it should return zero! If your's doesn't, you better contact Rob, your interpreter has a bug somewhere! > It doesnt matter how deeply you nest something, the > language has to have a way of conveying the result to the > program that makes sense for ALL possible cases, not just > some... That doesn't mean it should give errors! > i=match("b","abc"}}) -- ret 2 I say no. The b in "abc" looks like an atom to me, and you told match to look for a "b", which is a sequence. > i=match("b",{"a","b","c"}) --ret 2 Yes. > i=match("b",{{"a","b","c"}}) --ret 2 > i=match("b",{{{"a","b","c"}}}) --ret 2 No, and no. > You really have to stick your result into some code > to find out what really happens next, once you > think you have determined a better return result. Doesn't matter what i code, Rob isn't going to put it into the official Euphoria, is he? Kat
9. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 27, 2003
- 396 views
gertie at visionsix.com wrote: > > > On 27 May 2003, at 11:16, Al Getz wrote: > > > > > Hello again Kat, > > > > > > >Kat wrote: > > >match("b",{{"a","b","c"}}) -- 0 > > >There you simply have it nested too deeply. And you know that. > > > > > > > Yes i know that and you know that, but the language doesnt. > > It doesn't??? When i run it, it returns zero! And it should return zero! > If your's > doesn't, you better contact Rob, your interpreter has a bug somewhere! What was meant there was that the language doesnt know what level you want it to look though. It cant look at arbitrary levels unless it returns the level also, and since there can be multiple levels, there would have to be multiple return values. You cant have both. Either match("b",{"a","b","c"}) returns a 2 or match("b","abc"}) returns a 2, but not both. Right now, the second case returns 2 and that has to stay like that, but match("",...) can be changed to return a zero without breaking code. I dont know why i have to keep saying this? Take care, Al
10. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 27, 2003
- 410 views
Derek Parnell wrote: > > > Well that seems to be true with nearly all previous suggestions. > However, > one of my bosses used to say "Trends are not Destiny". > > I guess what we are really saying is > 1) that it would be nice if Euphoria would return a value, say 0, for > zero-length LHS parameters in match() rather than crashing. > 2) If the LHS parameter of match() is an atom, treat it as if it was a > single item sequence. > > Neither of these would break existing code. > > ---------------- > cheers, > Derek Parnell > > Yes, i have been saying that all along I'd even be happy to see #1 alone. If something makes the language better without breaking existing code, why not use it? Take care for now, Al
11. RE: match() (not short, he he)
- Posted by gertie at visionsix.com May 27, 2003
- 404 views
On 27 May 2003, at 12:44, Al Getz wrote: <snip> > match("",...) > > can be changed to return a zero without breaking code. > I dont know why i have to keep saying this? I don't know why you feel you must keep saying that line, i agree with that one, 100%. I always have. Kat
12. RE: match() (not short, he he)
- Posted by Christian.CUVIER at agriculture.gouv.fr May 27, 2003
- 418 views
> On 27 May 2003, at 11:16, Al Getz wrote: > > >> Hello again Kat, >> >> >> >Kat wrote: >> >match("b",{{"a","b","c"}}) -- 0 >> >There you simply have it nested too deeply. And you know that. >> > > >> Yes i know that and you know that, but the language doesnt. > > > It doesn't??? When i run it, it returns zero! And it should return zero! If > your's > doesn't, you better contact Rob, your interpreter has a bug somewhere! > > >> It doesnt matter how deeply you nest something, the >> language has to have a way of conveying the result to the >> program that makes sense for ALL possible cases, not just >> some... > > > That doesn't mean it should give errors! > > >> i=match("b","abc"}}) -- ret 2 > > > I say no. The b in "abc" looks like an atom to me, and you told match to look > for a "b", which is a sequence. > > >> i=match("b",{"a","b","c"}) --ret 2 > > > Yes. > > >> i=match("b",{{"a","b","c"}}) --ret 2 >> i=match("b",{{{"a","b","c"}}}) --ret 2 > > > No, and no. > I agree with all 4 statements: only #2 shoud return 2, all others 0. And it means that, contrary to what I said before, match() must behave differently if first argument is an atom or a sequence. But logically it shouldn't throw an error when first arg is an atom. Thus i=match('b',"abc") --ret 2 which means that match() falls back on find() in this case. CChris
13. RE: match() (not short, he he)
- Posted by Al Getz <Xaxo at aol.com> May 28, 2003
- 404 views
Hello again, I see now why there is so much confusion here. We are attempting to understand something basic, yet confusing the issue by the using something that belongs to another issue in general that, in itself, is also a little hard to understand. Once we remove this secondary issue from all the examples, the underlying concepts shine through bright and clear. The secondary issue i was talking about is that of using quotes around characters like "b", "abc" etc. This in itself clouds the issue, and so if we remove the use of quotes for all of the remaining discussions, the concepts will show through much better. Once we have determined for sure how things work without using ANY quotes, then we can come back and again look at cases with quotes, but im sure it will be much simpler then. Ok, so leaving the quotes out we have to use the ascii codes to represent the characters, such as 97,98,99, etc., but we dont even have to use characters for now really. With this in mind, let's repeat a couple of the examples: [1] match(2, {1,2,3}) --ret 0 [2] match({2}, {1,2,3}) --ret 2 [3] match({2}, {{1,2,3}}) --ret 0 Note that the level of the first arg determines where the second arg is searched, but unfortunately, it only works at level 1 unless you are looking for an exact match, which will be the subject for my next post about the problems with match. Take care, Al