The Fumbling Bumbling ACM ECNA Regional

The test data for the regional was finally published. One test case for problem B violated the input spec. My team (CMU Tartans) solved that case "correctly" (whatever that means for an invalid input) while Waterloo Black and CMU Dragons solved it "incorrectly". Those runs will have to be rejudged and the scoreboard recalculated.

To preface this I will say that I am pissed because there is a good chance that after being a regional winner for 5 days there is a good chance we won't go to world finals. Right now it looks like Waterloo got 1st, CMU Dragons got 2nd, CMU Tartans got 3rd, and Michigan got 4th.

The first big mistake was not checking the test data. I helped create the problem set for the CMU Invitational. For all of the problems I wrote I made my solution check the input format and verify that all of the test cases were valid. It is a simple sanity check to make sure the problem specification matches the test cases.

The second big mistake was not checking the test data right after the contest. The problem decided world finals spots its probably worth checking. If they had asked either of the two top teams that missed the problem with many resubmits they would have been told that there is a decent chance of a bug in the test data. If they had looked at the one test case which everyone was failing they probably would have seen the bug. Instead they just glanced over things and missed it completely. They should also have realized that they screwed up test data the last two years, which means there is a decent probability they did it again.

It is hard to write a completely correct problem set, but it isn't that hard. More importantly the contestants deserve a better contest. We practice countless hours to do well in this one contest, and they can't put in the time to make sure that their problems are correct?

There was another, smaller, error in the problem set. On problem H the number of queries is not limited. Thus there is a valid input file of infinite size. When we first read it we thought that you might need some fancy data structure because their could be a huge number of queries. It turns out that nothing special is needed. The problem is that for every solution judged correct there is a huge input file that makes it time out. That didn't cost us the problem, but it definitely cost us time penalty.

ACM ECNA Regional 2009 Part 2

We found out some more information about the 8 minute error from the regional. All sites but Youngstown started on time. The contest was essentially 5 hour and 8 minutes long, and Youngstown started 8 minutes late. The solution itself is not great. I would have preferred running 5 hours for all sites. Youngstown would have an advantage because they would be able to look at the scoreboard 8 minutes in the future from other sites, but it is a very small advantage.

But what I really don't like about the solution was that the judges were okay with it because no top teams were from Youngstown. I think that one of the key parts of a competition like this is that it doesn't matter where you start from, as long as you show up to the competition you are on even ground. Sure its nice to get preferential treatment but fundamentally it isn't fair. I realize that when there is some sort of mistake there isn't always a fair way to fix it, but I don't think top teams should be given any thing extra just because of paster performance.

At this point we aren't sure whether or not there is a problem with B, because the test data has not been published. At this point I'm willing to give the judges the benefit of the doubt, but I'll post more about it once we figure out exactly what happened on the problem.

ACM ECNA Regional 2009

The final standings are here. As usual the contest report doesn't mention any technical problems. I thought I would mention the ones I heard of here.

When the contest started the McMaster site had not yet handed out problems. So after PC^2 was started it was stopped again, then the contest was started over 8 minutes later. At least at my site we started and were never told to stop, and didn't check PC^2. I believe that the other sites except for McMaster did the same thing. Essentially McMaster was 8 minutes late to a 5:08 long competition. Its not fair, but it shouldn't change the results of the world finals teams.

The time left on PC^2 was wrong for about the last hour of the contest. It showed < 2 minutes left for about the last hour. We were done at that point so we were unaffected. This is a huge problem for teams still working because it makes it much harder to manage time. The other CMU team was printing every few minutes because on the printout was the current time.

The last issue may or may not be an issue. At this point I'm willing to give the benefit of the doubt to the judges. Most of the teams who got B incorrect (Waterloo, CMU Dragons, Purdue) weren't sure why they got it wrong. There are rumblings that the test data was wrong, or that there was floating point error. I haven't throughly checked our 4 wrong answers to that problem, but at this point I believe all 4 of them were incorrect. After the floating point debacle of last year I think the judges probably checked the problem very throughly before finalizing the results.

