Skip to main content

Timeline for Shuffle product of two lists

Current License: CC BY-SA 3.0

23 events
when toggle format what by license comment
Feb 8, 2014 at 11:36 comment added ciao @Mr.Wizard: LOL, I don't have to tell you, it's one of those non-trivial "trivial" questions! Yep, there's a many-fold beauty to your recursive solution - learned much from going over it.
Feb 8, 2014 at 11:34 history edited ciao CC BY-SA 3.0
added 9 characters in body
Feb 8, 2014 at 11:04 comment added Mr.Wizard I love seeing you take this "simple" question so far. I'd vote again if I could. By the way, in the extreme the recursion (f) has an advantage in that each branch can be interrupted and continued as needed, whereas solutions using Permutations will eventually run out of memory.
Feb 8, 2014 at 2:52 history edited ciao CC BY-SA 3.0
Added random ordered shuffle for intractable cases
Feb 7, 2014 at 12:46 comment added ciao @Mr.Wizard: yes, on my toy testing, second is consistently 10-20% faster. Also, in my tests, the non-generalized version of the latest is neck-and-neck with the SWR refactoring of my OP. Finally, I'm a bit puzzled by timings on the generalized version - it is consistently 20% slower than the other with same arguments. As if passing ## instead of referencing the distinct arguments is making a difference. It's a ludicrous hour here, so off to sack, but I'll be poking at this.
Feb 7, 2014 at 12:00 comment added Mr.Wizard I want to make sure I understand one of your statements; can you confirm that in v9 the second line is faster than the first?: Ordering /@ Ordering /@ Permutations[Range@9] // Timing // First versus Ordering[Ordering[#]] & /@ Permutations[Range@9] // Timing // First. In v7 they are equivalent.
Feb 7, 2014 at 11:50 comment added ciao @Mr.Wizard: Thanks much for taking the time to test in your environment!
Feb 7, 2014 at 11:41 comment added Mr.Wizard @rasher Your latest non-generalized code takes 2 seconds in v7 on my symmetric test. Nevertheless I like it very much.
Feb 7, 2014 at 9:09 history edited ciao CC BY-SA 3.0
Added method for >= 2 lists
Feb 7, 2014 at 1:11 comment added ciao @Mr.Wizard: Curious what last edit does in your tests: seems as fast as fastest refactoring of accumulation method in my limited tests, and prettier IMO...
Feb 7, 2014 at 1:10 history edited ciao CC BY-SA 3.0
Updated ordering method
Feb 6, 2014 at 0:20 history edited ciao CC BY-SA 3.0
New method
Feb 4, 2014 at 11:47 comment added ciao @Mr.Wizard: Along the lines of what I am/was tweaking. Have some other ideas, but cigar is at lip-burning stage, time to hit the sack. I'm curious what morning shall bring ;-). What a great question and set of answers!
Feb 4, 2014 at 11:43 comment added Mr.Wizard @SimonWoods On my system it appears that my use of Outer is equivalently fast; can you confirm that for later versions?
Feb 4, 2014 at 11:38 comment added Simon Woods Regarding the last point, that the Map is the slowest part, you can save some time by doing ss[[Flatten@pres]] ~Partition~ Length[ss] instead
Feb 4, 2014 at 10:41 history edited ciao CC BY-SA 3.0
Typo
Feb 4, 2014 at 10:36 comment added ciao @SimonWoods: Appreciate the comment! Yes, as I commented to Mr.W, I was scratching around for a bit on that. I think there's more tweaking ;-)
Feb 4, 2014 at 10:34 history edited ciao CC BY-SA 3.0
Added explanation per request
Feb 4, 2014 at 10:07 comment added Simon Woods This is the approach I wanted to take, but I couldn't see a fast way to compute pres. The Accumulate trick is very clever. Excellent work!
Feb 4, 2014 at 8:59 history edited ciao CC BY-SA 3.0
Added method
Feb 4, 2014 at 8:58 comment added ciao Yes, it was meant as a goof. Adding my real entry now...
Feb 4, 2014 at 7:37 comment added Yves Klett :) ... it does only work with unassigned variables, though.
Feb 4, 2014 at 4:57 history answered ciao CC BY-SA 3.0