Learning Prolog: Lab Session #3

I'm back with the third post in this (rather unexpected) series! I think I might be getting the hang of this. It's rather abstract and difficult to visualise though. Perhaps there's a tool out there that lets you visualise your Prolog programs to better understand them (If you know of one, please leave a comment down below!) This week's lab introduced the idea of rules. A rule in Prolog is basically if this then at. For example, if the temperature is low and there are lots of clouds in the sky, the weather can be considered bad.

Here's an example:

weather(bad) :-
    temperature(low),
    cloud(high),
    visibility(low).

weather(good) :-
    temperature(high),
    cloud(low),
    visibility(high).

weather(unsure).

temperature(low).
cloud(high).
visibility(low).

(Pastebin, Raw)

The last 3 lines of the above describe the weather at the moment - feel free to change them. The :- bit is simply the equivalent of the IF syntax in Prolog (rather odd if you ask me). Anyway, using the above we can now ask Prolog what the weather is like so:

?- weather(What).
What = bad .

Note that you nad to press enter in order to tell Prolog that it got the correct answer. This is because it has detected that there are other possible answers that it hasn't evaluated yet. You can press space to tell Prolog that it hasn't found the correct answer, but more on this later.

The above, in english, says something like this:

The weather is bad if the temperature is low, there's lots of cloud cover and visibility is low. The weather is good if the temperature is high, there aren't many clouds about and visibility is high. If the weather is neither of the above, then we are unsure about whether the weather good or bad.

We can also use rules in Prolog to categorise something based on a set of rules. Here's an example that works out what category a test score would fall into.

grade(distinction, Mark) :-
    Mark >= 70.
grade(pass, Mark) :-
    Mark >= 40,
    Mark < 70.
grade(fail, Mark) :-
    Mark < 40.

(Pastebin, Raw)

Using the above, we can ask Prolog questions like this:

What grade would I get if I got a mark of 86?

What grade would a mark of 52 be?

And so on. Here's how you would ask Prolog the above questions:

?- grade(Category, 87).
Category = distinction .

?- grade(Category, 52).
Category = pass .

?- grade(Category, 11).
Category = fail.

verything was all going rather well, until I got to the final excersize. It was based on getting Prolog to tell you whether a car fault was electrical or not. Here's a description of what we were asked to do:

A car fault is electrical if the car won't start or the lights are broken. A car fault is also electrical if the car won't start and the lights won't work, or the battery is flat.

After some thought, I came up with the following:

car_fault(electrical) :- % colon-if represents IF in Prolog.
    wont_start; % Semi-colons represent OR in Prolog.
    lights_broken. % Full stops terminate rules.
car_fault(electrical) :-
    (wont_start, % Commas represent AND in Prolog.
    lights_broken);
    flat_battery.

wont_start.
lights_broken.

Where you define any combination of wont_start., lights_broken. or flat_battery beneath the rules, depending in your situation. However, I got a nasty error when I tried to run it, complaining that I hadn't defined something. After sone looking into it (and some help from my lecturer), we found that you need to explicitly tell Prolog that it's OK if lights_broken., wont_start., or flat_battery. aren't defined, and that it shouldn't throw an error. You can do this like so:

:- dynamic wont_start/0.
:- dynamic flat_battery/0.
:- dynamic lights_broken/0.

(Full version: Pastebin, Raw)

Then you can ask Prolog whether your car has an electrical fault like so:

?- car_fault(What).
What = electrical .

...and Prolog will reply that yes, it is an electrical fault if the above rules are met. Otherwise, it will reply false. To practice, try extending the above to include the following:

A car fault is mechanical if the windows have been smashed.

A car fault is also mechanical if the engine is smoking, or if the engine is making a loud noise.

Just ask in the comments for the answer to the above, or if you need help. Also note that I can't tell who's reading this blog if you don't comment! I don't have any analytics set up at all.

Update 16th Jan 2016: An anonymous commenter (please leave your name next time!) alerted me to a mistake in the test grading example. I've fixed it now, thank you!

Learning Prolog: Lab Session #2

Apparently we are supposed to complete the second and third set of lab instructions before the next lab. This post is about what I've learnt from the second lab session, and my thoughts along the way.

Now that I've played around with Prolog for a bit, I've discovered that it isn't really as bad as I thought it was to start with, although the inbuilt editor is absolutely terrible (and there's no real replacement :/).

Last time I learnt that Prolog is rather like a detective in that you tell it about the world, and it can then answer simple questions based on what it's learnt. It's also capable of working things out that you don't explicitly tell it, for example that cats don't like bones - they like milk instead.