When the test data is released for B we'll be able to go back and figure out why teams were getting wrong answers. The problem was hard to code, and hard to debug so it is plausible that teams just had subtle bugs in their code.

The final results were CMU Dragons in 4th, Waterloo in 3rd, University of Michigan 2nd, and my team, CMU Tartans in first. My team had plenty of good luck on our side. We weren't affected any of the issues and potentially we got B right despite rounding errors in the test data. Either way we are headed to Harbin China in February.

The TopCoder Easy

The easy division one problem on TopCoder is a weird type of problem, that I'm not sure exactly how to tackle. The problem almost always has a very short (~15 lines of code) solution, but normally you need at least one insight to get to that solution. My problem has always been either finding the insight, or being able to prove its correctness.

For the last two SRMs I have solved the easy using a more complicated approach, but one that doesn't require much insight at all. Take OrderedNim(http://www.topcoder.com/stat?c=problem_solution&rm=302474&rd=13904&pm=10190&cr=22657324) for example. The answer is directly related to whether or not the piles have one stone or more than one, but I couldn't think of the exact solution. Instead I just used DP to solve the problem. Sure it took me longer to code, but it avoided a leap of faith in doing so.

I'm still not sure if it is optimal to spend more time looking for the elegant solution, or to just dive into the longer solution. At this point I am confident enough in my coding that I'm not going to lose much time by coding the longer solution. On the other hand I think I am also running away from the elegant code because I don't have the solution. It is hard to force yourself to think of a better way when you have found a method that works.

I am probably doing something wrong because my times for the easy solutions have not been great. ()They haven't been bad, but for the last two SRMs my mediums have carried a majority of the weight. I'm very happy to be able to get fast times and still be very confident that my code is correct. I got the fastest medium overall in SRM 450 and the fastest Java solution in 451 (~10th overall). ()

The Programming Contest Version of Chicken

In the last few practices we have had a couple of problems that have induced an interesting phenomena. The best example is one problem from world finals last year. It was questionable whether the brute force solution would time out or not. My team decided to wait and just look at the scoreboard in 15 minutes. When we checked the scoreboard a bunch of teams had a wrong answer for the problem and no one had solved it. We had our answer without wasting any of our time solving the problem.

Assuming all parties recognize that the problem may or may not be brute force able it seems optimal to always wait until someone else attempts it. On one side if you are able to brute force it you will have a smaller time penalty, on the other side if it isn't you waste console time. In general I think that console time is more important.

At world finals I think it is much more crucial to not spend times on problems you don't solve then to worry about time penalty. All but a few teams there will solve no more than 6 of the 10 problems. You can waste a ton of time by attempting one of the harder problems and never solving it. This creates an even better argument for not attempting the questionably brute force able problem.

At world finals there will probably always be a couple teams who are too optimistic and try the brute force solution, but at regionals that may not be the case. My region (East Central North America) had only 5-6 top teams last year. In theory this could lead to a phenomenon where a lot of the top teams don't solve a brute force able problem until very late into a contest.

Learning while Coding

There has been a phenomena that has been bugging me for a while, but I just couldn't put my finger on it. A couple days ago my brother (a non programmer) asked about which programming language to use for a little project of his. I asked what the project was, and didn't get more than some vague statements. He said that he wanted to start coding and figure out how to do it on the way. I have been guilty of this many times (including the AI project I am currently having trouble with). I think it is one of the most inefficient ways of going about programming.

For some reason when you code you aren't able to focus on the big picture of the program. I have a very hard time anticipating problems I am going to have 20 lines in the future until I actually get there. There are plenty of TopCoder problems where half way through I realize that my algorithm doesn't work. I have had the same thing happen at my internship over the summer. In a good case I figure out the problem before I am finished coding, occasionally it takes until I start debugging to figure things out.

