For example, I took up Déjà Vu again. The implementation had some problems, or rather one big problem: the C stack.

You see, the Déjà interpreter has two functions step_eval and getnextnode which call each other recursively, while walking the source tree. A simple function in Déjà Vu is often three or four nodes deep, so calling a function in Déjà Vu can easily add eight functions that are called recursively. CPython uses the C stack for that. The C stack is rather limited in size, so the interpreter usually can’t handle more than a node depth of a few hundred nodes, and that includes recursive function calls.

Now, there are other implementations of Python that don’t have that limitation, but I don’t want to require the user to use Stackless or PyPy or something else. It is possible to increase the size of the C stack, but that’s a workaround and only works for applications of less than an arbitrary size. I deemed neither solution acceptable.

So what then?

My reasoning was as follows: the recursion of the interpreter is the problem, so I have to make it not recurse any more. Thus I wrote a function called flatten, which made the tree a list of instructions. (Actually, some parts kept a tree shape, but those were limited and unlikely to cause problems). Then I did nothing with it for several months.

When I got started on it again, I decided the code to flatten the tree could easily be used to generate byte code. I then spent a while thinking of useful opcodes and other low-level decisions. When that was done, I had a pretty good idea how I wanted to do the byte code and the virtual machine. I wrote several functions and adapted flatten, to produce proper byte code.

Although this byte code is a binary format, I wrote it for portability, so the compiler would not be needed by users of Déjà Vu programs.

I started writing a virtual machine in C, in code as clean and portable as possible.

As regular readers* will know, I am a high-level thinking guy, so C isn’t my forte, especially for writing virtual machines. I found a sensible way to implement stacks and values that can have multiple types, and I think I know how I can handle return stacks and closure stacks, but there’s still a long road ahead.

At the current state, it has a garbage collector: reference counting plus the synchronous method of cycle collection described in Concurrent Cycle Collection in Reference Counted Systems.

* Ha! As if!

Wikipedia trivia: if you take any article, click on the first link in the article text not in parentheses or italics, and then repeat, you will eventually end up at “Philosophy”.
— Randall Munroe, title text of xkcd/903.

The method described in the quote at the top of this page is actually away to make a graph out of Wikipedia, I realized. Some sort of reverse tree. Not exactly the right description, since cycles are possible (and do exist on Wikipedia).

I wondered whether it would be possible to write a script that starts from some article on Wikipedia and goes on until it finds Philosophy or ends up in a cycle.

As it turns out, it is. Once you get past the parsing of HTML, it is not that hard, even. For that, I avoided regular expressions, and went straight to html.parser.HTMLParser. Can’t say I used it before, but it was a breeze. 90% of the code in the parser is concerned with keeping track of all the conditions whether it is the right time to follow a link. Surprisingly, handling the “not in parentheses” condition was the simplest. I want to keep the code out of this post and in a Gist, but I can’t resist sharing this snippet beforehand:

	def handle_data(self, data):
		self.open_parens += data.count('(') - data.count(')')

For my walker, I ran into the problem of redirects: this could cause problems — or at least redundancy — for cycles. I solved the problem by making what can be described as a dictionary of sets. I sought help from Stack Overflow, and got a neat new toy out of it, but in the end I just went with what I had already.

Long story short: most articles seem to end up in Philosophy eventually (often in ~20 steps), but some end up in a cycle. It is possible that there is some article in there without a valid link, which means there could be dead ends (I don’t check for that, only for Philosophy and cycles), but I haven’t found one yet.

I thought of building an extensive network of Wikipedia articles, but decided against it because of the high volume of requests I would need to send to Wikipedia for it.

And finally, for those of you craving code, here it is. Requires Python 3.

1. Each position gets a list with all possible values (A, B, C, D, E, F).
2. I choose a random value from each list to select the next attempt.
3. If the score I get for attempt the attempt (for example ABCD) has no red points, I know that:
   • A cannot be in the first list, so I remove it.
   • B cannot be in the second list, so I remove it.
   • C cannot be in the third list, so I remove it.
   • D cannot be in the fourth list, so I remove it.
