DFA problems

When learning about automata, you might stumble upon this classical problem which pops up in books, lecture notes and articles:
"Construct a DFA that accepts the strings containing an even number of 1s and 0s"

The classic solution I've seen associated with the problem is the following:

I'll call this the A_2,2 automaton and I'll explain later why.

We can easily check that this is the minimal automaton for this particular language.
However, I've never seen anyone try to tear this automaton apart and explain how one would reach it. Sure, you could find a non-deterministic automaton first that solves the problem, convert it to a deterministic one, and finally minimize it, but building it from scratch is far nicer.

First, let's consider a simpler, but related problem for example:
"Construct the DFA that accepts the strings containing an even number of 1s"

Of course, the solution to this trivial problem is the following:

I'm naming this A₂ and for convenience I'll rewrite it to look like this instead.

Wait, how is this related to the initial problem? Well, if we look closer at A_2,2 we observe that we can build a similar structure to that of A_2,2's out of this simpler automaton.

Just take these two automata

Multiply them and that's it!

It turns out that an automaton that accepts "an even number of Gs" AND "an even number of Bs" is the result of multiplying the automaton that accepts "an even number of Gs" with the automaton that accepts "an even number of Bs"


Let's now generalise this!
"Construct a DFA that accepts the strings containing k*2 Rs and k*3 Gs (for any natural number k)"

Following the recipe, we first need to build the automata that accept the two sublanguages and then multiply them.

I'll call this A_2,3. See, the two indices (2 and 3) indicate the length of the cycles.

Can this scheme be extended to fit a third symbol? Yes, of course! Let's see how A_2,2,2 would look like.

Special thanks to Mr. Sipos together with whom I cracked this late in the evening years ago.

WebGL is good for your health

Here's a totally random link I've happened to find on the internet: https://3d.casinofloor.com/.

What is this you might say?! Am I trying to lure you to some online casino and get incredibly wealthy? Well, that, and take a closer look at the link - it says "3d"! Now click on the link, wait 2 seconds for it to load and feast your eyes on one of the biggest tech-demos showing off WebGL - it's a 300 meter long cathedral-like casino containing a ton of slot machines, animated characters, particles, reflective water, gazillions of bottles and glasses, spooky statues and a never-ending sunset.

As far as I'm aware there are only 2 other neat demos out there showing off huge environments in WebGL. The first is the Epic Citadel demo by the makes of the Unreal engine and the second is Bananabread. These 2 are initially coded in C++ and then transpiled in asm.js flavoured JavaScript. Wait, why are people in this age coding in C++ and then spitting out javascript-machine-code-wannabe apps on the web? Plain JavaScript is fast and mature enough to develop in and drive huge applications as well - as proof,  the Casinofloor demo uses the Goo Engine which is written from scratch in JavaScript.

tl;dr? Short version: goo.js rules and check out the little snippet below:

Meanwhile...

I've been a bit absent/slow on this blog and I'm terribly sorry, but I've grown out of my bedroom now, I'm not a "bedroom programmer" any more, I got a job and I program among other programmers (in an office!). I'm working at Goo Technologies and as a Goonian I have the honour of contributing to GooJS (a really cool JavaScript-WebGL-3D-eyepopping-library) (oh, and yes, we at Goo prefix everything with "goo").

And in the weekends I still manage to push updates on MUPLex.

One of the most important additions to MUPLex is a type-inferencer-checker-thing. The language is still dynamically typed (I love dynamic typing), but because the default/preferred bindings in the language are immutable and because there are no implicit conversions, a static code analyser can have a look at the code, infer the possible types of expressions and throw warnings when it concludes that some bits of code can never execute properly if they're reached.

Another addition is that MUPLex now has a to-javascript transpiler. Yes, I am contributing to the 87563284762 languages that compile to JS nowadays. One of the hardest bits was to find a translation scheme that generates pretty expression-ish looking JS code (even compiled code has to be pretty) and not generate any _var_7a62ff variables. It actually generates no extra variables. MUPLex has some features like implicit currying, lexical scoping and a module/namespace system, but JS is flexible enough that you can emulate these relatively easy.