I think the problem comes from the fact that it is hard to spend the time and understand your algorithm. It's very easy for me to just dive in and start coding. For some reason I am scarred of going through the work to really figure out exactly how things are going to work. I think that being able to plan things out in detail (to the point where what you code doesn't change much between the first draft and the final version) is a crucial skill for both competative programming and for programming in the real world. 

I think you can really see the difference when it comes to debug time. Look at the last problem we solved at the ACM world finals. Alan and I talked it over thoroughly and we really knew exactly what we wanted to do. The code got written in about 15 minutes and the debug time was just a couple of minutes. Contrast that with my performance on the medium problem in the TopCoder open round 4, I recognized it as DP (without grasping the full complexity of it), jumped in and started coding. After an hour I was still debugging a flawed algorithm.

Another example is coding malloc. My friend just jumped in and started coding it. He was well on his way to finishing the code while I was still figuring out how I wanted to setup my #defines. I debugged it for a couple of hours, it took him days to finally get his code correct. Planning is especially important for things like malloc (basically a ton of bit operations, and problems show up way after they occurred). The more complicated the code, the more you need to plan.

When I started TopCoder I always wanted to be really fast. Speed was a huge focus for me as it is for many other competitors. I think that focusing on speed early on doesn't help the learning process at all. The real focus should be on correctness. Plan things out on paper in detail and get things correct (in practice and in the contest). After doing that for a while it is easy to recognize a problem that you can solve quickly without planning and ones you need to spend a half our coding.

ACM World Finals

Our plan going into the world finals was to slow down for the first hour so that we would tackle the correct problems in the problem set. We had not done that well at problem selection on the last couple of practices. The goal was to get 5 problems (the best CMU has ever done is 4), but I thought we were capable of 6 on a very good day.

We started out as we always do, Celestine (the fastest coder) reading A-C, I get D and every other after it (D,F,H,J) and Alan gets E and every other. Celestine recognized that A was pretty trivial very early on. He talked it over with me and we came up with the algorithm which he coded and got correct on the first submission. Already we had started out better than at regionals.

From there we didn't have an immediate next problem. I started working on F, and eventually got a rather crude algorithm for it. I talked it over with Celestine and he started to code it. After a few minutes he noticed a cool property that allowed the code to be significantly simpler (basically taking all the computational geometry except convex hull out of the problem). While he coded that up I talked over B with Alan, and started coding it out on paper.

Celestine got F correct, so I hopped on the terminal to type up B. Alan was working on E on paper while Celestine scavenged for another problem. My first two attempts at B were incorrect, but after some help debugging from Celestine we found the bugs (not implementation problems but a small misunderstanding of the problem). We finally got B done and Celestine went to code up I. I talked over E with Alan and we got an algorithm working that we thought was correct.

Celestine turned in I and got it wrong the first time. We found a small typo resubmitted and got it wrong again. We fixed another few bugs over the next hour or so, but we still didn't have it correct. Alan started typing up E while we finished up I. Celestine was still debugging I, when Alan turned it in and got it back wrong. I looked over it with him, and after a few minutes we were both confident in the implementation. It took a few more minutes before I found the counterexample. We quickly found a fix that would still reuse most of the old code. In the meantime I told Celestine to go from int to double math and to do another stupid fix just in the off chance one of those is our bug. We ended up having integer overflow so that fixed I. Alan quickly fixed E and we were finished with 5 before the scoreboard was frozen.

From there we went looking for more problems. Alan recognized that H is basically the 2-sat algorithm. He coded that while I watched, in the meantime Celestine looked at the other problems trying to find the next easiest one. Alan quickly finished H (whenever we pair program the debug time seems to be nearly instant) and got it right. We were a little worried about some parts of the algorithm, but I think that if I had more of a grasp as to why 2-sat works, not just the algorithm it would be easy to show that ours is correct.

At that point we had 6 problems left with about 35 minutes on the clock. We selected D as the next easiest problem, but despite our best attempts we didn't get too far on it. I think at the end we had some good ideas on how to solve it, but we were probably 30 minutes to an hour away from getting it.

