submitting reactants in any sequence

Hi,

Any progress on submitting reactants to Reactor in any sequence, not just the sequence demanded by the reaction definition?  We grab our reactants from MarvinSketch, so we have no control over their sequence, which means we must permute them and submit each permutation in turn to Reactor.  It would be much easier if Reactor did the permutation for us.

-- Bob

Hi Bob,

If you permute reactant sets grabbed from MarvinSketch, then your implementation - posted here - is absolutely fine. Reactant order handling is done at a higher level (in ConcurrentReactorProcessor class, not in Reactor), and we don't want to change that. I suggest you to extend the Reactor class, and hide the reactant permutation handling inside the extended class, so you can use it as you use Reactor now. Let us know if you need more help with this.

We would add permutation handling to a higher level API, as described in this post. We can implement a ReactantSetEnumeration, which permutes the reactants, but it would be usable only with ConcurrentReactorProcessor class,  and using this class makes only sense in batch mode. Please, let us know if you plan to use this feature also in batch mode.

Zsolt

Hi,

Our implementation works, but it is slow, because we have to generate every permutation and submit it in turn to Reactor and see if we get any products out.  It would be much more efficient if the method that did the permuting knew something about which submitted substrates satisfied the reactant definition. 

Consider molecules A, B, C for a three-component reaction.  Reactor first finds which molecule (A, B, or C) satisfies the definition of reactant 1.  It then finds which of the remaining two molecules satisfies the definition of reactant 2.  It then sees if the remaining one satisfies the definition of reactant 3.  Number of tests is between 3 and 6, and we don't need to store any permutations.

When we do it ourselves, we have to generate all 6 permutations, then send each one individually to Reactor to test.  There might be up to 18 tests, and we have to temporarily store every permutation.  

We don't want to hide the generation of permutations inside another class; that won't make it any more efficient.  We simply want Reactor to use its knowledge of the reactant definitions to reduce the number of permutations that need to be examined.

This is a high priority for us.  I can't imagine we're the only ones who don't use Reactor combinatorially. 

-- Bob

bobgr wrote: Our implementation works, but it is slow, because we have to generate every permutation and submit it in turn to Reactor and see if we get any products out.  It would be much more efficient if the method that did the permuting knew something about which submitted substrates satisfied the reactant definition.

We don't want to handle permutations in such low level in Reactor. It would not speed up the processing significantly.

bobgr wrote: Consider molecules A, B, C for a three-component reaction.  Reactor first finds which molecule (A, B, or C) satisfies the definition of reactant 1.  It then finds which of the remaining two molecules satisfies the definition of reactant 2.  It then sees if the remaining one satisfies the definition of reactant 3.  Number of tests is between 3 and 6, and we don't need to store any permutations. When we do it ourselves, we have to generate all 6 permutations, then send each one individually to Reactor to test.  There might be up to 18 tests, and we have to temporarily store every permutation.

Let's suppose the only match is the A,B,C order in this example. Then, with combinatorial match handling you suggested it would mean 6 tests (marked with red): A,B,C;[A],C,(B);B,(A),(C);C,(A),(B).

Currently Reactor skips further match testing if a reactant does not match the reactant in reaction definition. So in this example only 9 tests are performed currently, not 18. The tests: A,B,C;A,C,(B);B,(A),(C);B,(C),(A);C,(A),(B);C,(B),(A). 6 vs.9, it's not a big difference, I think. Storing the 6 permutations should not be a problem at all.

Processing one reactant set, and all its permutations (max 6, in general) should be fast enough for use in GUI-s (it's not batch mode, with thousands of input reactants), let us know if you have other experiences. Please, send also example reactions, so we can examine what causes the slowness.

Zsolt

Zsolt wrote:

Currently Reactor skips further match testing if a reactant does not match the reactant in reaction definition. So in this example only 9 tests are performed currently, not 18. The tests: A,B,C;A,C,(B);B,(A),(C);B,(C),(A);C,(A),(B);C,(B),(A). 6 vs.9, it's not a big difference, I think.

If A, B, and C all match the definition of reactants 1 and 2 but none match the definition of reactant 3, then I think there will be 18 tests.  But granted, this situation is not likely to arise very often.  OK, you've convinced me that generating the permutations is not such a serious drawback after all, except in adding one more loop to an already very loopy method.