"In the future, in the year 2000" I'm looking forward to showing what awesomeness you can achieve with GooJS and you can expect more updates on MUPLex, but not that often.

Introducing MUPLex

I've been taking one of Dan Grossman's courses on programming languages and it was one of the most illuminating I've ever taken. While teaching, he used a made up programming language called MUPL. This MUPL had higher order functions, pairs, conditionals and the addition operation - this is the bare minimum with which you can teach how to build interpreters but also enough on which you can further build a high level functional language.

MUPLEx is basically an extensions of MUPL. It adds some syntactic sugar as well as new features. Here's a list:

• Functions with an arbitrary number of arguments
• Currying by default
• Mutability - yes, I know mutability is the source of all evil (most of it, at least) but in some cases it makes sense, like having lazy evaluation or memoization
• Records - to be able to build meaningful data structures
• More math operations
• Letrec - the equivalent of forward declaration in C (this way you can have mutually recursive functions, or other useful constructs)
• Cond - syntactic sugar for nested conditionals
• Lists - syntactic sugar for nested pairs
• A way to print out stuff
• Booleans

It also has some primitive type checking to catch some errors as you type. But, unfortunately, at this stage the errors are not too explicit.

I can't include the interpreter in this post because it's a pretty hefty beast, but I can point you to the github HTML preview thingie or directly to the repository.
*the preview may not work in Chrome/Safary

Spring updates, RU invades the GPU

Spring has come! (for most at least, Sweden is actually a bit behind). So here's some spring news:

Firstly, I've updated the stochastic optimization framework. The plugin system is now fully functional - yes, you can pack your favourite algorithm into a .jar, drop it in the plug-ins folder and see how it performs. The usual bug fixes here and there also come with this update.

Secondly, I've updated and shared Particle48 on github. It's a particle systems library (for JS & the HTML5 canvas) I made a while ago for use at LD events (and I've actually used it in Homo Vermes). I expect to update it before every LD compo and add new types of particles. If I get fellow ludumers to contribute, things will really start rolling.

And last but not least, OCLEx got 2 new additions: 1. a simple demo to the bundle to show how to set things up to start doing some image manipulation on the GPU and 2. RU on the GPU - this basically means that every Executor is a separate "process" running on the GPU and doing its duty. It started as an experiment to see how one would simulate a MIMD architecture in a SIMD environment and then got disguised in a nice RU uniform. Early OpenCL capable video cards have terrible performance penalties if the kernels are not executing the same instruction. This is a big bummer if you have any sorts of branches in the kernels. With this simulation you don't get any performance penalties (everything runs slower, but it's independent of the instructions the kernels are executing). I'll come back with more details after I do some more work and prettify it. In the mean time you can find it here.

The screenshot looks like that not because it's a work in progress but because it uses the GL_UGLY texture filter.

Return of the Four Fours

In an attempt to get faster results for the four fours problem mentioned earlier, I've come up with a simpler algorithm that does even more number crunching but somehow computes the precious list faster. Despite being sillier because it computes the same thing twice (or even worse), it'll use waaay less memory.
Oh, and since the algorithm encodes the solutions as stacks of operations, it'll print them accordingly (in reverse polish notation).

I want to see all three four five six seven ones twos threes fours fives sixes sevens eights nines tens

Four fours

The "Four fours" problem has probably wasted many people's time... As I recently rediscovered the fun in solving this, but I didn't have the patience to figure out how to get more than 2 or 3 values, I started writing a program for it instead. Supposedly, computers are better at number crunching.

It takes about 2 15 seconds to compute five fours on my super-speedy 1.0 GHz AMD not-even-sure-it's-Turing-complete thing. However, trying with seven fours is only for the brave and the patient. The algorithm stores partial results in some huge matrix to reduce computation time, but I have a feeling that this has consequences (especially in JavaScript).

I want to see all three four five six seven ones twos threes fours fives sixes sevens eights nines tens

The long journey from character to AST... begins elsewhere

Since we're in full compiler-compiler season I thought it would be appropriate for me to also provide a more educational example. This example illustrates how a very rudimentary* compiler works. In more detail, it shows what happens to your code after it's been chopped into nice tokens. Then, it shows how, based on these tokens and the language's grammar an AST is built and then decorated and, finally, how this tree is fed to an interpreter and results start popping up.

