Screenshot of game session

Instead of letting the project just sit and wait until it will be redeemed and completed I’ve decided to release my code. It consists of a simple terminal user-interface and an AI opponent. Compiling is straight forward and doesn’t require any special libraries. You can obtain the code from here: oware-0.1.tar.bz2 [15.1 KB].

tar xvf ./oware-0.1.tar.bz2
cd oware
g++ main.cpp ai/basic_ai_engine.cpp -o oware

Running the program is pretty simple, just type ./oware. You will be prompted to select the level of the AI opponent. The higher the number the slower and better the opponent will play. I suggest starting pretty low, and climbing up untill you find it challenging. The houses (holes) are numbered from 0 to 11 starting with the bottom left hole (yours) and going counter-clockwise.

The game is licensed under the GPLv2 or any latter version, so fill free to hack and improve the game if you have time.

I’ve figured that a simple pie plot would better serve Open Yahtzee’s needs, so unfortunately this code will not be released as part of the program. While the code is not perfect, it’s functional and serves a good example of a custom widget. So I’ve felt pity letting it fall into oblivion in Open Yahtzee’s SVN repository, and I’ve thought it might come handy to someone else (or at least for me) if it will be easily accessible.

The widget is made up of two files: simple_histogram.h and simple_histogram.cpp. The code uses stl::vector to pass the plotting data and depenpends on BOOST_FOREACH (but it can easily be removed).

simple_histogram.h:

/***************************************************************************
 *   Copyright (C) 2009 by Guy Rutenberg   *
 *   http://www.guyrutenberg.com/contact-me   *
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 *   This program is distributed in the hope that it will be useful,       *
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 *   GNU General Public License for more details.                          *
 *                                                                         *
 *   You should have received a copy of the GNU General Public License     *
 *   along with this program; if not, write to the                         *
 *   Free Software Foundation, Inc.,                                       *
 *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.             *
 ***************************************************************************/
 
#include <wx/wx.h>
#include <vector>
 
#ifndef SIMPLE_HISTOGRAM_INC
#define SIMPLE_HISTOGRAM_INC
 
class SimpleHistogram : public wxPanel {
public:
	SimpleHistogram (wxWindow* parent, wxWindowID id,
		 const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize,
		 long style = wxNO_BORDER, const wxString& name = wxPanelNameStr);
	void SetData(std::vector<double> d);
	void OnPaint(wxPaintEvent& event);
	void OnResize(wxSizeEvent& event);
private:
	std::vector<double> data;
	double data_total;
};
 
#endif

simple_histogram.cpp:

/***************************************************************************
 *   Copyright (C) 2009 by Guy Rutenberg   *
 *   http://www.guyrutenberg.com/contact-me   *
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 *   This program is distributed in the hope that it will be useful,       *
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 *   GNU General Public License for more details.                          *
 *                                                                         *
 *   You should have received a copy of the GNU General Public License     *
 *   along with this program; if not, write to the                         *
 *   Free Software Foundation, Inc.,                                       *
 *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.             *
 ***************************************************************************/
 
#include "simple_histogram.h"
#include <boost/foreach.hpp>
#include <memory>
using namespace std;
 
SimpleHistogram::SimpleHistogram(wxWindow* parent, wxWindowID id,
				const wxPoint& pos, const wxSize& size,
				long style, const wxString& name)
				: wxPanel(parent, id, pos, size, style, name)
{
	Connect(this->GetId(), wxEVT_PAINT, wxPaintEventHandler(SimpleHistogram::OnPaint));
	Connect(this->GetId(), wxEVT_SIZE, wxSizeEventHandler(SimpleHistogram::OnResize));
 
}
 
void SimpleHistogram::OnPaint(wxPaintEvent& event)
{
	wxPaintDC pdc(this);
	auto_ptr<wxGraphicsContext> dc(wxGraphicsContext::Create(pdc));
 
	dc->SetBrush(*wxBLUE_BRUSH);
	int width, height;
	GetClientSize(&width, &height);
 
	const double column_width = static_cast<double>(width) / data.size();
 
	int i = 0;
	double item_x, item_y, item_ratio, item_height;
	BOOST_FOREACH(double d, data) {
		item_x = i * column_width;
		item_ratio = data_total ? d/data_total : 0;
		item_height = item_ratio * height;
		item_y = height-item_height;
		dc->DrawRectangle(item_x, item_y, column_width, item_height);
		i++;
	}
}
 
void SimpleHistogram::OnResize(wxSizeEvent& event)
{
	Refresh();
	event.Skip();
}
 