4. If the score I get for the attempt has no white points either, I know that all the colours in the attempt must be removed from all the lists.
5. If the right solution hasn’t been found yet, go to 2.

That’s it. That’s the whole of the algorithm. I didn’t think it would work. But sometimes, it did. It was more luck than wisdom, but still.

As you might know, our major is Artificial Intelligence, so I wanted to make it smarter, once we dealt with the annoyance of MVC — I can see how that can be useful in certain situations, but we never have practical assignments that do the pattern justice.

Anyway, the Wikipedia page I linked to earlier had an interesting section on algorithms. I wanted to implement one of them, but we soon abandoned the idea. Firstly, the computer playing a near-perfect game each time seemed boring. Secondly and more importantly, Java couldn’t let us do it easily or elegantly.

The problem seemed to be object orientation to me. It simply wasn’t cut out for this. I thought functional implementation would be much better. Java really sucks at this, so I made up my mind to write an implementation of Knuth’s five-guess algorithm in Python, using every functional trick I could think of.

That’s exactly what I did last weekend. The complete program, with CLI, is only 42 lines long (yes, that was intentional). And it works. You can supply a code as a command line argument, or enter it later. The first attempt is always AABB. The second attempt takes a while. Depending on the score at the first attempt, it may take twenty or forty seconds on my machine, but I have seen it take only three.

At first, it didn’t work. It took me some time to find the problem: the search space was too limited. Because of careless reading, I used the wrong function to generate the list of all possibilities. It actually generated a list of permutations of ABCDEF of length four, meaning codes containing duplicates (AABC or DABD, for example) could not be found. Using the right function solved all that.

I made a Gist, enjoy.

PS: I don’t like using a global to keep track of the number of attempts. If you know of an elegant and functional solution, please let me know!

The post proper starts with a generic question: how does one model belief states for NPCs/agents in games?

Why would you want to model belief states? I’m not talking about things like “last know position” here, which is neat but not what I want to discuss.

This is about social simulation games, where it is important for agents to act believably. Letting the agents have subjective models of the world in their “heads” could potentially be a huge benefit.

In the game series The Sims, little attention is paid to agent world view: the Sims have relationships with other Sims, but that’s still rather one-dimensional. There are different elements in the different games in the series, but other world view elements are given rather limited attention. For instance, interests in The Sims 2, which decide what the Sims like to talk about, but they don’t influence game play very much.

In OpenTown, I want to do things rather differently. Relationships consist of multiple elements, for example: how much John trusts Jack is independent from how much John likes Jack. Although they are independent properties, they are related and mutually connected. Also related is how much John trusts Suzie and how much Suzie trusts Jack (or at least: what she tells John about that). So relations are complex, dynamic and influenced by groupthink.
What more: people prefer to talk to people that agree with them. I expect groups to form, hopefully preventing the town to become a homogeneous paste. In The Sims, this is resolved by letting Sims do stupid and rather OOC things like randomly picking fights with strangers, which I really don’t like.

There is a lot to OpenTown belief state which I’m glossing over, one thing I do like to mention is Doubt. Every believe has a Conviction and a Doubt quantity attached. The Conviction is simply how much the person believes a certain claim to be true. -1 is “most certainly false”, 1 is “most certainly true”, 0 is “I have no clue whatsoever either way” and the rest sits somewhere in-between. Doubt is more of a meta-belief: it goes from 0 to 1, it says how much the person suspects their own belief is false.