By rudimentary I mean that the language consists of simple arithmetic expressions. Below, you can find the compiler-demo. Just type stuff and be amazed!

If you want to find out more about the inner workings of this nifty thing, check this very nicely written article on CodeProject.

Your input code:
7 + pi * (x - 10)
The environment:
{ "x" : 5, "pi" : 3 }
Output:

Melc

Every life form wants to live, naturally, but as our lifespan is limited the next best thing we can do is making sure our species survives. This applies to programmers too, as a species. For some time I've been haunted by the thought that I'll never be a real programmer until I write a compiler and the species metaphor I've come up with 5 minutes ago made a lot of sense. Joking aside, now I'm going to present Melc, a compiler-compiler.

Melc is a compiler-compiler or compiler generator that builds a recursive descent parser corresponding to whatever grammar it's been given. The grammar is written in SEBNF, which is a variation on EBNF. The specification including some examples is available on GitHub. I'm going to go on developing this and writing more examples in the year to come.

Petri dish party

Here's a seak peek of what I'm working on

Amandine

Rewriting rules:
21 -> 12 31 -> 13 32 -> 23

Input string:


Output string:



Amandine is a string-rewriting system.

The input given is rewritten accoding to the specified rules. This is how the process goes:
The first rule is applied repeatedly to the string until no more changes are made. Then the second rule is applied, followed by the third and so on. This process is repeated until the string can not be modified with any of the rules anymore. Rules are of the form source -> replacement where source is a JavaScript regular expression and replacement is a normal string. Lines that start with a ; are ignored.

The default example shows how sorting a sequence of numbers is possible.

OpenCL Experiments

While there are many applications (not necessarily scientific ones) for OpenCL and the technology has been available for some years, I have yet to see any piece of software that took advantage of this. There aren't even many tutorials and books on OpenCL. Now, I'm no expert but I thought I could make some OpenCL demos and share them on Github. Here's what I have so far:

• Simulation of repulsive particles - similar to the n-body problem, except here all particles want to stay apart and all particles are attracted to just one. This makes them chase each other which results in some neat patterns and dynamics.
• Hillclimbing! - the hillclimbing algorithm is a very simple stochastic optimization algorithm. The algorithm can be described as follows: a dwarf is placed in the search space (the hills). The dwarf chooses a random direction and goes that way as long as he keeps climbing, after which he chooses another direction and does that until he's on top of the hill. Obviously the hillclimbing algorithm is prone to getting stuck in local maxima, but that's where OpenCL comes in to save us: initialize N parallel hill climbers (dwarves) from random positions in the search space. Thus, we get N local maxima, one of which is the global maxima (hopefully).
• Particle Swarm Optimization (actually Parallel Asynchronous PSO) - I've already covered PSO in this online demo and extensively in my Bachelor's graduation thesis and Gloptat. PAPSO is more suitable for the GPU since synchronizing "threads" is costly. There is also no clear disadvantage in using asynchronous PSO and there are even scientific studies that show how reliable PAPSO is. PAPSO is even closer to what it simulates, to the natural model.
• Shadow demo - it's just a little demo showing a simple way to compute shadows using rays. It also shows how you can have more than one kernel on the same context/queue and that they can use the same allocated global memory without issues.

RU gets reflection, GOAT gets full benchmarking functionality

RU
+ added instruction for sending commands to the other Executor. Executors can now control each other.
+ added instructions for telling the other Executor to place or erase instructions on the "playfield"
+ added a much needed instruction for synchronizing Executors

Now that the language is reflective it's probably even harder to make a compiler for it than for Befunge.
Check it out here: http://madflame991.blogspot.se/p/ru-online-interpreter.html


GOAT
+ separated the application into 2 parts: one for visualising how simulations advance and one for benchmarking which launches simulations in parallel and outputs much more detailed results (output in CSV, XML and JSON formats are in the making)
+ added proper classes for intervals and function domains
* streamlined some sections

Check it out on GitHub: https://github.com/madflame991/gloptat

Homo Vermes for LD #24

Evolution was finally voted for this LD event.
My entry is called Homo Vermes and it's something between Pipe Mania and Entanglement

