[KLUG Members] PHP and regular expression problem

members@kalamazoolinux.org members@kalamazoolinux.org
Thu, 30 May 2002 22:11:22 -0400


This has been an interesting thread; php lends itself to a rather nice 
solution that delegates the semantics to a user-defined function, while
providing a high-level algorithm that scales nicely.

The high-level algorthm is easier to deal with. Here's my first shot at
it (unencumbered by testing or other pesky considerations of "real"
programming :) ) :

function lookup($array,$current_string) {
	$merged_array=$array_merge($array,array($current_string));	
	$sort_array=usort($merged_array,"compare");
	$position=array_search($current_string,$sort_array);
	return $position;
}

Thr meaning (or "format") of the elements is now confined to the 
implementation of the "compare" function. If the meaning is actually
minimal, the function can be minimal as well. In fact, it may be a 
very simple string compare. In any case, you very much want to confine
the data semantics (aka "the format", or "the meaning of each part of 
the data" to the compare function, and a bit o'work to make that as 
fast as possible (just less code) is time well invested.

I suspect that you might not want to get into the business of squeezing
out the '0' bytes at all. If you want to do any preporcessing at all, 
you want to do it outside of the above function, and you'll want to hoist 
it out of any prepetitive processing you do in any case. There are some
real economies of scale to be achieved if you want to do this array-at-a-
time, rather than single key at a time. The reason for this is that you
want to do that sort (and all the calls to your compare function) as few
times as possible, so if you can amortize that over fewer, bigger calls,
you're looking at a real gain. Coding an array-to-array version of the
lookup function is a tricky business, but its bound to be a win, more
so if you are doing this a lot, or on large arrays.

							Regards,
							---> RGB <---