void SimpleHistogram::SetData(vector<double> d)
{
	data.assign(d.begin(), d.end());
	data_total = 0;
	BOOST_FOREACH(double tmp, data) {
		data_total += tmp;
	}
}

UPDATE 2009-08-17: Removed commented out function – DoGetBestSize().

template <class T> inline std::string stringify(T x)
{
	std::ostringstream o;
	o << x;
	return o.str();
}

I first wrote it to convert ints to string, but later I templatized it so it would work with other types as well. It’s a clean elegant snippet that I thought other might find useful too.

One of C’s preprocessor operators is the # which surrounds the token that follows it in the replacement text with double quotes (“). So, at first the solution sounds pretty simple, just define

#define STR(tok) #tok

and things will work. However, there is one caveat: it will not work if passed another macro. For example,

#define BUF_LEN 100
#define STR(tok) #tok
 
STR(BUF_LEN)

will produce after going through the preprocessor

"BUF_LEN"

instead of "100", which is undesired. This behavior is due to the C standard noting that no macro expansions should happen to token preceded by #.

However, after reconsidering the source of the problem, I’ve found the following workaround: define another macro which will expand the argument and only then call the macro which does the quoting.

#define STR_EXPAND(tok) #tok
#define STR(tok) STR_EXPAND(tok)
 
#define BUF_LEN 100
 
STR(BUF_LEN)

will produce

"100"

as desired.

Explanation: The STR macro calls the STR_EXPAND macro with its argument. Unlike in the first example, this time the parameter is checked for macro expansions and evaluated by the preprocessor before being passed to STR_EXPAND which quotes it, thus giving the desired behavior.

The main new thing in the version in that it allows the users to specify via the command line how many words should be considered when generating the next one. The bigger the step number the closer the generated text is to the original one. The value used in mctext-0.1 was 2, and this is also the default in this one. The number of steps can be set using the --steps command line switch.

In this version also couple of bugs were fixed (mostly segmentation faults). Another change the regular user will not notice, as it happened under the hood. I’ve redesign the program, and gave better software architecture that hopefully will allow one to extend its abilities and generalize its output generation.

I planned to add more features in this release but due to lack of time, I’ve decided to release as-is. The design rewrite is part of a future plan to allow mctext to operate on music pieces (probably MIDI). This should add a new dimension to the program and allow it to utilize the new generalized structure to generate new music pieces based on sample ones. This future project can have much nicer results that just plain text generation. I really hope I’ll find the time to complete it.

The new package can be downloaded found here – mctext-0.2.tar.bz2. Compilation and installation remained the same as in the previous version. The only dependency is the Boost C++ library.

This is a free software, so please fill free to modify or hack it any way you like. It would be great if you can send a comment when you do so. Also, if you got an interesting idea how this program can be used or modified, please comment.

The first step is to install ctags (if you haven’t got it already installed), this provides the tags file, on which the autocompletion is based. ctags is available directly from the package manager of all popular distro’s.

The next step is to install the OmniCppComplete plugin for vim. The plugin uses the ctags‘ generated tags file for the autocompletion. In order for the autocompletion to properly work with classes, you need to create the ~/.ctags file and add some default options. Each option should be listed in a newline. Your ~/.ctags file should look like this:

--c++-kinds=+p
--fields=+iaS
--extra=+q

These options will now be used as default when running ctags.

The next step is to create a tag file for the wxWidgets library. This can be done using the following command:

 ctags -f ~/.vim/wxwidgetstags -R /usr/include/wx-2.8

Don’t forget to replace /usr/include/wx-2.8 with the path to the header files of wxWidgets. This will create the tags file under your ~/.vim directory.

The next step is to tell vim to use this tags file. This is done by adding the following line to your ~/.vimrc:

:set tags+=~/.vim/wxwidgetstags

And now your done. OmniComplete will now work for wxWidgets, listing members and functions for any of the wxWidgets classes.
Remember you can repeat the last two steps for any other libraries you use in order for the OmniComplete to work with them too.

N.B. don’t forget to run ctags -R . in your projects root dir if you want OmniComplete to work for classes you defined.

int count = 100;
while (count-->0) {
        //some work
}

As I said I don’t think I’ll find any performance benefit for using this code snippet. On the other hand it is always fun to see the puzzled face other programmers have the first time they see the code.