Today's lab session started off with some simple Maths. Prolog, apparently, isn't particularly good at Maths - and I'm inclined to agree. Maths in Prolog is done through the use of the symbol comparison system. For example, you can ask Prolog is 2 is equal to itself:

?- 2 = 2.
true.

Prolog replies that yes, 2 is equal to itself. This is relieving, as something would be very wrong otherwise. You can ask Prolog whether other things are equal to each other:

?- two = two.
true.
?- carrots = carrots.
true.

This is mildly interesting, but not really useful. Let's ask it something a bit harder.

?- 4 = 2 + 2.
false.

Erm right. That's not the answer we were expecting...! The reason for this is that Prolog sees the above in terms of the literal symbols that we gave it. So Prolog sees this instead:

Is four equal to "two plus two"?

The equals operator in Prolog actually means unify (are these things the same?), and Prolog is a bit stupid and takes this more literally than we intended. Thankfully, there's another operator we can use:

?- 4 is 2 + 2.
true.

That's much better. The is operator can be used to check if two things are equal as well, but the difference here is that Prolog will perform any mathematical operations that it comes across on the right hand side. In addition, it can be used to set variables (more on that later). The is operator supports brackets, too, allowing you to do this:

?- 40 is ((2 * 10) / 4) * 8.
true.

Variables

Variables in Prolog always start with a capital letter, and are useful when you want to ask Prolog questions like "What does a cat like?" or "What is purple?". Here's an example knowledge base:

purple(flower).
purple(elephant).
animal(elephant).
animal(cat).

Given the above information, we know we can ask Prolog questions like these:

?- purple(elephant).
true.
?- purple(cat).
false.

Those are nice, but rather obvious. Let's step it up a bit, and ask it what is purple:

?- purple(What).
What = flower .

Note that you have to hit enter after entering the command to confirm that the answer is correct. In the above it has correctly identified that a flower is purple and put this information into the variable What. Let's see if we can retrieve the contents of the variable later on:

?- What.
% ... 1,000,000 ............ 10,000,000 years later
% 
%       >> 42 << (last release gives the question)

What's going on here?! This is certainly a rather odd response. The problem here is that variables in Prolog are scoped to the command that's executing. This seems rather useless for now, but at least we use them to ask Prolog a different sort of question. This also works with multiple predicate parameters:

food(cheese, dairy).
food(milk, dairy).
food(cabbage, vegetable).
food(orange, fruit).

Given the above knowledge, we ask things like:

?- food(What, vegetable).
What = cabbage.
?- food(What, dairy).
What = cheese .

Prolog correctly identifies that a cabbage is a vegetable, and that cheese is a dairy product. Note that it picked cheese over milk, as cheese is the first thing it came across. I have a feeling this might be important later on.

That concludes this post on Prolog. If you found it useful, please comment below! I don't run any sort of analytics on here at the moment, so I can't who's reading (or not). If you found a mistake (which is likely) or just want to say hello, please also leave a comment below.

Dividing by zero doesn't always throw an exception

Yesterday I had my first Advenced Programming lab session. Part of the instructions get you to investigate how small a number has to be in order to throw a division by zero exception. I discovered, however, that if you use a double, it does not, in fact, throw any such error. I did some investigation, and thought I might share what I learnt here.

According to Google, C++ only throws a division by zero error if it is doing integer math. It doesn't seem to care if it is doing floating point math. This is because floating point numbers can hold the value Infinity, and integers can't. This means that none of the following statements will throw an error:

double x = 10.0 / 0.0;
float y = 371 / 0.0;
int z = 89.0 / 0.0;

The last line of the above looks like it should throw an error, but it doesn't. The reason for this is that it calculates 89.0 / 0.0 using floating point maths to be Inf, and then converts that into an integer. Since Inf doesn't convert directly, it picks the next best thing I'd assume. The following, however, will all throw an error:

int x = 10 / 0;
float y = 1000 / 0;
double z = 4560 / 0;

Language Review: Lua

I have recently tried writing a bit of Lua. I ported an implementation of a maze generation algorithm I came up with from Python to try it out:

-------------------------------------
-- Maze generation script
-------------------------------------
-- A test by @Starbeamrainbowlabs

---------------------------------------------
-- Intelligent table printing function
---------------------------------------------
-- From http://coronalabs.com/blog/2014/09/02/tutorial-printing-table-contents/

