|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On July 02 2017 01:58 spinesheath wrote:Show nested quote +On July 02 2017 01:16 Manit0u wrote:On July 01 2017 10:19 travis wrote: a little algorithm puzzle for you guys, it was the "challenge question" on my last homework
I think I figured out a solution but I thought some of you may have fun with it (don't cheat!, there's probably solutions online)
Find the median of a 5 element array with only 6 comparisons between elements. (I don't care what you do that isn't some sort of comparison) In other words, sort a 5 element array using only 6 comparisons (math says you can do it in 7 - Ph.D. thesis (Stanford University) by H.B. Demuth (1956). Technically you don't need to fully sort the array to find the median, though I can't think of a method in 6 comparisions off the top off my head nor can I tell if it's possible.
it is possible
its pretty ugly to code though
|
Off the top of my head, I think you can do:
a <=> b c <=> d d <=> b e <=> a e <=> b e <=> c e <=> d
That's the usual 7. I wonder if you can get it in less... I'll think on it.
|
This is what I wrote (it's just english, not code. I am sure anyone here could code it though)
+ Show Spoiler + separate the array into blocks. block of 2: A[1] and A[2]. block of 3: [A3], A[4], A[5] - 0 comparisons
- insertion/bubble/whatever sort the block of 3. - 3 comparisons
sort the block of 2 - 1 comparison
Take the bigger element of the 2 element block and compare it to the median of the 3 element block. If it is smaller than it, compare it to the first element of the 3 element block. The bigger element of this comparison is the median, and it took a total of 6 comparisons. If it is bigger than the median, take the smaller element from your 2 element block and compare it to the median. the bigger element of this comparison is the median.
- 2 comparisons
total comparisons: 6
On July 02 2017 01:16 Manit0u wrote:Show nested quote +On July 01 2017 10:19 travis wrote: a little algorithm puzzle for you guys, it was the "challenge question" on my last homework
I think I figured out a solution but I thought some of you may have fun with it (don't cheat!, there's probably solutions online)
Find the median of a 5 element array with only 6 comparisons between elements. (I don't care what you do that isn't some sort of comparison) In other words, sort a 5 element array using only 6 comparisons (math says you can do it in 7 - Ph.D. thesis (Stanford University) by H.B. Demuth (1956).
If you want to see it that way, you may be removing possible solutions. Maybe it isn't needed to sort the array to find the median.
|
On July 02 2017 04:58 travis wrote:This is what I wrote (it's just english, not code. I am sure anyone here could code it though) + Show Spoiler + separate the array into blocks. block of 2: A[1] and A[2]. block of 3: [A3], A[4], A[5] - 0 comparisons
- insertion/bubble/whatever sort the block of 3. - 3 comparisons
sort the block of 2 - 1 comparison
Take the bigger element of the 2 element block and compare it to the median of the 3 element block. If it is smaller than it, compare it to the first element of the 3 element block. The bigger element of this comparison is the median, and it took a total of 6 comparisons. If it is bigger than the median, take the smaller element from your 2 element block and compare it to the median. the bigger element of this comparison is the median.
- 2 comparisons
total comparisons: 6
your solution is failing these test cases for me
+ Show Spoiler +9 11 3 4 6 block1 = 9 11 block2 = 3 4 6 sort block2 sort block 1 11 vs 4 9 vs 4 9 is output (not median)
5 4 3 2 1 same for this one
|
On July 02 2017 06:03 dsyxelic wrote:Show nested quote +On July 02 2017 04:58 travis wrote:This is what I wrote (it's just english, not code. I am sure anyone here could code it though) + Show Spoiler + separate the array into blocks. block of 2: A[1] and A[2]. block of 3: [A3], A[4], A[5] - 0 comparisons
- insertion/bubble/whatever sort the block of 3. - 3 comparisons
sort the block of 2 - 1 comparison
Take the bigger element of the 2 element block and compare it to the median of the 3 element block. If it is smaller than it, compare it to the first element of the 3 element block. The bigger element of this comparison is the median, and it took a total of 6 comparisons. If it is bigger than the median, take the smaller element from your 2 element block and compare it to the median. the bigger element of this comparison is the median.
- 2 comparisons
total comparisons: 6
your solution is failing these test cases for me + Show Spoiler +9 11 3 4 6 block1 = 9 11 block2 = 3 4 6 sort block2 sort block 1 11 vs 4 9 vs 4 9 is output (not median)
5 4 3 2 1 same for this one
damn I thought I had it. but clearly wasn't thorough enough in testing it
not sure how I was so confident, lol but i won't give up, back to the drawing board..
|
|
I definitely think the key must be by splitting the array up with 1 or 2 comparison sorts, probably with mergesort, though
edit: well actually I guess the sorting algorithm you use doesn't matter since any reasonable one will be 1 or 3 comparisons for 2 or 3 elements
edit2: I think I am on to a new idea.. I am trying to think about it a different way. if I can quickly get rid of the elements that are not near the median (the extremes), then I am left with comparing 3 elements (or 1 if there is some trick). that must be the key. removing the extremes in 5 comparisons, in a way that allows us to have only 1 comparison left to find the median
|
I decided to solve the problem programmatically. I wasn't really planning to but we were talking about the problem with a friend and one thing led to another. The program solves it optimally for N=3, N=5 and N=7 (google search told me 10 is the optimal number for N=7). Here's the source code and here's the generated decision tree as C code. N=7 was a bit too slow to generate naively (I got too impatient) so it assumes A<B, C<D, E<F (and uses 3 comparisons for those). The result is optimal but not as beautiful because it's not a pure and beautiful nested if statement. The tester program tries all permutations of N numbers and makes sure the generated code works for each case. The numbers are currently assumed to be distinct but there shouldn't be a problem with equal values since we can just add an epsilon to each value after we perform the comparison.
How the algorithm works: + Show Spoiler + Generate all possible decision trees recursively, so that at each step:
1. see if we can already definitely select the median element based on the current list of performed comparisons (count number of known greater and known smaller elements for each element - if some element has N/2 for both then we know the median)
2. if not, pick a pair of elements whose order isn't known yet
3. add that pair to the decision tree, try both possible comparison results for that pair and generate recursively the remaining decision tree for each result if possible
4. fail fast if the decision tree is too deep (and would require more comparisons than the known optimal amount)
5. fail if either of the child nodes can't be solved within the remaining number of comparisons
|
|
28079 Posts
Yea I've been using OSS to pick the moocs I've been taking. It is a really good resource tbh.
|
You guys need to learn how to Google. Stackoverflow solved it for me, although I was mostly on the right track with what I was thinking, I was trying to eliminate the smallest and the largest, while you should just eliminate the smallest twice.
+ Show Spoiler + sort a,b <- a is now smallest of these 2, 1 comparison sort c,d <- c is now smallest of these 2, 2 comparisons if a < c: <- 3 comparisons sort b, e <- b is now smallest of these 2, 4 comparisons if b < c: <- 5 comparisons if e < c: <- 6 comparisons return e else return c else: if d < b: <- 6 comparisons return d else return b else: Same as above, but with (a,b), (d,e)
|
On July 02 2017 17:43 Acrofales wrote:You guys need to learn how to Google. Stackoverflow solved it for me, although I was mostly on the right track with what I was thinking, I was trying to eliminate the smallest and the largest, while you should just eliminate the smallest twice. + Show Spoiler + sort a,b <- a is now smallest of these 2, 1 comparison sort c,d <- c is now smallest of these 2, 2 comparisons if a < c: <- 3 comparisons sort b, e <- b is now smallest of these 2, 4 comparisons if b < c: <- 5 comparisons if e < c: <- 6 comparisons return e else return c else: if d < b: <- 6 comparisons return d else return b else: Same as above, but with (a,b), (d,e)
And what if you have 2 equal numbers?
|
On July 02 2017 17:58 Manit0u wrote:Show nested quote +On July 02 2017 17:43 Acrofales wrote:You guys need to learn how to Google. Stackoverflow solved it for me, although I was mostly on the right track with what I was thinking, I was trying to eliminate the smallest and the largest, while you should just eliminate the smallest twice. + Show Spoiler + sort a,b <- a is now smallest of these 2, 1 comparison sort c,d <- c is now smallest of these 2, 2 comparisons if a < c: <- 3 comparisons sort b, e <- b is now smallest of these 2, 4 comparisons if b < c: <- 5 comparisons if e < c: <- 6 comparisons return e else return c else: if d < b: <- 6 comparisons return d else return b else: Same as above, but with (a,b), (d,e)
And what if you have 2 equal numbers? Then it doesn't matter?
|
On July 02 2017 17:43 Acrofales wrote: You guys need to learn how to Google.
Come on, we were specifically told not to cheat...
On July 02 2017 17:58 Manit0u wrote: And what if you have 2 equal numbers?
As the graph formed by comparisons (a < b means edge from a to b, and !(a<b) means b->a) will never have cycles, we can topologically sort the group of equal numbers and mentally add epsilon values and the comparisons will stay consistent.
An easier way to reason about this is that we can mentally subtract index*epsilon from each number. As we can always compare in the order "(smaller index) < (greater index)" (false for equal values), the results of the comparisons would match our modified numbers.
|
On July 02 2017 19:51 slmw wrote:Come on, we were specifically told not to cheat... As the graph formed by comparisons (a < b means edge from a to b, and !(a<b) means b->a) will never have cycles, we can topologically sort the group of equal numbers and mentally add epsilon values and the comparisons will stay consistent. An easier way to reason about this is that we can mentally subtract index*epsilon from each number. As we can always compare in the order "(smaller index) < (greater index)" (false for equal values), the results of the comparisons would match our modified numbers. More importantly, it literally doesn't matter how you order two numbers if they are equal. Just run through the algorithm.
As for cheating, other people started, they just cheated badly
|
ah shit, i looked at acrofales algorithm
yeah i was on the right track too but i also was trying to eliminate the largest twice
|
ok here is a new problem, a conceptual one
You have students at a school. Students form "cliques" of friends. A clique is a group of students where each student is friends with each other student in the clique. Students can be friends with students outside of a clique, but they can't be in two(or more) cliques at once. Students are assigned a "value" 1-10 based on other research.
My mind immediately saw this as a clique being a "graph" where each vertex has an edge to each other vertex, and each vertex has a value.
So some researchers are doing research on cliques in schools. Their goals are two-fold.
1.) Based on an arbitrary target value T, see if a given school has 2 cliques with a total value of T or higher.
2.) Find the 2 cliques in the school that give the highest total value.
now the actual question I have been assigned has a bit more to it - but how would you guys approach this?
My first problem is I am not really seeing a difference between 1 and 2.
For 2, my mind automatically goes to something like this:
1.)take an arbitrary vertex V 2.)add all it's connected vertex into a set 3.)for each of those vertexes, check if the other vertexes in the set are connected to it (you could probably optimize this step a little) 4.)if so, total up it's value and make a set of the vertexes in the clique 5.)repeat for each vertex V 6.)when you are done repeating, find the 2 highest value cliques
So obviously run time for this would be enormous (but I think that's expected). Is it a reasonable approach, though?
And does anyone see some kind of obvious difference between 1 and 2 in how you should approach it?
|
Finding maximal cliques in a graph is NP-complete. So it's a problem that is studied quite seriously to find better and better heuristics for solving it in reasonable time (as well as studying graph topology to figure out what types of graph make it easier to solve, because even approximate algorithms are hard). Depending on whether your algorithm actually needs to be computable or not, you can thus solve it in a variety of ways. The most obvious is:
1) Brute force search for cliques. Effectively what you're doing in steps 1-5 (I think, not sure I follow) 2) Select 2 most valuable cliques.
E: and obviously for low values of T, the first problem is easier: you find 2 cliques with value T you can stop, whereas for the second problem you're going to have to find the most valuable cliques, which is obviously harder. Of course if T is large, then they boil down to the same thing.
|
Okay that's what I thought. Yeah, my approach is right (though I may not be writing it out correctly, I'll have to check).
Worst case performance, 1 and 2 are the same though right? There is no "easy" way to increase worst case performance for lower values of T?
I don't think there is... maybe if it was only based on 1 clique but I definitely don't think there is since we are looking at the sum of 2 cliques.
|
Question: How can I multiply files in Linux?
What I have: 10 directories with some files in them (each directory has name_0001, name_0002 etc.).
What I need: 1000 directories with some files in them. All in the same parent folder (directory contents being duplicate don't matter for me).
How should I go about it? Just write a python/ruby script? Is there a cleaner/better way?
Edit:
I did it with ruby script. I still wonder if there's a better way though...
|
|
|
|