Go back and read the original problem. There is a specification given. Debating whether another specification may be better (eg do points won by matter) is irrelevant, we are given the spec. There are 6 parts to the spec. The original poster claims to know how to do 5 parts of it correctly, and shows enough code to demonstrate that. The problem is that condition 3 is hard. The question is therefore, "How do I handle condition 3?"
Your answer pointed the original poster at different ways to do the bits that could already be done. It offered no help on condition 3. Therefore it did not address the question asked
My answer explained how to calculate that condition. I did not do the rest of the spec because I believe that the original poster can do that. Plus it is boring work.
If you wish to continue defend your answer on the grounds that it demonstrates that you have the "creativity" to answer the question that wasn't asked, and not answer the question that was, well, I don't quite know what to say to that. The situation pretty much speaks for itself.
Anyways we're now going in circles. Unless you have a response that breaks new ground, I won't be responding again in this thread. | [reply] |
Ok, it's tiring to argue. Show me a 'White Paper" showing that "transitive closures" are the most mathematically clean solution to this problem, and I will conceed. But after googling for it, and reading it's wikipedia entry, it makes things even more confusing. :-) My idea is to make a multiplicative string of each team that you have beat. Then store that as a hash key. For the sort, divide that by the other team symbol, and cancel out values in the numerator. (Or something like that :-)...which would yield a value if you beat the other team. Of course, instead of a binary value there, we could move to real numbers, and account for point differential, weather, time of day, etc. You see where I'm going with this? Actually, about 30 years ago, there was an article in Sport's Illustrated about a guy who could predict thorobred horserace winners with a program similar to this. He entered all previous race data for the horses(teams), like weather, track, temperature, jockey weight, head to head wins, time of day, etc. Then he could set up his model with today's conditions, and predict who would win.
He was making a consistent profit by racing....probably with something like 30% accuracy. I too, am tired of arguing with a fellow monk, so this is all I say.
| [reply] |
Joy, you have a response that broke new ground. You made it clear that you still don't understand the problem asked, nor do you understand the solution offered.
Part 3 of the specification said that if you tied on the first two criteria but had played head to head, then the winner should be ranked first except when that win is part of a cycle like the one where where A beats B beats C beats A. The challenge is therefore how to calculate which wins should be counted, and which wins are to be ignored because they are part of a cycle.
My solution was to take the transitive closure of the relation "won over". This is the relation "there is a chain of wins leading from one to the other." Once you have that transitive closure, you can easily find whether a particular win is part of a cycle. If A beat B, but there is a chain of wins from B to A, then A's win over B is part of a cycle and can't be used in that criteria. If A beat B and there is no chain of wins from B to A, then A's win can be used as a sorting criteria.
Now one can debate whether the best way to do this is to compute the whole transitive closure up front. But there is no way of solving the question asked without somehow being able to figure out whether a given win is part of an ambiguous cycle or not. And the process of doing that when A beat B is exactly the same as answering the question of whether (B, A) is in the transitive closure of the relation "won over". So you can't get away from dealing with the transitive closure, whether or not you use that language or whether you compute the whole thing or just part of it on demand.
Please note in particular that simply encoding wins in numbers in some fancy way will not readily let you know which wins are to be used as sorting criteria, and which need to be discarded as being ambiguous.
| [reply] |