With the contest over we milled about waiting for the results. It was really nerve wracking for us, we were in roughly 16th place when the scoreboard froze without a very good time penalty. We knew we had a shot at a medal, but it didn't seem like a good shot at the time. Eventually the scoreboard went final and our tiebreaker was good enough to put us ahead of most of the teams with 6 problems solved and in 12th place for a bronze medal.

ACM World Finals Days 1 and 2

We arrived in Stockholm on Saturday, and went straight to the Grand Hotel where we stayed. Despite the jet lagged we managed to get out and see the Nobel (prize) museum which was very interesting. The day ended uneventfully with registration and some food in the hotel.

Sunday started very early with a trip to Vaxholm's fortress at 7:45am.We arrived to see a castle on an island which looked very interesting. If you did not know, Stockholm is on an archipelago.

I was fully expecting a tour of the castle, but instead we were shuffled into an auditorium. We got to listen to IBM talk to us about how they are making the world smarter and saving the world. I guess if you pay for everything you get to give the group a presentation. The presentation was down right terrible. The lecture was a high level view of a bunch of projects that IBM are involved with that are helping save the world. The audience is a bunch of incredibly smart, and very technical people. Tell us about the interesting technical details. One of our coaches remarked is that a good measure of how smart you are is how fast you fell asleep at the lecture.

From there we were divided into groups to do a scavenger hunt. My first thought were math and logic puzzles. It ended up being a bunch of team building type exercises. Games where you have to work together to do something. For example the game pictured on the right. Everyone holds a rope to help control where the ball goes. You need to drop the ball into the cylinders and based on which lights turn on you determine the order of the cylinders. Then you drop the ball into the cylinders in that order for bonus points.

Celestine's team ended up winning the scavenger hunt and winning some well deserved viking hats. We returned to the hotel for a few hours before taking a short walking tour of Stockholm on the way to city hall for the opening ceremony. The opening ceremony recognized a number of volunteers who make this event happen. It must take an immense amount of time to coordinate an event of this side. Just helping make the problem set for our local contest took quite a bit of my time.

The rescheduled TopCoder SRM was during the opening ceremony so ACRush and all the other great TopCoders here missed it. That probably made it a much easier contest than a normal SRM.

In general the first few days were interesting, but a lot of waiting around. I'm really ready to go and start the contest. I'm doing being nervous, lets just get on with it.

Pretty Bad Practice

Today we had another practice (with Purdue and Duke), we got 3rd getting only one problem. Purdue and Duke both managed to get two. I think we did poorly versus what we could have done on the problem set.

Alan dove into a simulation problem that he probably should have planned on paper more. That basically took his entire five hours. Celestine and I worked together on H and got it. On D I thought I had it but didn't manage to solve it. We didn't put much work into problems we could have gotten, and a lot into problems we didn't have a chance on.

I think that this is a good time to have this learning experience for us. Going into world finals we can't change which problems we will be able to solve and how long it will take us to solve them, but we can change how we play the game. I think that we will go in with a focus on playing the game correctly.

This also really helps because we know what it is like to get our asses kicked by a problem set. We aren't going to just get frustrated by how many other teams are solving.

I am still worried about what sort of mind set I will be in during the actual contest. I think the key is really in the first 30-45 minutes. We need to get started with the correct problems in the correct direction. The first problem we start on needs to be the easy problem, and we need to knock it down. In soccer it is always important for the goal keeper to get a good touch on the ball early in the game, we need the exact same thing.

The one thing we can't really simulate is the intensity at an actual competition. You really want to go full steam ahead, but we need to slow down and get things right. It isn't about saving 5 minutes of console time here and there. Our one and only goal should be to not make the huge mistakes, like miss reading problems, trying a hard problem, or jumping into a simulation too early.

I'm ready to be in Stockholm and not have to worry about any of my homework for a few days. CMU is great, but the workload coupled with lots of 5+ hours practices is really draining.

Simulation Problems

Recently when we designed the problem set for the CMU Spring Invitational the topic of simulation problems came up. We had 10 problems, and not a single one was a simulation. It took us about 45 seconds to dismiss the concept of a simulation problem. Our team and coaches are all fervently against simulation problems.

The reason is really quite simple, simulation problems aren't interesting problems. They don't require any insight to solve them. All that is required is to accurately translate a set of (usually very complex) rules into code. The solutions tend to not be elegant. The console time needed to solve them is terrible. They are usually very long, and have enough special cases to force more than a couple of resubmissions.

While I think a majority of people will agree that simulation problems are not very interesting, we still have to deal with them. My view has shifted recently, I think that simulation problems are interesting because they are problems from world finals or regionals. We are going to have to compete with this problems, so we need to get better at them. Which of course begs the question, how can you get better at simulation problems?

I have yet to really try and get better at these, but that won't stop me from throwing around a few ideas. I think that solving a bunch of simulation problems will help, but not that much. Simulation problems are rarely similar to other problems, so solving one won't really help you in another one down the road.

Alan came up with, what I think is, a much better way to practice these problems. Assign one problem to your team/coaches every week. Everyone individually solves the problem (while attempting to still write code on paper and minimize console time), then everyone gets together and talks about how the implemented in and what cool tricks they used, and what tripped them up.

For these types of problems we don't need to get together to figure out how to solve them, but we can still get value out of seeing other people's ideas. I think what we will see is that most simulation problems, while lacking an elegant solution, have some solutions which are significantly easier to code and debug than other solutions.

I'm interested to see how much better we can get at simulation problems by putting some time in to practice on them. If anyone has put in a tone of time I would love to hear from them about how much better they are. My best guess is that we won't save too much on the amount of man hours it takes to solve the problem, but that we can cut the console time the problems take down significantly.

ACM ECNA Regional 2008

I never wrote a blog post about how the regionals went down, so here goes. We came in as the B team from CMU. We had only practiced a couple times with the A team and they beat us both times, once by a narrow margin and the other by a big margin. I thought we were getting more practices in, but either way we were the underdogs.

I started the contest off really nervous. I started by reading problem C which was a pretty trivial problem. I was scared about accidentally jumping on too hard of a problem at the start, but after I few minutes I went for the terminal. The problem was pretty simple and I submitted it, only to get it back with a wrong answer. In the mean time Celestine who was assigned problems A and B started working on B, probably not what he should have started working on but it was a doable problem. Alan started on D and also got back wrong answer. 45 minutes in we had two wrong answers already, and no correct submissions.

Alan and I helped each other out debugging code while Celestine started on B. Eventually I fixed my bug and got our first correct answer 50 minutes in, and Alan followed with his problem 6 minutes later. Alan went for E, while I helped Celestine with B and started looking at the last few problems. Alan finished E pretty quickly while Celestine was having problems with B. I worked with Celestine to get B wrapped up and get the significant figures worked out. We turned in B and somewhat surprisingly got it right the first time.

I'm not sure when, but I think about now we decided that we weren't going to get all 8 problems, so we canned A and just went for seven. I wrote up my somewhat hacked together program for F, it worked first time but I really didn't think that it was going to. After we got it right we checked the scoreboard and saw that we were in the lead (which I think is a bug because looking at the submission times we were never actually leading). Celestine identified G has brute force (despite by disbelief) and he went to work on that. In the mean time I worked on H with Alan. We started with a pretty simple solution, but we found some counter examples and had to make it more and more convoluted. Thankfully the bounds on the problem were so small that an extra factor of n in the runtime didn't hurt.

Celestine submitted G and got it wrong. While he was debugging Alan went to type of H, and I helped Celestine debug. We found Celestine's bug which I think was something small like swapping his is and js in some nested for loops. We had fifteen minutes left to finish off H. The scoreboard was locked with an hour to go and the top 3 was us, the other CMU team, and Waterloo, all with 5 problems solved. Our tiebreaker was pretty horrendous with 4 wrong submissions and a really slow start. At that point I thought we had no chance of winning the contest.

Alan debugged his code while I watched him and Celestine worked on some test cases. The clock was slowly ticking down and we couldn't even pass the example test cases. With one minute left on PC^2 (which means less than 2 minutes actually) we finally passed the example test cases and turned in the code. We didn't bother typing up the example test cases until after. We put them in and everything seemed to work. The contest ended and we still hadn't gotten a response back. At this point Alan was shaking uncontrollably. I thought that even with the seventh problem we would be in second or third because of our tiebreaker.

Eventually we got our submission to H back correct. The other CMU team came in and asked us how many we solved (the scoreboard was still frozen) we had seven, they had six. At that point whether we won the regional or not we were going to the world finals. I was still pretty sure we hadn't won overall. When we got to the coaches area the scoreboard was up and CMU had gotten first and second. We were the only team to solve seven.

I have been wondering how lucky we got to win the contest. After the fact Waterloo challenged the fact that their submissions to B were wrong claiming that it was a round error. They used ieee rounding instead of the normal rounding. The problem should be setup so that doesn't matter. The other CMU team said their submission to H would have worked if they had gotten the tiebreaker right for which path to pick. Our submission to H could have easily gone the other way, but it all seemed to work out in our favor.

In the end there was a big chunk of luck that helped us, but I think out team strategy was more of the deciding factor. The decision to not even attempt A was pretty crucial to us. We didn't waste any man power on it, while the CMU team (and maybe the Waterloo team) spend some time trying to figure it out. I think out use of console time was done really well, we didn't do much debugging on the console, lots of team debugging on paper.

On the other side our problem selection was pretty horrendous. We got E (one of the 2 easiest problems) two hours into the contest. We started B as one of our first problems (which only two teams ended up getting). In the end though if you solve seven problems and no one else does it really doesn't matter how you solve those seven problems. This is also an example of how for a team solving most of the problems at a regional problem selection can't hurt you that much. Sure our time penalty got hit pretty bad, but it didn't make us solve fewer problems. If a team who was only going to solve 4 problems went after B as their first problem they will probably only end up solving 2 or 3 problems.

With that win we are off to Stockholm in a week. After a winter of practicing I think it is going to give us a trip to the next world finals. The previous CMU A team hasn't been practicing much at all. For them to compete with us at next year's regionals they are going to need to put in a ton of work. Thinking back if the regionals go the other way and we don't put in the practice over the winter we could have effectively lost this year's regionals, and next year's.

Prepping for World Finals vs. Purdue

The last two Mondays the world finals team scrimmaged against Purdue (who just barely qualified for world finals with a correct submission at the 300 minute mark). The first week was a synthetic set made up of 7 IOI finals problems. The problem set was incredibly hard. Normally when I start a hard problem set there are a few problems where I have some ideas of where to start working, on this set I had nothing. I think the key was getting people assigned to the right problems. Alan gave me a fun DP problem, and I gave him a DP problem on trees (just like an assignment he had just a few days before). That helped us break open the problem set a bit.

We managed to get four problems in five hours, which seems like a decent accomplishment. Purdue got 2 in 5 hours, and a third in the thirty minutes after the contest. I think we should have gotten a fifth, but I'm not complaining about four. I think partially IOI is a different type of set (the bounds are a lot larger on most problems), and partially it is simply a very hard set. I am clueless how some high schoolers knock down three of these problems in five hours.

We practiced by ourselves the next friday on another IOI set. Again getting four problems, but this time out of only four on the problem set.

This Monday it was back to practicing with Purdue, this time on a problem set with 11 problems from various European regionals. All of the problems were the hardest 2 or 3 from their regional. I had about the worst contest I have ever had. I had 5 submissions on problem J. The first was a simple swapping i/j which caused a runtime error, second was a few more implementation bugs, third was a bad assumption about the problem, the fourth was a worse assumption, and the fifth was correct. The other problem I got was a simple max flow, which I managed to mess up once.

Overall we got 6 of 11, as did Purdue, but we did so with a better time penalty. I think on a better day we really should be solving 8 problems on that set. We had a problem done with 10 minutes left that just had a stupid implementation bug in Dijkstra, and a bruteforceable problem we never got to.

These types of days scare me, because one bad day at world finals throws out all the practice you did. Just like running (my other big sport) being in the right mindset seems to be key to this. I think today I was too focused on speed and not enough on correctness, especially on my max flow submission. I have a shot at redemption next Monday when we add Duke into the practice. Individually I think we are a little better than Purdue, as a team I think we are a good bit ahead. I have no clue how good Duke is, but regional results and their lack of a larger number of high ranking TopCoder members suggests they aren't that good.

Tommy Angelo is my new hero

Elements of Poker by Tommy Angelo hit home with me really well. In the book he has an example about an archer training with some monk in Asia. The archer has spend a year and is not any better than he was. Finally one day the monk tells the archer to breathe in a certain way before shooting and finally the archer improves a ton. The archer had to endure the bad before he would be willing to really try something so stupid as breathing.

I think that story follows exactly what I went through reading the book. I have had a lot of problems with tilt and the book made a ton of sense to me. Just before going back to college I mocked my brother about going to a meditation, and didn't get it at all. Now I get controlled breathing. It really is just to get your mind off of everything.

Two other things really stuck with me. The first one is that just like playing better, quitting better is a poker skill that will help with your hourly. If you quit while still playing your A game and someone else waits until they are playing their C game you are going to win off of them. Quitting isn't something that the weak do, its a competition just like poker itself. Whoever quits better will win.

The other element that helped a lot was when you are all in consider what you should do if you lose when you are ahead. At that point you aren't tilted so make the decision that if you get sucked out on whether you will continue or not. That way you make the decision before you get tilted not after.

In the last two days (since reading the book) I am up $78 with an ROI of %30 just playing for about 3 hours. Its a sick hourly for someone playing the $11s. I'm only $90 away from the $22s!

Bursting into the $11s

I finally made it fairly deep into the $11s (bankroll wise). I ended the day up 2-0 at the $6s and 7-4 and the $11s for a nice $39. My bankroll is up to $200 so I would have to lose 4 of the $11s before I would drop back down to the $6s. I'm really hoping that this is the last I'll see of the $6s, with another couple winning sessions I should be easily away from the $6s. I'm also closing in on being +ROI for the $11s (I'm 15-18 at them so far).

Poker Update

Yesterday I tilted off a 4 buyins at the $11s, I got the money in good for the first couple, lost then lost a few more. I didn't play that badly, but definitely not my A game. I did well at the $6s winning 16 out of 23. I took two shots at the $11s, got it all in really early in both one with 65% equity and the other with 80% and lost them both =/. I don't want to get into bad beat stories, but whenever I try a higher limit I seem to run bad at the start. I still think I'm massively +EV on the $11s so eventually I'll make it fully into them.

Don't Vote: Why I didn't and you shouldn't

If you, the reader, happened to vote in this election why did you do so? From a purely logical point of view the probability that one vote swings an election is minuscule. Sixty one percent of Americans voted in this election, but logically only a few should actually vote.

One of my many cynical views is that people have a need to feel that they are significant. The United States is a democracy and your vote counts, even if we all know that in reality doesn't. The other side of this argument is that we need something to blame for our problems. If you voted for the "correct" candidate and the country takes a turn for the worse its not your fault. You voted for the other guy!

What people fail to recognize is that while their vote doesn't count, that doesn't mean that they don't matter. The choices each of us make every day affect our lives more dramatically than a lifetime of voting. Voting does not make America great, voting has simply allowed for the preservation and creation of our rights. This country has been made strong by generations of citizens looking out for their own well being. The act of voting does not guarantee prosperity, only fighting for ones own personal well being can do that, and through that fight everyone gains.

So next election don't vote, spend that time pondering how you can make your own life better, and through that simple act you will accomplish the goal of voting, making everyone's lives better.