Codility

I was reading a blog concerning how to hire new programmers. According to this blog, one of the classic mistakes some recruiters make is that they don't get the propsective candidate to write any code during the interview. This seems a bit odd, but I guess in some small companies they may not have the competence to select their first programmer. This blog mentioned Codility, a way to test a candidate's programming skills.

I headed over and liked the design and thought I'd take the demo test. I recommend you give it a go and come back after that.

It was a neat and easy to understand interface. I selected C as it's my weapon of choice for everything except for applications that need extensive string handling (in which case the String class makes bothering with Java worthwhile).

They had a fair problem and a suboptimal solution as a framework. After coding my most intuitive solution (for those who tried the demo, getting the righthand side total then:

for(i=0;i<n;i++){
  rsum -= arr[i];
  if (lsum == rsum) return i;
  lsum += arr[i]; }

To avoid arithmetic overflow, the array consists of doubles to be on the safe side. I overlooked this the first time in.

Anyway, in the 30mins I got it except for the overflow, which I went back and checked that it worked. I wish there were a few more tests like this as work doesn't exercise all my c muscles :) Props to Codility hopefully a thing of the future.

Round up of the Google AI Competition

Well the competition got a lot harder once the maps changed, the real top bots certainly rose to the top. Congratulations to the winners!

My reflections on the competition:

• Nicely run and nice that it adapted to the demands of the players
• Great to have the ability to watch the matches afterwards.
• Some very talented AI guys out there - with a fair bit of time on their hands.

My bot:

• Instead of doing a minimax on my move then the opponents move, it should have used the syncronous nature of movement to analyse the 9 (apart from the first move with all 4 directions available to both players) feasiable options.
• I would have ideally trimmed the resultant decision tree in a logical manner, searching deep on both sideways options and that would often beat the opposition, by adventagously cutting the areas.
• My initial implimentation of 'first to the most squares' was buggy, it would have been great to sort it out. so the bot didn't make such obvious bad moves.
• Using a more optimized 'first to most squares' algorithm. I should have made a list of the coordinates to go over in the next run, meaning that only 1-20 squares were checked rather than all squares.

I lacked the time to impliment these options, but that's no excuse, just the way it was. I had great fun and I'll be looking for the next challenge from the University of Waterloo CS Club.

I'll throw my code up here for anyone that wants a slightly buggy (but very fixable) tron bot.

In fact I have a few versions - one in perticular was stable but didn't search very deep.

Plant Monitor

It took me a little while to get a few bugs sorted out. But I now have a working plant monitor.

The receiver sits by the computer. It's an arduino with a loosely wired shield. The RF receiver's data line goes into the Arduino's RX. The rest are either unused or for power.

One change I will make to version 2 (if I ever get round to a version 2) is to make a small packet get sent rather than the ID and then the reading. I would also be interested in sending the temperature. I'm unsure if the temperature effects the conductivity of the soil, but I guess I'll work that out in the coming weeks. Maybe I'd have to adjust the threshold dependant on the temperature.
Both .pde files needs the RFDriver.pde file from Morris's site (mentioned in the last post). It needs to be in the same directory and this only works with Arduino's IDE version 16 onwards.


PlantRcvr.pde
PlantTrans.pde

Note - don't program the tx with rx or vice versa. Rookie mistake.


Now the transmitter is a little simpler.The idea is that one transmitter can do a windowsill full of plants. Luckily the ATmega328 has 6 A/D channels, so we don't have to do anything tricky to monitor 6 plants.

You could pull the AVR out of the arduino (carefully!) and attach the power rails and hook all of the lines up as per the pins on the arduino if you want to save yourself an arduino board. I'll be doing that as soon as I get my hands on a 16MHz crystal. Even after changing the clk fuse I can't seem to get a un-clocked chip to work.

I'm sure there's bugs in the code and it's hardly optimised at all. Let me know if you use it, like it, hate it, or find bugs. If you optimise or add functionality let me know, I'm interested to see what this could become.