Check the entry here: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=5035
...and play it here: http://madflame991.blogspot.se/p/homo-vermes.html

LD coming up - particles activate!

In less than 48 hours a new LD begins and this time I've prepared a little library/framework for particle systems.

After seeing an awesome speech by Martin Jonasson and Petri Purho I am now convinced that there can never be too many particles on the screen. They're mesmerizing, fun to program and make your game JUICY.
I've implemented 7 types of particles and 3 types of emitters, but as I use it I'll add more.

Still, screenshots don't do this justice so check the thing in action --> link

Lindenmayer power update

Here's an update for Lindenmayer power! I've rewritten the whole thing and switched from simple context-free grammars to stochastic context-free grammars. The turtle commands have been streamlined and I've also added some new commands. Now you can change the colour of the lines, their thickness and you draw little squares and text.
Link --> http://madflame991.blogspot.ro/p/lindenmayer-power.html

Hello Tarflex, RU gets updated and wiki page on Esolang

First of all, I'd like to introduce you to Tarflex. It's a reflective Turing tarpit. In short the whole program is treated as a list of lists consisting of simple instructions, and some of these instructions can perform operations on the lists.

And second of all, I've added the ability to export RU programs as HTML tables or Wiki tables.
RU has also made it on Esolang - probably the best resource for esoteric programming languages --> link

Here's an HTML table!

>>

>>

>>

++

v

v

<<

<<

<<

++

<

>

>

<<

>>

>>

+

<<

+

v

v

+

>>

-

<<

<<

<

>

>>

-

>>

+

>>

-

v

^

--

>>

v

#

>>

<

RU online interpreter is up and running

It's been almost 2 years since I devised Robot Unlock. Due to the positive feedback and seeing how people shared solutions for levels online I thought Robot Unlock is a fun toy language and deserves more development. That is why I have made an online interpreter for the language. You can program in it and share your marvels with others.

In the future I will add more instruction sets (some more expressive, some more restrictive and some quirky ones too).

Mudboy salutes you!

From Under the Rock

This is my entry for miniLD #36 (Contrast)
Download link for Windows/Linux/OSX + Source: http://gamejolt.com/open-source/games/other/from-under-the-rock/8666/
Explore, listen, see, taste.

Global Optimization to the max!

GOAT, or Global Optimization AT is a framework/sandbox for testing of global optimization algorithms. I've started tinkering with optimization algorithms back in feb 2011 and this whole thing ended up becoming my bachelor's thesis. Now I think the project is mature (ok, it still needs some tidying up) and modular enough so that others can build on it too. That's why I have released it under the GNU GPL on GitHub. https://github.com/madflame991/gloptat

Thus far its main components are:

1. A function plotter to see how objective functions look like and why they're so much of a challenge. It also points out where candidate solutions are at every iteration in the search space
2. Basic benchmarking features - so that one can compare the performance of different algorithms
3. An implementation of Genetic Algorithms and many variations
Here's a list of operators and variations implementd thus far:


• [Standard stuff]
  Tournament and Roulette wheel selection
  Singlepoint, 2-point and uniform crossover
  Uniform mutation
  


• [Not so standard stuff]
  Population reduction
  Random immigrants
  Iversion
  


• [Unique* as far as I know]
  Biased crossover (inheriting the significant part of a chromosome from the better parent)
  Non-uniform mutation with dynamic parameters
  Growth (a hillclimbing step each generation)
  Some methods to adjust selection pressure at runtime ("Damping functions")
  
  *I haven't found any mention of the last 4 variations. As far as I know they're my original contributions, but I'm sure someone else interested in the field has thought of them already and documented these...
  
  
4. An inplementation of the Particle Swarm Optimization algorithm and variations.
   Here are some features implemented for PSO:
   
   
   • Nighbour networks
   • Population reduction
   • Random immigrants

---

...and here's a list of things I'm planning to implement:

1. Split the application in 2 parts: one entitled "demo mode" - this should be used to see how the simulation progresses with fancy 3D graphics and one entitled "benchmark mode" for well... benchmarking. It will probably run simultaneous jobs to minimize the time it takes to benchmark
2. Add more objective functions
3. Add more optimization algorithms