399 karma · joined August 15, 2011
I've also had a hard time selecting a winning solution when several correct ones are posted. I'd like to avoid duplication of effort by solution providers when possible, but finding a way to do that is tricky (I plan to at least implement a 'view count' to give would-be solution providers an idea of how many others have seen the problem).
Thanks for the feedback regarding the tip fees. I'm considering reducing them, as I want to encourage tipping as much as possible (especially considering that tips are often awarded to solutions which may be as good as the winning solution, and I want to encourage rewarding those efforts so that good solution providers stay around).
Cheers!
Sorry about the latency, I'll work on that. I'll also address the Terms and Conditions issue (by most likely removing it entirely, since there is a redundant notice on signup). Please let me know if you have any other suggestions or feedback, I really appreciate it.
BTW, the winning solution doesn't appear to have the security flaw you pointed out.
2. That feature is forthcoming 3. Thanks for pointing that out, I'll fix that. 4. It started that way, but then I realized the time limit wouldn't have much impact on when the bounty actually gets answered, because solution providers compete to answer as soon as possible. So in the interest of simplicity I decided to make it a week. I'll consider changing it back. In practice, most tasks have been solved well before the deadline.
By the way, if there's a security hole in the accepted solution to https://bountify.co/B, you should post a better one or even just mention it- I might tip you for it! :)
Yes, I think the money-to-charity policy will dissuade some users from posting higher bounty amounts at first. My goal is to show that certain kinds of tasks can consistently get quality solutions on Bountify. So far I've been pleased with the speed and quality of solutions and the tone that's been set by the first users.
Feel free to share what types of tasks you'd consider posting. Thanks again for the feedback!
www.wasmylinkedinpasswordleaked.com
What worked for me was porting simple programs I'd written (in Java) to the iPhone. Java is actually pretty similar to Objective C, and some of it was literally just cut and paste. I imagine C++ is very similar too. At first the programs weren't even visual- they were essentially just command-line programs. That way I could focus on learning the basics of the language before learning all the high-level libraries.
Once you get "hello world" working it shouldn't be too hard to build simple programs off of that. Porting an existing program might provide useful structure to your learning if that's your style. Good luck!
The department at Middlebury was small, but I doubt that I could have received a better CS education elsewhere. The opportunity to do one-on-one interesting research so early in my college career was invaluable. All three semesters were Go-related, but I didn't focus on the same thing during each.
The first summer was spent scoping the lay of the land. Reading the papers, implementing naive "improvements", and a lot of testing. Our best result was achieved by implementing someone else's we'd read in a paper. It was a humbling experience.
The second semester started with finding ways to visualize the algorithm in action. Since the improvements were so nonintuitive I felt I had to find a better way to understand how it worked and what my changes were doing. Easier said than done.
The third semester was more varied. I did more testing and playing with parameters. I also ported a version to the iPhone (we wanted to be the first and best on there- this was before ios 2 was released). Then my professor and I started a company that was initially related to Go and iPhones but later pivoted substantially several times.
I'm very thankful for the opportunities I had at Middlebury and the chance to work with Tim Huang.
When it's expanding the search tree, every node expansion is arrived at "intelligently". It starts at the root node, and at each branching, asking itself: which following move is the best mixture of good (based on MC games I've played on the leaf nodes of its children) and unknown (ie I haven't explored that branch very much yet). It does that at every node until the leaf, where it expands a node with the MC-simulator (and then propagates the result up the tree). So unlike some other tree-search algorithms, it isn't cobbled by having to expand all paths to a certain depth before exploring a particular sequence deeper. The result literally looks like a tree: some branches are really tall, maybe 18 moves deep, while others are really short. Even though the "heuristic" is MC, I don't like calling it brute force, because it uses the results of those MC games so well.
Our goal was to improve overall gameplay by making the Monte Carlo simulator play slightly more realistically than random. Keep in mind that when the Monte Carlo simulator plays completely random games, it still does pretty good. I believe it's on par with GnuGo, a good pre-UCT go player, on a 9x9 board on a modern quad-core.
Whether a heuristic applied within the MC-simulator generates sample games that better assess the strength of a move is a tricky question to ponder. But it seems reasonable that most non-random tactics, however simple, would accomplish that (such as proximity- or capture-based tactics).
The reason that good real-life tactics do not correlate with improved gameplay when implemented in MC-simulators is because the logic required for even simple tactics can reduce the number of semi-random games the computer can play by several orders of magnitude. Picking a random move is extremely quick (choosing a number with a Mersenne Twister is faster than adding two numbers- compare that to the operations required to determine how many pieces surround a given position). That's partly why very simple heuristics like capture-if-possible are only effective if they're applied on a few (2, in our case) open board positions per move in a MC-simulated game. So its just slightly non-random.
Anyway I hope that made sense. It's a weird problem to think about at first, but it's actually really fun to play around with. I recommend checking out Drake's implementation.
It's a tough problem to get your head around. Sure, the premise makes sense- that the Monte Carlo heuristic plus the UCT tree-exploration algorithm balances promising nodes with uncertain ones to intelligently expand the tree. But tweaking that algorithm usually hurt performance more than helped, and the tweaks that did improve gameplay were non-intuitive.
One semester our goal was to improve the random-playout generator to play slightly more human-like games. It turns out that almost any play enhancements made in the Monte Carlo simulator crippled performance (for instance: instead of playing randomly, search the board for an opportunity to capture the opponent). The best result we had was achieved by applying the capture-if-possible heuristic on only two positions per random move (ex: at the beginning of the MC-simulator's move, pick two positions randomly- if moving in either one captures the opponent, do it). Applying that heuristic on any more than 2 positions per move made the random games play out more slowly than it was worth. Needless to say, a lot of time was spent testing our tweaks (which itself was quite time consuming).
It was frustrating to see our initial seemingly sensible tweaks cripple performance, and it definitely took some time to calibrate ourselves to the problem at hand. But I probably learned more about programming while working on Go than in any other 3-semester span.
Peter Drake's Orego player is a great starting point for exploring the UCT algorithm (Peter Drake wrote a popular Java textbook you may have used in undergrad). I highly encourage people interested in AI to check it out: