Lambdal Tap consists of Mike Amy, Ben Scherrey (proteusguy), Sajal Kayan, Satoko Oh, Chip Huyen, Nick Martin and Kirit Saelensminde. The team homepage is http://www.kirit.com/Lambdal%20Tap There are two parts to the source -- A C++ section and a Python section. They both work together. None of it is especially tidy. There are about 4 version of the OVM. There are Python and C++ versions cross compiled from the .obf files. The Python ones work and the bin1.cpp version has been brought into a C++ VM tool, but was never used. These versions of the VMs where produced by entry/Python/translator.py There is also a hand written C++ interpreter which can load either the translated JSON files or the binary files directly. This is mostly in entry/Cpp/vm/ovm.cpp and entry/Cpp/vm/instructions.cpp ==Solutions/Submissions== Solutions to problem one were done running the Python VM and then switching to the C++ when it was finished,, the Python visualiser and a Python controll program. The winning versions of these are in Python/simulations/rocket/accel-100?-winner.py. We did one that optimised the fuel to leave is with no fuel, but numeric differences between all of our VMs and the submission one meant they didn't work when submitted. The main code we wrote for the competition is in the "entry" folder. The rest are libraries that we made use of. We have not included the Boost source code. ==Building and running== These instructions are by no means exhaustive, and are probably somewhat buggy too. ===Python=== The Python files uses a virtual environment that should set everything up properly. We assume a python 2.6 environment under a recent Ubuntu distro. To install the environment do: # install subversion sudo apt-get subversion # get latest virtualenv & install in /usr/local/bin cd /usr/local/bin && sudo wget http://svn.colorstudy.com/virtualenv/trunk/virtualenv.py && sudo chmod +x virtualenv.py # download & install setuptools globally wget http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg#md5=ca37b1ff16fa2ede6e19383e7b59245a sudo sh setuptools-0.6c9-py2.6.egg # download & install pip globally (goes to /usr/local/bin) # use like '$ pip install -E django-trunk -r django-trunk.txt' to build new virtual env setup sudo easy_install pip sudo apt-get libsdl-dev sudo easy_install pygame Once installed cd to the "entry" directory and. $ source setup The command prompt will change to show that the environment is correct. To run with the C++ vm you need to follow the C++ instructions in the next section to get that compiled then do the following: ../dist/bin/fpython newsim.py [-d] where is 1001..1004 and is simulations.rocket.accel-100?-winner.slow-go optinal -d param determines whether to show visualization of the run via pygame. You local directory will have a corresponing .osf file for each run. Our scoring submissions where therefore generated as follows: ../dist/bin/fpython newsim.py 1001 simulations.rocket.accel-1001-winner.slow_go -d ../dist/bin/fpython newsim.py 1002 simulations.rocket.accel-1002-winner.slow_go -d ../dist/bin/fpython newsim.py 1003 simulations.rocket.accel-1003-winner.slow_go -d ../dist/bin/fpython newsim.py 1004 simulations.rocket.accel-1004-winner.slow_go -d These are pretty close to optimal solutions using Hohmann transfers. Unfortunately we are penalized for optimal fuel usage because of the error in the scoring for this particular scenario. Therefore, we implemented a fuel dumping option by performing thousands of +1/-1 thrusts to use up un-needed fuel prior to the initial primary burn. These solutions work perfectly in both our C++ & Python vms but are counted as crashes when resulting traces are submitted to the contest. I believe this to be the result of a cummulative floating point discreprencey where our vm produces slightly different vector directions than the contest scoring vm that eventually add up enough so the raw trace instructions send the rocket off. It's interesting that our two independently implemented vms both return identical results and score in the 90s. To see the runs under our vm do the following: ../dist/bin/fpython newsim.py 1001 simulations.rocket.accel-1001-fuel-opt.slow_go -d ../dist/bin/fpython newsim.py 1002 simulations.rocket.accel-1002-fuel-opt.slow_go -d ../dist/bin/fpython newsim.py 1003 simulations.rocket.accel-1003-fuel-opt.slow_go -d ../dist/bin/fpython newsim.py 1004 simulations.rocket.accel-1004-fuel-opt.slow_go -d ===C++=== Note, be in the Python virtual environment to build and execute the C++ code, it sets the LD library paths etc. We did not include Boost libraries, these will need to be fetched and built. From the "Boost" directory run build: $ ./build 39 0 That will take some time :) Next from the "entry" directory run the build script there: $ ./build This will build all of the libraries and run some tests. ==Clever stuff== ===Visualisation and tools=== Very early on we had a visualiser and a working VM that we could try to use. The Chimpanzee controller can be given a firing plan and the visualiser shows what happens to it. Later on we also added an .osf player. For the submissions theses were recorded by the C++ VM which wrote the .osf files. ===Genetic algorithms=== We worked on 2 GA engines -- one Python and one C++. The Python uses pyevolve and wasn't really fast enough to get very far. The C++ was fast enough, but wasn't finished early enough to be able to really do anything useful. As of this writing (2 hours before the final deadline) it looks like we may be able to get one solution from it, and be close on a second -- now 30 mins before close, and it seems neither will complete in time, if they actually ever even can. The C++ GA is mostly in entry/Cpp/ga.cpp It uses a fairly basic model and was tweaked for most of the last 48 hours of the competition finally resulting in something that might work.