function print_r ( t )
    local print_r_cache={}
    local function sub_print_r(t,indent)
        if (print_r_cache[tostring(t)]) then
            print(indent.."*"..tostring(t))
        else
            print_r_cache[tostring(t)]=true
            if (type(t)=="table") then
                for pos,val in pairs(t) do
                    if (type(val)=="table") then
                        print(indent.."["..pos.."] => "..tostring(t).." {")
                        sub_print_r(val,indent..string.rep(" ",string.len(pos)+8))
                        print(indent..string.rep(" ",string.len(pos)+6).."}")
                    elseif (type(val)=="string") then
                        print(indent.."["..pos..'] => "'..val..'"')
                    else
                        print(indent.."["..pos.."] => "..tostring(val))
                    end
                end
            else
                print(indent..tostring(t))
            end
        end
    end
    if (type(t)=="table") then
        print(tostring(t).." {")
        sub_print_r(t,"  ")
        print("}")
    else
        sub_print_r(t,"  ")
    end
    print()
end

if arg[1] ~= nil then
        width = tonumber(arg[1])
else
        width = 36
end
if arg[2] ~= nil then
        height = tonumber(arg[2])
else
        height = 16
end

----------------------------------
-- function to print out the world
----------------------------------
function printspace(space, w, h)
        for y = 0, h, 1 do
                local line = ""
                for x = 0, w, 1 do
                        line = line .. space[y][x]
                end
                print(line)
        end
end

-- Initialise the world
start_time = os.clock()
math.randomseed(os.time()) -- seed the random number generator with the system clock
world = {}
for y = 0, height, 1 do
        world[y] = {}
        for x = 0, width, 1 do
                world[y][x] = "#"
        end
end

-- do a random walk to create pathways
nodes = {} -- the nodes left that we haven't investigated
curnode = 1 -- the node we are currently operating on
cx, cy = 1, 1 -- our current position
table.insert(nodes, { x = cx, y = cy })

