[OpenSCAD] Digging into search( )

runsun runsun at gmail.com
Sun Apr 19 18:22:32 EDT 2015


Hi Andrew, thx for your effort to make search() in the first place.

I forgot to mention that:

(1) my tests were done with the new nightly built, after the unnecessary
Wanring is supposed to be suppressed (but, as you can see in my examples
above, there are at least two more warnings) 

(2) Judging from all examples on the doc, I assume that the design of
search() aims at searching matches against a list of lists/vectors:

     [ ["abc",1],["def",2] ...]   #1

but not from a flat list:

     [ "abc",1, "def",2 ...]    #2
  
Therefore, my tests haven't covered #2 situation yet. But as you can see,
it's already complicated enough. 

I understand that it's not fair to judge its features based on the current
spirit of OpenSCAD, since the OpenSCAD has been upgraded a lot. It's good to
know that a change in the implementation is under considerations. 


clothbot wrote
> 1. search( substring, string):
> 	- return list of substring match indices
> 
> Example 1:
> 
> 	string1=”abcdabcabcdd”;
> 	search(“abc”,string1);
> 		[0,4,7]
> 	search(“efg”,string1);
> 		undef

What's the answer to : search( "ae", string1 ) ? will it be [0, undef] ? or
just [0] ?

If it's just [0] (means, the unmatched will just no-show), then, users won't
be able to tell what are actually matched ( [0] for "a" or for "e" ???)

Note that this, in fact, is doing list comprehension's job :

    abc = "abc";
    [ for( i=[0:len(abc)-1] ) search( abc[i], string1) ]

means that it is still redundant. I'd suggest to get rid of this feature
completely. Means, when match_value="abc", just search for "abc", but not
"a", "b", "c". 


clothbot wrote
> 2. search( fullstring, vector_of_strings):
> 	- return list of indices (set of ‘i’ values) where fullstring ==
> vector_of_strings[i]
> 	- do not attempt substring matches since [ for() …] list traversal and
> construction works
> 
> Example 2:
> 
> 	list2=[“caterpillar”,3,”cat”,2,”dog”,2,”cattle”,5,”cod”,42];
> 	search(“cat”, list2);
> 		[2]
> 	search(2,list2);
> 		[3,5]
> 	search(“bird”,list2);
> 		undef

I see that list2 is a flat list. This is new to the original design. Will it
be treated the same way in ALL situations as a list of vectors ?


clothbot wrote
> 3. search( match_value, vector_of_vectors [, index_col_num] ):
> 	- return list of indices (set of ‘i’ values) where match_value ==
> vector[i][index_col_num]
> 	- this simplification should make it even more powerful+useful for
> hash-style table lookup operations
> 
> Example 3:
> 
> 	table3 =[ [“caterpillar”,3],[“cat”,2],[“dog”,2],[“cattle”,5],[“cod”,42]];
> 	search(“cat”, table3);
> 		[1]
> 	search(2,table3,1);
> 		[1,2]
> 	search(“bird",table3);
> 		undef

I believe the 2nd case should have read:  search(2,table3,1,1) 

Also note that this will create confusion with Example 1, since in Example
1, a string is treated as a collection of chars, but here it's treated as a
whole. It'd be extremely hard for users to remember that. 

Still, I'd strongly suggest that not to try to treat a string as iteratible.
Iterating though a string match_value creates lots of problems, it's hard
for users to understand in the firsts place, and it's hard to come up with a
clear answer (See Example 1 above). Thus users might as well roll up their
own. IMHO, that defeats the purpose of making it a built-in.

SIDE NOTE: Judging from the existence of *lookup* and *search* as built-ins,
I strongly believe that a hash-like data structure is needed:

>     >>> h={ abc:1, def:2 }
>     >>> h["abc"] 
>     1
>     >>> g = update(h, {ghi:3} )
>     >>> g
>     { abc:1, def:2, ghi:3 }
>     >>> keys( g )
>     ["abc","def","ghi"]
>     >>> values( g )
>     [1,2,3]
>     >>> kvs( g )
>     [ ["abc",1], ["def",2], ["ghi",3] ]

 



_______________________________________________
OpenSCAD mailing list
Discuss at .openscad
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




-----

$  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-tp12421p12435.html
Sent from the OpenSCAD mailing list archive at Nabble.com.




More information about the Discuss mailing list