How does that work in theoretical practice?
Put a firm believer in Red Is Better Than Blue (R>B) in a circle of people who all believe Blue Is Better Than Red (B>R). When they converse, sometimes the subject of Red vs Blue comes up. The Conviction of either party is raised, because that is the typical response of humans. But the Doubt is raised too. The kind hosts can lower their Doubt by talking amongst themselves about B>R, while their guest has no such luxury. After a while, the Doubt of the guest begins to overtake their Conviction, and the latter starts dropping, while the Doubt starts rising even faster (of course, once Doubt reaches 1, it will not rise anymore). Once Conviction crosses the 0, their Doubt starts dropping, and it won’t take long now before the guy who thought R>B at first now completely believes B>R.

This is all very complicated and, if implemented, might provide for very interesting situations.

For another game, I wanted to do something similar, but less complicated, since (believable) social dynamics was not the primary goal of that game.

The working title of that game is Tribe. In it, you lead a tribe, consisting of unique individuals. There is more to it, but I’ll just discuss the belief system I want to use there. That system uses certainty factors. The tally there is how much the receiving person trusts the claimant. This does away with the whole double Conviction/Doubt system and I have no justification for it as I have for the OpenTown system.

This post is getting a bit long, and there is so much more to say on this subject. You can consider this the first part of a series. Probably.

When reading about the history of Haskell, I had an idea: I would return Lith to a former state, without functions, so that it could be used to describe data and nothing more, while guaranteeing any valid source code has an equivalent canonical form (only containing T and [ ]). This could not be guaranteed when using functions, which have no canonical representation. The other part of the idea was that I would copy the Lith project to a new project named Lazy-Lith, which would be a lazily evaluated superset of Lith. Functions (in the form of ( )) are completely gone now: Lith does not have a way to suspend evaluation, while in Lazy-Lith, every list is a lazy list.

This means I have to let go of the idea of a stack, rendering the -th in Lith obsolete, because when all lists are lazily evaluated, there is no way of knowing beforehand when the stack will be used.

I have added alphabetical names and assignment with = in the parser, they’re not yet evaluated.

That’s pretty much all there is to say about Lazy-Lith at the moment.

Yesterday, I decided to implement the rest of the language, which was surprisingly easy. (Of course, Lith is still a simple language, and I have more experience with this sort of thing now.) It’s up on GitHub now.

In today’s post, I discuss the theory and implementation of the latest version of Lith.

First, I added numbers, such that 5 was recognised as [ T T T T T ]. Next up, strings. "Hi" turns into [ [ T T T … T ] [ T T T … T ] ]. After that, I added operations (head, tail, test, length, concat, and later flatten), with a generic Special class, which takes as argument the next element in the source.

Now, the operations were not processed, only parsed. I wrote an evaluator, similar in structure to the parser, which took its input from the output of the parser.

An overview of the operations:
!, head
Takes the first element of a list. Is the identity function for T and [ ].

! [ T ]             # = T
! [ [ T T ] [ T ] ] # = [ T T ]
! 34                # = 1
! [ ]               # = [ ]
! "Hello"           # = 72

$, tail
Returns everything but the first element of a list. Is the identity function for T and [ ].

$ [ T ]             # = [ ]
$ [ [ T T ] [ T ] ] # = [ T ]
$ 34                # = 33
$ [ ]               # = [ ]
$ "Hello"           # = [ 101 108 108 111 ]

?, test
Tests for truth. T is true, [ ] is false and any non-empty list is true.

? [ ]  # = [ ]
? T    # = T
? 3    # = T
? "Hi" # = T

&, length
Returns the length of a list. This means that for any number, including zero, length is the identity function. The length of T is defined as [ ].

& [ ]                     # = [ ]
& T                       # = [ ]
& 3                       # = 3
& "Hi"                    # = 2
& [ T [ T T [ T T T ] ] ] # = 2

:, concat
A bit of a weird operator, as it is infix instead of prefix. Concat is a bit like cons in Lisp: it prepends an element to a list,

T : [ ]   # = [ T ]
[ ] : [ ] # = [ [ ] ]
[ T ] : 4 # = [ [ T ] T T T T ]
T : 4     # = 5
!"H":"i"  # = "Hi"

_, flatten
Flatten can be understood to return the total number of Ts in its argument.