world[cy][cx] = " "
while #nodes > 0 do
        io.write("Nodes left: " .. curnode .. "\r")
        --print("Nodes left: " .. #nodes)
        --print("Currently at (" .. cx .. ", " .. cy .. ")")

        local directions = "" -- the different directions we can move
        if cy - 2 > 0 and world[cy - 2][cx] == "#" then
                directions = directions .. "u"
        end
        if cy + 2 < height and world[cy + 2][cx] == "#" then
                directions = directions .. "d"
        end
        if cx - 2 > 0 and world[cy][cx - 2] == "#" then
                directions = directions .. "l"
        end
        if cx + 2 < width and world[cy][cx + 2] == "#" then
                directions = directions .. "r"
        end
        --print("radar output: '" .. directions .. "' (length: " .. #directions .. "), curnode: " .. curnode)
        if #directions > 0 then
                -- we still have somewhere that we can go
                --print("This node is not a dead end yet.")
                -- Everything starts at 1 in Lua...... ewwwwwwww
                local curdirnum = math.random(1, #directions)
                local curdir = string.sub(directions, curdirnum, curdirnum)
                if curdir == "u" then
                        world[cy - 1][cx] = " "
                        world[cy - 2][cx] = " "
                        cy = cy - 2
                elseif curdir == "d" then
                        world[cy + 1][cx] = " "
                        world[cy + 2][cx] = " "
                        cy = cy + 2
                elseif curdir == "l" then
                        world[cy][cx - 1] = " "
                        world[cy][cx - 2] = " "
                        cx = cx - 2
                elseif curdir == "r" then
                        world[cy][cx + 1] = " "
                        world[cy][cx + 2] = " "
                        cx = cx + 2
                end

                table.insert(nodes, { x = cx, y = cy })
        else
                --print("The node at " .. curnode .. " is a dead end.")
                table.remove(nodes, curnode)
                if #nodes > 0 then
                        --print("performing teleport.");
                        curnode = math.random(1, #nodes)
                        --print("New node: " .. curnode)
                        -- print("Nodes table: ")
                        -- print_r(nodes)
                        cx = nodes[curnode]["x"]
                        cy = nodes[curnode]["y"]
                else
                        --print("Maze generation complete, no teleportation necessary.")
                end
        end
        --printspace(world, width, height)
end

printspace(world, width, height)
end_time = os.clock()
print("Generation completed in " .. (end_time - start_time) .. "s.")

I originally wrote it in Python 3 (I might post about the game it is part of at some point). After trying Lua for a bit I thought it would be a good idea to write up a language review about it.

Firstly, it is really easy to get started with. I was able to compile Lua from source using my MinGW on my Windows 7 machine. Lua is also really lightweight (500kb in total!).

The problems begin when you start looking at Lua's equivalent of arrays: tables. I found that they feel clunky and outdated as there appears to be a lack of manipulation functions. Those that do exist (table.insert() and table.remove() use a lot more characters to use than the equivalent in other languages, such as Javascript (e.g. table.insert(tablename, "somestring") is 40 characters, compared to Javascript's tablename.push("somestring"), which is only 28 characters - a 30% saving!)

Lua's tables also start indexing from 1, not 0 - I found this to be a source of much confusion when I was experimenting with it.

The other thing I found annoying is that strings in Lua are immutable - which means that you can't change them once you have declared them. This can lead to lots of nasty performance issues in programs that do a lot of string manipulation if you are not very careful since every time you re-set a string variable's contents, you are creating more work for the garbage collector.

All in all, Lua looks like an interesting language to learn for fun - you should definitely check it out, if only to see how odd a language it is. I love how lightweight it is. I also managed to build the Lua interpreter from source too, which is always a plus. I can't see myself using it for any real project any time soon though - it just feels too clunky to work with for my purposes, although this is probably more down to my lack of experience and the other languages that I know than the design of the language itself.

Edit April 2020: Fixed a small bug in the code, so it should be slightly faster now.

Learning Three.js four: Maze Birthday Card

Hooray for the fourth 3 dimensional experiment!

This one is a birthday card for someone I know and is also much more complex than the others I have done so far. I ported a maze generation algorithm that I originally wrote in Python 3 to Javascript (I also have ported it to Lua, keep a look out for a post about Lua soon!) and then set about rendering it in 3D.

The aim is to get to the centre of the maze, where some 3D(!) spinning text is waiting for you. The maze generation algorithm is not designed to have the goal in the centre of the maze, so you will find that there are multiple paths that you can take from the centre that lead to different parts of the maze. I will make a separate post about the maze generation algorithm I have written later.

The collision detection is tile based and rather complicated (for me, anyway). I am surprised that nobody has written a library for this sort of thing.....

You can play with it here: Learning Three.js four

Learning Three.js three: Texturing

This week I have been busy, but I have still had time to create a new Three.js experiment. This week, I looked into simple texturing. The Cube in the middle has a simple soil texture, and I gave the skybox a bunch of clouds from opengameart.org. It took a whole lot of fiddling to get it to display the way it has now - I couldn't figure out the correct rotation for the tiles :D

This experiment also uses orbitcontrols.js from here I think? Click and drag to move around, and scroll up / down to zoom.

I have attempted to optimise it by only rendering a frame when the camera is actually moved or a texture is loaded too.

You can find it here: three

Learning Three.js 2: Catch the Sphere

The second thing that I have made in my endeavours to learn three.js is a simple catch the sphere game. Every time you get close to the orange sphere, it will move it to another random place in the room, add one to your score, and play a sound.

I cheated a little bit on the collision detection... I really ought to look into writing a simple 3D collision detection library that uses boxes and spheres.

The collision detection for the sphere is really done in 2D - I check only on the x and z axes to see if you are within a certain distance of the sphere since your y position doesn't change. For the bounding box, I simply check to make sure that your x and z co-ordinates aren't too big or too small.

You can find it here: two

Learning Three.js: Spinning Cube

TL; DR: I am going to learn Three.js. I made this.

3D programming is much harder than 2D programming. You have to think about renderers and scenes and cameras and that extra dimension when specifying co-ordinates. I have wanted to break into the 3D world with my programming for some time, but every time I tried, I got confused.

Enter Three.js.

Three.js is a Javascript library that abstracts away all the complications of 3D programming that come with WebGl and makes 3D programming much easier. This series (hopefully!) will document the things that I learn about Three.js and programming in 3D.

This post is about my first attempt: A spinning cube. I found this tutorial to start me off. Although it is a little bit outdated, it works fine for my purposes.

The first thing I needed to wrap my head around were co-ordinates. In Three.JS they work as follows:

(Image credit: Originally made by Keistutis on openclipart.org, tweaked for use here by me)

If you imagine your physical laptop screen as the 3D space that your stuff lives in, then the x co-ordinate is from side to side (left: negative, right: positive), the y co-ordinate goes up (positive) and down (negative), and the z co-ordinate goes in front and behind (coming out of your screen: positive, going into your screen: negative) of your screen.

I am noting down the co-ordinate system here for my own reference... :D

You can see the code in action that I have written here: one - spinning cube.

If you can't see it, please check get.webgl.org. It will tell you whether your browser supports WebGL or not. Some (older?) chromebooks also have a buggy WebGL implementation if you use one of those.