[OpenSCAD] Digging into search( )

MichaelAtOz oz.at.michael at gmail.com
Sat Apr 18 23:49:10 EDT 2015


runsun wrote
>     1.2. Strings are treated as vectors-of-characters to iterate over;
> </br>
>     1.3. If match_value is a vector of strings, search will look for exact
> string matches.
> </br>
> Observations:
> </br>
> </br>
> A. Since a match_value is treated as a list of chars, the following 2
> should give same results:
> <pre>
> <code>
>     search( "abc","abcdabcd" )= [0, 1, 2]
>     search( ["a","b","c"],"abcdabcd" ) want: [0, 1, 2] got: [[], [], []]

See 1.3 above. "a" <> "abcdabcd"

> 
> </code>
> </pre>
> B. The following searches give same return. Users have no way to know what
> are matched:
> <pre>
> <code>
>     search( "bc","abcdabcd" )= [1, 2]
>     search( "xbc","abcdabcd" )= [1, 2] 
>     search( "xbzjck","abcdabcd" )= [1, 2]
> </code>
> </pre>

See 1.2 above, b is at pos 1, c is at pos 2. 
wiki: By default, search only looks for one match per element of match_value
to return as a list of indices

> C. Users can't possibly predict the following return:
> <pre>
> <code>
>     data9= [ ["cat", 1], ["b", 2], ["c", 3], ["dog", 4]
>                 , ["a", 5], ["b", 6], ["c", 7], ["d", 8]
>                 , ["e", 9], ["apple", 10], ["a", 11] ] 
>     q= ["b", "zzz", "a", "c", "apple", "dog"]
> 
>     search( "cat",data9 ) want: [2,4] got: [0, 4]
> </code>
> </pre>
>     
>     This also gives out a warning:  WARNING: search term not found: "t"
> </br>
> </br>

1.2 again, c is at 0, a is at 4, t is not found.

> D. This is unpredictable, too:
> <pre>
> <code>
>      a1= [["ab",1],["bc",2],["cd",3]] 
> 
>      search( "ab", a1) want: [ ] got: [0, 1]
> </code>
> </pre>

1.2 again, a is at 0,b is at 1.

Wiki:
If num_returns_per_match = 0, search returns a list of lists of all matching
index values for each element of match_value.

index_col_num (default: 0): When string_or_vector is a vector-of-vectors,
multidimensional table or more complex list-of-lists construct, the
match_value may not be found in the first (index_col_num=0) column.

So as index_col_num=0 & num_returns_per_match=0, it looks for "a" and "b" in
the index_col_num (0) element of the vector a1. Hence [0, 1] is where it
found "a" & "b".

> E. This gives correct answer, but showing two warnings:   
> <pre>
> <code>
>      WARNING: search term not found: "p"
>      WARNING: search term not found: "q"
> 
>      search( "pq",a1 )= [ ]
> </code>
> </pre>

So, that is what it does.??

> F. Inconsistent return when match not found:
> <pre>
> <code>
>     search( "e","abcdabcd" )= [] 
>     search( ["zzz"],data9 )= want: [] got: [[]] 
> </code>
> </pre>
>     Since [[]] is treated as true, the following would be impossible:
> <pre>
> <code>
>     search(...) ? do_found : do_not_found
> </code>
> </pre>

Wiki:
If num_returns_per_match = 0, search returns a list of lists of all matching
index values for each element of match_value.

It returna a list, the outside [ ... ], of lists of all matching values, no
match=[], hence [ [] ].

> So what I think so far are:
> </br>
> 1) It is very difficult to understand how it works. 
> </br>

Yes.

> 2) It is still buggy.
> </br>

No.

> 3) Would make a lot of effort for users to understand it, and a lot of
> effort trying to debug, if possible.  
> </br>

Yes & No (no need to debug)

> My conclusion is that search() is still buggy and it would probably not a
> good idea for it in the release yet. 
> </br>

It has been released for a looong time. I suspect you may be reacting to the
change to remove the Warnings??

> What I believe is that it tries to accommodate too many usages in a single
> function. For example, 
/
> match_value
/
>  could have been designed as just a value (one of number, string or list),
> but not list of values. Since we have list comprehension, it'd be
> extremely easy to achieve this:
> <pre>
> <code>
>    [ for (m in match_values) search( m, ...) ]
> </code>
> </pre>
> This will take away a large chunk of complication inside the coding of
> search().





-----
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Digging-into-search-tp12421p12422.html
Sent from the OpenSCAD mailing list archive at Nabble.com.




More information about the Discuss mailing list