If you go use for loop, but you don’t really care about the order in which the loop is executed, to be more precise, if you can afford reversing to loop, you can save quite some time. By reversing the loop I mean instead of giving the index values from 0 to 10 for example, you go from 10 downward to zero. This doesn’t seem like a big change, but when being carefully implemented this can easily upgrade the performance of your for loops.

Take a look at the following for loop implementation:

for (int i=0; i<10; i++) {
	//some work
}

This loop goes from 0 to 10 and does some work. If the kind of work done allows one to go from 9 to 0, a for loop with the same functionality can be implemented like this:

for (int i=9; i--;) {
	//some work
}

Notice the difference between the two implementations. The first one, needs to compare the index to the stopping value, and then increases the index for the next iteration. On the other hand, the second implementation just checks that the index isn’t zero and increases it in the same statement.

To check if the theory behind this optimization is right, I’ve put a short piece of code to check it.

// fortest.cpp
#include <iostream>
#include <time.h>
using namespace std;
 
timespec diff(timespec start, timespec end);
 
int main()
{
	timespec time1, time2;
	unsigned int i, temp = 1;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
	for (i = 0; i <= 2420000000; i++)
		temp+=temp;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
	cout<<diff(time1,time2).tv_sec<<":"<<diff(time1,time2).tv_nsec<<endl;
	temp = 1;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
	for (i = 2420000000; i--; )
		temp+=temp;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
	cout<<diff(time1,time2).tv_sec<<":"<<diff(time1,time2).tv_nsec<<endl;
	return 0;
}
 
timespec diff(timespec start, timespec end)
{
	timespec temp;
	if ((end.tv_nsec-start.tv_nsec)<0) {
		temp.tv_sec = end.tv_sec-start.tv_sec-1;
		temp.tv_nsec = 1000000000+end.tv_nsec-start.tv_nsec;
	} else {
		temp.tv_sec = end.tv_sec-start.tv_sec;
		temp.tv_nsec = end.tv_nsec-start.tv_nsec;
	}
	return temp;
}

To compile it use g++ -lrt fortest.cpp -o fortest (don’t turn on, yet, any kind of compiler optimization). The program prints two line, one for every kind of for loop. Each line states the time it took for the for loop to complete in a seconds:nanoseconds format.

A typical run of the program on my machine resulted in:

10:338986608
9:728866372

The difference is about 0.5 seconds, which isn’t very small. On the other hand, it’s pretty small if taking into account that we did very little work in every iteration. But nonetheless it a speed gain you can easily achieve by just reversing the for loop code.

By the way, if you do use optimization, the speed gain is smaller, but compared to the runtime of the loop it can improve runtime by up to 70% (all my test showed an improvement of at least 50%).

For example one the same code compiled with the “-O2″ optimization flag, I got the following output:

0:873
0:255

Which is a big improvement when considering the the total runtime of the traditional loop.

• Iterating using the native indexes.
• Iterating using the string::at method.
• Iterating using indexes over the C string representation of the string.
• Iterating using pointers over the C string representation of the string.
• Iterating using the STL iterators.

The basic operation that tests the performance of each kind of iteration hasn’t been changed, and as in the last benchmark I used a test string of 50,000,000 characters. Instead I’ve altered the timing mechanism. In the first test, each one of the iteration methods had it’s one executable and the performance was timed as the execution time timed by the time command for each executable, this methods has a problematic overhead in the form of the time it takes to load to memory each one of the 50MB binaries. In this test I’ve fixed this problem and now the tests timed using clock_gettime. This allowed me to preform all tests from within the same executable and without the overhead of the actual loading time. As a bonus the timer in clock_gettime has much higher resolution, so the results should be much more accurate.

To preform the test download the benchmark’s source code – stringbenchmark2.tar.gz. After you download it go to the directory where you saved the archive and execute

tar -zxvf stringbenchmark2.tar.gz
cd stringbenchmark2
make
./benchmark

The last command is the actual benchmark. It will ran each of the tests and print its timing in the format of seconds:nanoseconds. For example a typical output of the benchmark on my system looks like this:

String iteration benchmark
String length: 50000000
iteration using indexes
0:588484755
 
iteration using indexes over C string
0:617691596
 
iteration using string::at()
0:615612772
 
iteration using pointers over C string
0:515342342
 
iteration using iterators
2:166078723

As you can see the results (in the relative speeds between the iteration methods) remained the same as in the last benchmark. Iterating using pointers over the C string representation is the fastest method by a small margin and using iterators is the slowest by far. This time the results are much more accurate and the difference between closely performing methods such as string::at and using index over the C string repesentation is easily noticeable.