Re^7: Adding Special Rules to Sort

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.

I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness

Comment on Re^7: Adding Special Rules to Sort

Replies are listed 'Best First'.
Re^8: Adding Special Rules to Sort by tilly (Archbishop) on Mar 02, 2009 at 05:58 UTC
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]
Re^9: Adding Special Rules to Sort by zentara (Cardinal) on Mar 02, 2009 at 12:44 UTC
I won't be responding again in this thread. What happened? Changed your transitive closure again ? :-) You are not getting any more secrets out of me...... ha ha....I will rule the betting world with my model. :-) I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness	[reply]