Re: Ordering of Blocks based on Input/Output

J>The two solutions *will* give different results in certain situations
J>because of the different strategies they use.

I only need a one feasible ordering so differences at this level
don't matter.

J>My instinct is that going through the nodes
J>one by one would cause less nodes to be visited overall - it may seem
J>more efficient to collect and process them all at the same time, but
J>the collection process involves visiting a lot of nodes that shouldn't
J>be processed - the more you can cut down on this, the better.

On the two test cases I just ran, it does appear to be faster but I
am going to have to evalutate this over a broader range of cases
with different topologies. The key is faster than N's original non-key
solution. 

>Something that might improve performance is to have a pre-process that
>sorts the blocks according to how many inputs they have. 
 
Or would you want to sort the blocks by the number of outputs they have?
I would think you want to process blocks with lots of outputs first so
the algorithm will more quickly find matching inputs on the next pass.

Unfortunately I can't evaluate the pre-processor now. I have dozens sub 
problems that might also benefit from some pre-processing so I am going 
to put this on my list and tackle them all at once. 

Regards,

Dan

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list