_ T                   # = [ T ] = 1
_ [ 4 T T [ [ 1 ] ] ] # = 7
_ [ ]                 # = [ ] = 0

When that was done, I wanted to simplify the tree I had to text the original parser could understand (so only T and [ ]). So I did.

Although the original parser ignored whitespace¹, several separator characters and #comments, I decided to skip all that, and just pasted all the elements together. That output is what I call the canonical form of a tree: the simplest form, free from any syntactic sugar or operation.

As of now, Lith doesn’t have any flow control (I still haven’t found a way to do functions), so it is actually more of a data description language than a programming language.

¹ There are two places whitespaces matter: between two numbers: 1 1 is entirely different from 11, and inside strings, for obvious reasons. But the original parser didn’t recognise numbers or strings, so all’s good.

I pitted two minimax players against each other. Predictably enough, it resulted in a draw. Always the same, since the algorithm is deterministic:

X X O
O O X
X O X

The total running time was consistently just under 3 seconds.

That got me thinking, surely a heuristic could do things faster? So I drew up some heuristic rules the enhanced computer player would use:

1. If the board is empty, just play the top-left corner.
2. If you can win, play the winning move.
3. If your opponent can win, prevent them from winning.
4. If you can find a nice corner you can use to force a win (a number means it is empty, a period means it doesn’t matter), that is:

   X 2 3
   . . 6
   . . X

   or

   X 2 3
   . 5 .
   X . .

   (possibly rotated), do that move.

5. If the opponent has above opportunity, prevent them from doing so.

I tried the heuristics, and sure enough, they helped. Drasticly. But only when the heuristic went first (total time: just over 0.2 seconds). Otherwise, the timing didn’t change at all. Not even just a little bit. They did nothing.

After a bit of experimenting — not too much, you can probably tell what’s going on here just by reading the previous paragraph, I just wanted to confirm it — I found out what was going on:

None of the heuristics did anything. Except for the one for the empty field. You see, the further you get in the game, the smaller the number of possible future game states gets. Reduction early on is likely to matter more. Especially if you can throw away ⁸/₉ of the search space.

The nature of minimax did the rest: if you can win in one move, it will already be selected immediately by the algorithm. If your opponent can win in one move, the algorithm will find you lose quickly after choosing anything but that one soon enough. And those fancy heuristics for finding ways to trick the opponent into inevitable failure won’t be needed, because the opponent won’t let you get that far (remember, this is minimax vs minimax).

So I removed all but the first heuristic.

I put it up on GitHub as a Gist. If you scroll up, you can see the old implementation of the heuristic (much longer, a lot less elegant, and not a bit faster than the new one).

What have we learned? I’d say the lesson is that, when relying on a minimax as fall-back, you only need to implement heuristics for the opening moves, which will dramatically decrease the search space.

A while ago, I’ve written a post about it. I couldn’t quite get it to work. After much distress and failed attempts to fix things, I let it rest.

Once in a while I revisited it. For example, when I (re)discovered Parrot, it seemed like a good idea to implement it that way. The problem was that you pretty much need to do each part in one of Perl, some variant of Perl, or Parrot assembly. Perl is horribly opaque and I never learned it, which was problematic. I’m a high-level thinker, so assembly works against me. But the worst of all is that writing grammars and parsers and whatnot is just plain hard. No, scratch that: the absolute worst is the combination of those things. Learning a language you’ll probably never like is much harder if your equivalent to a “hello world” is a top-down grammar parser.

So I let that rest as well.

But I kept thinking about Déjà Vu. Not on how to implement it — I’m a high-level thinker, remember? No, I was thinking about concepts, about constructs, about connotations…

All ideas were kept in a file called “idea”. The language grew and matured, even though it had no implementation. I added new kinds of statements, full lexical scoping and new datatypes, and improved the function definition syntax.

