Notes on codes, projects and everything
We were asked to develop a program that demonstrate Artificial Intelligence and apply what we had learned in class into the program. Then we came out with an idea to develop a program that is able to do tarot reading. At first the program did not have a GUI and is operated through Swi-Prolog interpreter but in the end we included a GUI-frontend for the program using XPCE.
First the program will require 3 random numbers from the user, then a random number will be generated as the seed. Then the card will be “shuffled” (in fact, we did some calculations to the user provided random numbers) and then determine the orientation of the card (normal and reversed). Then, we use the computed number to pick a tarot card and get the reading based on the orientation.
To shuffle the cards, we use a random number and place the random number into the formula such that $$c=x^y\text{ mod }23$$ where c is the corresponding card number, x is the user provided number and y is the system generated random number. Then the orientation of the card is determine by calculating the mod 2 of the random number.
To implement simple search strategy, we used a hash function to divide the total of 22 major arcana cards into 5 groups. Each group will have one individual database file storing the card characteristics and reading. Then, depending on the calculated number, the system will choose to query which database file to decrease the inclusion of database files. We may not be able to observe the performance enhancement as we only have 5 database files but it should be more obvious for system with more database files.
I am the developer for the GUI front-end. At first we planned to write the GUI using other languages/platforms but because of the time constraint we decided to give up on GUI front-end. However, I managed to pick up basic XPCE GUI construction just in time and made a GUI for the program. However, the GUI is not very friendly and is not able to display images. Because XPCE is a multi-platform supported toolkit therefore the appearance of the GUI is consistent in various supported operating system.
The program is reading input through prolog interpreter.
The program displays the result after computing the input.
The program is reading input through GUI
The program displays the result through the GUI
I like how Kohana 3 organizes the classes, and I thought the same thing may be applied to my Zend Framework experimental project. Basically what this means is that I can name the controller class according to PEAR naming convention, and deduce the location of the file by just parsing the class name.
Sometimes, letting a piece of code evolving by itself without much planning does not usually end well. However I was quite pleased with a by-product of it and I am currently formalizing it. So the by-product is some sort of DSL for a rule engine that I implemented to process records. It started as some lambda functions in Python but eventually becomes something else.
I haven’t got much time lately, so didn’t write about this new phone that I recently imported. For some reason, this new phone of mine do not act as mass storage device like its predecessors (to certain extend). Thankfully I can still ssh in the phone and this makes it possible to mount it as a sshfs volume.
This post continued from this post. Finally I have found some time to start developing my pet project using Zend Framework. After getting the controller to work the way I am more familiar (comparing to Kohana which I used at work) with, the next step is to get it to output some data.
Back then when I was attending a job interview, I was asked to write a Fizz Buzz program to prove that my coding ability. There was only a pen and a piece of paper, so basically means there’s no way I can refer to the documentation for the API syntax. Fortunately I somehow managed to remember and not screw up.