to get it to run faster but so far every attempt has resulted in significantly longer computation times. “len” is the length of “list.” Both “symitems” and “list” are lists of lists of lists where “symitems” are all possible symmetry mappings (which range from S(2)xS(2)xS(2)xS(1) to S(5)xS(5)xS(5)xS(4)) of “list[[1]].” I’ve never understood when or how to use any of Mathematica’s “Share” functions, which might be the source of my problems. When “symitems” and “list” are short, the serial code is acceptably fast, however as they get larger the serial code become extremely slow (there is nothing I can do to speed up “MemberQ”). I’ve tried:
Can you provide a concrete method for generating list and symitems, or at least some more specifics about their dimensions. I can’t test without some data.
The attached file should be enough to allow you to test things out. This example is relatively fast, but still slow enough to get a feel for what the problem is. The goal is to end up with 1 member of each subgroup without a priori knowledge of how many subgroups there are (which rules out the use of Intersection and Complement - the order of items in list needs to be preserved, which neither of those functions do).
It’s taken me awhile to get traction on what your code is trying to do. I haven’t made any progress on performance, but I’d like to verify that I’ve got the semantics right so far.
unless I’m misunderstanding (why just the second to last position, AKA {-2}?). I’m a day into running my code, so I can’t test this right now (my list is 5118 rows long, with each symitems containing 11520 rows).
Best thing to do to see what is happening is to add
Print["vars: ", MatrixForm@vars]
after the local variables have been defined,
Print["symelement: ", MatrixForm@symelement]
after “symelement=…;” , and "Print["Result: “,MatrixForm@Result]” between “Remove[…];” and “Result” in PermRules[vars_].
I might be able to do Result=Flatten[Tuples[symelement, 4],1]. In many situations Tuples has caused me lots of problems when the output is large, so I tend to avoid using it.
That was a helper method I added, you don’t need to test it, except indirectly by testing PowSym. What I’m asking is whether my updated version of PowSym produces equivalent results as your original. Does your PowSymmetryCheck1 function, which depends on PowSym, still work if you make the changes I suggested?
Whether Tuples causes problems or not is irrelevant. I’m not proposing Tuples as a performance improvement yet (although I’m almost certain that it would actually be more performant than your Table approach). I’m just verifying that I’ve correctly reverse-engineered your code.
Eric,
I appreciate your time trying to answer my question, but
…“symitems” are all possible symmetry mappings (which range from
S(2)xS(2)xS(2)xS(1) to S(5)xS(5)xS(5)xS(4)) of “list[[1]].”
is the description of the problem, which was included in my original post. I also said I only need one member of each subgroup. If you do not know what that means, you could have asked for clarification. Elsewhere I create raw data, “list,” that can contain multiple members of subgroups when I only need one from each subgroup. S(n) is the n-permutation group, in this case the permutation group mapping a set of labels within itself. The fact that I have the product of 4 symmetry groups means that I have 4 sets of labels. As for what “list” represents, that is immaterial to the issue I wish help with.
I did not say that I would not test your ideas, just that I was not at a point where I could do it now. When I’m at a breaking point, I will try the Tuples approach since built-in code is always faster than interpreted code.
I asked a specific question regarding parallelization in a line of code because that line of code is the slowest part of the process and, to me, there is no obvious reason why parallelization is resulting in a considerably slower process than the serial process. That means I’ve already gone through the code, identified the bottleneck, and considered alternatives (besides re-ordering lists, both intersection and complement also change their length which is a serious problem when one is running a loop based on how long a list is).
I’ve tried to indulge your process for approaching problems while biting my tongue for your arrogance of second guessing me. This is not the first time I’ve had someone in this community insist on solving every other problem but what I asked for, and it is very annoying.
I have verified that the suggested Tuples approach does not produce the desired result. To produce the same result as my table approach (which is all ORDERED combinations of the parts) one would have to do something along the lines of
I solved the problem, though it took a complex solution. In the end I got a method that was 2 at least twice as fast as the original serial version and >10x the parallel one.