brute forcing it should be in the realm of possibility. 186 Choose 6 = 53,011,617,022
Unfortunately, it's both less and more complicated than that.
(In the sample dataset), there are only 94 unique values; so 814,216,767 is very doable. It takes about 20 minutes in pure Perl to find the 142,138,770 complient groups of 6.
But then you have to come up with 31 of those sets of 6, where the 186 values, contained match the original 186.
Something like 814216767! / (814216767-31)! * 1 / 31!
Which I get to be something like: 2.07931e242. Somewhat too big to brute force.
Mind you, the OP only wanted one, not all of the solutions, so maybe it is still possible without heuristics. The trouble is, that he suggested that he wanted a different solution each time.
The problem with the heuristics offered so far, is that they are either determanistic and will find the same solution each time. Or non-determanistic and so might run for a very long time before finding one. Or worse. Some of them seemed to, more or less frequently, randomly choose starting positions from which their heuristics never find a solution.
I was working on an idea that encoded the complient 6of94 groups as bitstrings and saved each in 6 of 94 files according to the values contained. You then pick a file & mask at random; and use it to exclude files that contain values already in that mask--so if your first mask has the bit set for the 311 value, which can only appear once, you can immediately exclude all the masks in the 311 file. You then pick another file at random ANDing the masks with the original and rejecting collisions; Once you find a compatible mask, you OR it with the first; reject the files for any maxed out values ones, and repeat till you've selected 31 masks.
But the OP seemed to loose interest--or silently chose to go with one of the existing solutions--and I cracked a tooth.
Whilst waiting at the dentist, I was trying to distract myself by working out what the OPs purpose might be. And the best I could come up with was randomly (re)distributing variable size images or thumbnails onto a fixed width page (840-900 wide), on a grid 6 wide and 31 deep. That thought, the type of website such formatting is frequently done, the effort involved in coding the solution, and the toothache, meant I lost interest also.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
BrowserUk,
Ah, I see. I am not entirely convinced smart brute forcing is entirely out of the question. The maximum number of iterations that you could possibly have to check is 186!. If you were dynamically generating your dials, the number goes way down.
dial 1 - any of the 186 indices (say 311)
dial 2 - any of the 186 indices that isn't dial 1's current (say 296)
dial 3 - any of the 186 indices that isn't dial 1 or 2's current (say
+257)
dial 4 - can't be anything because the sum of 1-3 is 864.
This is extremely messy to do in C though I have done it. Once you get to dial 7 you treat it as though it were dial 1 as far as sum goes. Doing it this way though cuts the possible paths down early and considerably assuming the data isn't designed for worst case.
I have no idea when I will have anything resembling free time again though so this is just an idea.
| [reply]
[d/l] |
| [reply] |