[OpenSCAD] Digging into search( )

runsun runsun at gmail.com
Mon Apr 20 10:08:26 EDT 2015

Wow, Andrew, that was quick !! 

Without going over the links in details, here is my quick view:

It looks great. The removal of iteration over match_value and the
num_returns_per_match is very significant. 

One note:

match_value doesn't have to exclude lists. You just treat it as a value and
don't iterate over it. This way, it can be used to search points like you

In fact, since it is "a value", there's no need to enforce any type
constraint on match_value. It could be anything even boolean or even undef.
Thus, there is no need for the warning sign. It wouldn't be too hard to
check why a search doesn't return indices as expected. 

Certainly, if match_value=vector is allowed,  we have to think about how to
deal with this: 

   search(  ["abc",1],   [ ["abc",1], [ ["abc",1],2 ], ["ghi",3] ...]   ) 

Will it give [0] ? [1]? [0,1] ?

This can be controlled by index_col_num, for example, 

index_col_num = 0 ==> [1]  (match the column #0 ) 
index_col_num = -1 ==> [0] (means, no selection of column, so match the
whole item, in this case, ["abc",1], and return [0] )

Lastly, a side note:

Since search( ) now seems to allow flat list (which I believe was not
original design for), what it does is returning index:

   search( "def", ["abc",1,"def",2,"ghi",3] )

and a step-short to serve the purpose of hash-like feature, because this
will fail :

   search( "def", ["abc","def","def",2,"ghi",3] )

It returns 1, the index of value of key "abc", but not 2, the index of key 

Unless a new argument, every, is introduced. every=1 (default), every=2:
allows for key search in a list of key-value pairs. Its addition depends on
how you feel how important this "key-value pairs" is and if this search()
wants to play that role. 

BTW: I have a whole set of test cases for search(). Once it is merged into
the nightly, I can try them out. 

clothbot wrote
> - A string 'match_value' searches for full-string matches.
>   - It does *not* iterate over each character in the string and return a
> list of matches per character any more.
> - All matches are returned every time
>   - no more 'num_returns_per_match' parameter.
>   - use user-defined functions like the above search_vector_one() example
> to massage search results to your liking.
> - the no-matches condition returns 'undef' instead of an empty vector '[]'
>   - conditional expressions based on no-search-results will work now.
> - Assigning any vector to 'match_value' throws a WARNING and return
> 'undef'
>   - I started trying to get smart and 'collapse vectors of length=1' for
> backward compatibility but... no. Better to rip this bandaid off clean.
>   - Perhaps a future enhancement could support vector-type match_value for
> things like searching for points... That could be handy for process
> polygon() and polyhedron() point sets.
> Thoughts? Comments?
> Speak now or fix it yourself.?. ;-)
> Andrew.


$  Runsun Pan, PhD 

$ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse  ) 

$ -- hash parameter model: here , here 

$ -- Linux Mint 17.1 Rebecca x64  + OpenSCAD 2015.03.15/2015.04.01.nightly 

View this message in context: http://forum.openscad.org/Digging-into-search-tp12421p12443.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

More information about the Discuss mailing list