This spring break, I decided to try it one more time last Sunday. Following the success of implementing a tree parser for Lith, (by the way, the answer to the question posed in that post, “Will I ever implement more?”, is “No, I will not.”) I decided to start simple: read the file line by line, perform a series of simple text transformations to deal with indentation, strings, comments, words and statements (it had to be in that order — I did spend some time thinking about implementation). After the transformations, produce a tree. I’d see what would happen next if I finished it.

I finished it within a day. I was shocked. Sure, Déjà Vu is not a large language — I kept the amount of syntax and the number of statements purposefully small — but I had so much problems with it before, and now it worked! In a day! It had everything. It had full lexical scoping! It took Lua 8 years to get that, and this implementation of Déjà Vu had it within a day! All I had to do now is find some way to deal with that parsed tree.

Let’s see. I had a tree filled with conveniently semantically typed nodes. Why not just traverse it, instead of struggling to convert it to byte code? (And probably back again at that.) So I started on that. When I went to bed that day, the first bits where in place for interpreting trees and what’s more: it looked like it was going to work.

The following day, Monday (it is past midnight as I’m writing this post), I implemented the interpreter. It was unbelievably easy. After figuring out some minor problems, I was even able to implement the For statement without much trouble, and I had expected that to hold up the project for a while.

It was the second day, and the language worked. It just worked. I had hastily added an interactive interpreter, modeled after Python’s. That worked too. I have written a neat standard library, implemented in Python. My idea file is over 400 lines, and I had implemented everything I proposed in it, save for those that were superseded by other ideas.

It’s all up on GitHub.

Tomorrow, I will write the much-needed documentation.

One more thing: the implementation as a whole defines 40 classes to parse, interpret, and represent Déjà Vu source. 26 of which are subclasses of the Node class alone. I think that’s the highest number of classes I’ve ever used for a single project.

For those unaware, LÖVE is a game framework, aimed at rapid prototyping, extreme cross-platformness and unlimited awesomeness. It brings in a lot of people who never programmed before as well as professionals.

And recently, version 0.7.0 of it was released. It is the second major release since I joined the community, and while it manges to break almost nowhere in the API with the previous version, it has many, many improvements. Sound is much less problematic now, and we have frame buffers and threads at our disposal.

I won’t talk about the many fun and successful games made with it nor shall I spew more propaganda, aimed at bringing new souls to the friendly and fun-loving community.

Instead I will give a technical review of LÖVE 0.7.0.

The changelog containing changes from 0.6.2 to 0.70 lists:

Additions

• Added love.thread.
• Added love.font.
• Added love.graphics.Framebuffer.
• Added Source:play, Source:pause, etc.
• Added Source:isStatic().
• Added get/setPosition, get/setVelocity, and get/setDirection to Source.
• Added get/setGroupIndex to CircleShape and PolygonShape.
• Added Font:getWrap.
• Added identity field to love.conf.
• Added love.quit callback.
• Added love.focus callback.
• Added extra meter parameter to love.physics.newWorld.
• Added love.graphics.setIcon.
• —Snip

Truth be told, I have no idea what I should write here. I can only compare it to PyGame, wich is completely different. For example, PyGame expects you to take control of the main loop yourself, while LÖVE doesn’t (although you can if you want to, since 0.6.0).

Back to propaganda it is.

Aside from all the cool new things in 0.7.0 (you’ve seen some of them in the changelog), the next version will bring loads of candy. Video playback (Theora and/or WebM) is on the list, but it is hard to tell how close it really is, since it needs a back end and the good ones tend to be gigantic Eldritch abominations.

What more is there to say? I’ve mentioned that it makes making games and other programs ridiculously easy, haven’t I?

Thus ends this blog post on a rather uninspired note. How about this: when the time comes for version 1.0.0 to be released, I will cover it, properly. Until that time, this blog will feature mad ravings and whatnot, like it always has done.

You know it will anyway.

• The Power of LÖVE
• Along comes the Stork

And yes, this post is mainly intended to get myself to finish them.