Jason Rush

Rave: Back at it

noreply@blogger.com (Jason) — Mon, 14 Dec 2009 01:08:00 +0000

Last year, I started working on a JRuby port of the Google Wave robot API called Rave. I took a bit of a hiatus from working on Rave, since the Google Wave API was a bit unstable, and I had been spinning my wheels trying to solve some things that turned out to be unsolvable... Anyway, the Wave API has stabilized a bit, so I'm back at it. And I have some help - a couple of people have been contributing code to the project. Which is, by the way, awesome.

Anyway, I'll post more on Rave pretty soon. In the mean time, check it out on Github, for more info. Particularly the README.

Vendor Jars

noreply@blogger.com (Jason) — Mon, 23 Nov 2009 05:15:00 +0000

I'm hanging out at JRubyConf today, and I got all inspired to contribute something to the community. So I decided to put together a little plugin for auto-loading jars into a JRuby on Rails project. One of the key advantages of using JRuby instead of MRI is the availability of all of the mature Java libraries. In JRuby, you have the ability to easily wrap those libraries and access them directly from your Ruby code. The process is pretty easy, you just require each jar that you want to use, just like you'd require a gem, or another .rb file. But there is no consistent pattern for this -- no convention for where to place those files. What I wanted was to have a jars folder under vendor where you could just drop jars and have them automatically required in your app. The end result is a ridiculously simple plugin I've imaginatively called Vendor Jars.

To install it, just cd to the top-level folder of your rails app and run

script/plugin install git://github.com/diminish7/vendor_jars.git

This will add the plugin to your vendor/plugins folder, and it will create a vendor/jars folder. Then, for any Java jar that you want to be accessible from your JRuby code, just drop the jar into that vendor/jars folder, and it will automatically get required at startup.

That's it. I know it's not much (it's like 4 lines of code or something) but I feel like I write that same code every time I do a new JRuby app, so, simple as it is, I think it'll be useful.

Taking a Break from Rave

noreply@blogger.com (Jason) — Sun, 13 Sep 2009 20:07:00 +0000

I've had a frustrating couple of weeks working on Rave. Rave is a Ruby port of the Python API for building robots in Google Wave. Wave is pretty unstable, and so I keep running into problems where I'll spend hours debugging my code only to determine that it's a problem with Wave. So I'm going to set it aside for a little while. In about a month, Google is going to release new versions of everything, and start letting the general public sign up for Wave accounts. I assume that they are planning on having a more stable version of Wave at that point. So, I'll revisit it then. As it stands, Rave is in a pretty good spot for building a lot of types of robots. The two big things I've been fighting with recently are that the capabilities versioning doesn't work correctly (so Wave caches your robot's capabilities and you can't add or remove capabilities in new versions), and cron events don't work. I'll revisit both of those in October once a more stable version of Wave is out. Until then, I need to stop spinning my wheels and start focusing on some side projects that I can make some actual progress on.

Rave: Google Wave Robots in Ruby

noreply@blogger.com (Jason) — Sun, 21 Jun 2009 17:03:00 +0000

Google Wave
There's been a lot of talk about Google Wave lately, so what's Wave all about? Wave is a protocol, that extends XMPP. In practice, it contains elements of email, instant messaging and threaded discussion. Oh, and document management. Yeah, it seems to do just about everything. The problem with that is that it makes it really hard to describe. It always sounds like it is trying to be everything - to solve every problem. But really, it's all about online collaborative communication. Here, take a look at the demo from the Google I/O keynote this year. It makes more sense once you've seen it in action.

Wave is in an alpha release right now. As far as I know, only the attendees of Google I/O have accounts on the sandbox. Hopefully that will change before too long. Google's only saying that it will be released "before the end of the year" right now. In the mean time, there's a ton of information on the main Wave site, the wave protocol site, and the Google blog.

Some Terminology
There are three primary components to Google Wave: waves, wavelets and blips. Waves are the central component. Think of a wave as a conversation. A wave has one or more wavelets, which are sort of like sub-conversations, or threads of discussion under a conversation. Finally, blips are the actual messages in the discussion, so a wavelet can contain one or more blips. There's a better description of these terms in the protocol spec.

Wasn't This Post Supposed to be About Robots?
Here's what's really cool about Google Wave: there's an API for building extensions for it. There are three things that a developer can do with Wave: embed a wave on a website, build gadgets to be embedded in a wave, and build robots. There's a discussion on each of these on the Wave API site. My focus here is going to be on robots, because let's face it, robots are awesome.

Robots are automated participants in a wave. They can do basically anything that a human participant can do: they can read the conversation, add to the conversation, and they can edit a conversation. So you can, for example, build a spell checker that reads everthing you post to a wave and edits it to change typos as you type. There are some cool examples of things you can do with robots in the Google I/O keynote demo.

Google Wave Robot Tools
Google released two toolkits for building robots, one in Java, and one in Python. Furthermore, there is currently a restriction in place that requires robots to live on Google App Engine. So that means that a robot has to either be in Python or Java... or some other language implemented on the JVM. Happily, for those of us who prefer to code in Ruby, we've got JRuby. Now all we need is an implementation of the robot client API in Ruby.

Rave: A Google Wave robot client framework for Ruby
There are several parallel efforts to create a Ruby implementation of the robot API. The rest of this post is going to focus on Rave, but I just wanted to link to the other implementations that I'm aware of:

Sam Ruby's Wave Robot Ruby Client
Jack Danger's Wave
Mike Sofaer's Wave Robot Sinatra Template

Warning!
Both Rave and Google Wave are super-alpha. There are a lot of things in the protocol that aren't implemented in Rave yet. And the protocol is changing, so the things that are implemented are likely to break at some point. I will try to keep up, but if you notice anything broken, or if you have a need for something that isn't implemented yet, shoot me an email: diminish7 at gmail dot com.

Okay. You've been warned.

The Basics
Since Google currently requires that all robots run on App Engine, this tutorial assumes you are using JRuby. You should have JRuby already installed, and you should have the App Engine SDK installed. You can find more information on JRuby at http://jruby.org/, and you can find more information about the App Engine SDK at http://code.google.com/appengine/downloads.html

What We're Going to Build
I hate it when people yell in writing. I want a robot that will moniter discussions and tone down any yelling. So, for example, this robot will turn a post like "I'M NOT YELLING!!!!" into "I'm not yelling." The full source for this robot is in git under examples/appropriate-casey/. Here's how you build it yourself:

Install Rave


   sudo jruby -S gem install rave

Start a new Rave Project
Rave comes with a "rave" executable that, among other things, sets up the project structure for you. Setting up a new project looks like this:


   jruby -S rave create [robot_name] [options]

The options include profile_url and image_url, which will set the URL for the robot's profile and avatar, respectively. Here's how the example project "appropriate casey" was set up:


   jruby -S rave create appropriate-casey

I haven't bothered to create an avatar for casey, but if I had, I would instead have done:


  jruby -S rave create appropriate-casey image_url=http://myimageurl/avatar.png

This will stub out a project called "appropriate-casey". It automatically creates a robot class AppropriateCasey, creates the config files for both Rack and Warbler, and creates the appengine-web.xml file that App Engine will need. For the App Engine file, it assumes that the App Engine project name is the same as the robot's name. So in this case, the application name is appropriate-casey, which means I have to have the URL http://appropriate-casey.appspot.com. If you name your robot something different than the App Engine application ID, just change the line in appengine-web.xml.

Build your robot!
The robot.rb file that Rave created contains a class that extends Rave::Models::Robot. All of the logic needed for your robot to talk to App Engine is included in Rave::Models::Robot, so all you really need to do now is define your robot's event listeners. Here is a list of the events that Google Wave can send your robot:

WAVELET_BLIP_CREATED
WAVELET_BLIP_REMOVED
WAVELET_PARTICIPANTS_CHANGED
WAVELET_TIMESTAMP_CHANGED
WAVELET_TITLE_CHANGED
WAVELET_VERSION_CHANGED
BLIP_CONTRIBUTORS_CHANGED
BLIP_DELETED
BLIP_SUBMITTED
BLIP_TIMESTAMP_CHANGED
BLIP_VERSION_CHANGED
DOCUMENT_CHANGED
FORM_BUTTON_CLICKED

To add a listener to your robot that will respond to a given event, just define a method with the lower-case version of the event name, that accepts an event and a context. So, I want appropriate-casey to do something whenever a document is changed (the DOCUMENT_CHANGED event), so I add the following method to my robot:


   def document_changed(event, context)
      # Do some stuff
   end

The Event object contains the following properties:

type (the type of event, "DOCUMENT_CHANGED" in this case)
timestamp (the timestamp that the event occurred)
modified_by (the user ID of the user who modified the document)
properties (varies by event type, but this will be a range of affected text in this case)

The Context object contains the following properties:

waves (a hash - the keys are the wave IDs, and the values are the waves)
wavelets (a hash - the keys are the wavelet IDs, and the values are the wavelets)
blips (a hash - the keys are the blip IDs, and the values are the blips)
operations (an array of operations)

See the Google Wave protocol documentation for definitions of each of these things...

So, with Appropriate Casey, I want to create a robot that looks for people "shouting" in Waves. To do this, I just create a document_changed method in my robot that looks something like this:


   def document_changed(event, context)
     unless event.modified_by == "appropriate-casey@appspot.com" || 
            event.modified_by == "spelly@gwave.com"
        context.blips.values.each do |blip|
          if blip.content
            new_sentence = true
            blip.content.length.times do |index|
              range = index..index+1
              char = blip.content[index, 1]
              if char =~ /[A-Z]/ && !new_sentence
                blip.set_text_in_range(range, char.downcase)
              elsif char =~ /[a-z]/ && new_sentence
                blip.set_text_in_range(range, char.upcase)
              elsif char == "!"
                if new_sentence
                  blip.delete_range(range)
                else
                  blip.set_text_in_range(range, ".")
                end
              end
              new_sentence = (char =~ /\.!?/ || (char =~ /\s/ && new_sentence))
            end
          end
        end
      end
   end

For simplicity's sake, I'm brute-forcing this a bit. It would be better to look at the event properties and just change the range of text that the event is telling me about.

So that's it, my robot is now ready to go: just 17 lines of code.

Packaging for deploy
I'm assuming that you have an application set up on App Engine already. Again, for the time being, all robots have to be on App Engine to work with Google Wave.

First of all, we need to turn our project into the correct format for App Engine. There is a utility
in the "rave" executable for this, so from your robot's top-level folder, run:


   jruby -S rave war

This is basically just a wrapper around the warbler gem, but with some additional cleanup to get things in the right format for App Engine. For example, the complete JRuby jar is too large for App Engine, so Rave breaks it up into two jars. Once you've run "rave war", you'll see a tmp/ folder, and a .war file. You can ignore the .war file, as App Engine needs the unpacked version. The tmp/war folder is what will get deployed.

Testing
The worst part about App Engine is testing...

Rave includes a "server" command that starts up Rack for your application, but that is of limited use, since App Engine has many App Engine-specific issues. Better to use the App Engine SDK (which is still not a perfect match to the deployed environment, but it's better). The App Engine SDK comes with a dev_server command. From your project directory run:


   path/to/appengine_sdk/bin/dev_server tmp/war

This will start the development server on port 8080. You can now hit the following three URLs:

The first two are GETs, but the last one requires a POST. See the Google Wave protocol for the expected body of the POST if you want to test locally.

Deploying
Use the App Engine SDK to deploy. From your project directory run:


  path/to/appengine_sdk/bin/appcfg update tmp/war

Using the Robot
From a Google Wave client, start a new wave, and invite your robot as a participant. Your robot's user name will be [robot_name]@appspot.com. So Casey is at appropriate-casey@appspot.com.

The End
That's it. You now have a working robot! Enjoy!

Moonstone

noreply@blogger.com (Jason) — Wed, 17 Jun 2009 01:03:00 +0000

We recently open-sourced Moonstone, our JRuby wrapper around Lucene, the Java search engine toolkit. Moonstone is simple, and easy to use - it lets you put together a powerful search engine quickly. It gives you the full capabilities of Lucene, but replaces the Java-isms with a more Ruby-ish syntax. I wanted to take a quick minute to run through the basics:

Installation

    sudo jruby -S gem install moonstone

Note that if you are on Windows, drop the "sudo". Also, for the record, no one's ever tested Moonstone on Windows. But since it's all JRuby and Java, there shouldn't be any issues...

If you want the source, you can get it from automatthew's github repo.

Engines

Creating an engine requires two things: a doc_from method and an analyzer.


  class SimplestEngine < Moonstone::Engine
    def doc_from(record)
      doc = Lucene::Document::Doc.new
      doc.add_field('name', record[:name])
      doc.add_field('desc', record[:description])
      doc
    end
   def analyzer
     @analyzer ||= Lucene::Analysis::WhitespaceAnalyzer.new
   end
 end    
 # We can now instantiate the engine
 engine = SimplestEngine.new
 # and create an index of some data
 records = [
     {:name => "Moonstone", :description => "A simple JRuby wrapper around Lucene"},
     {:name => "Foo", :description => "A search engine based on Moonstone"}
   ]
 # By convention the index method accepts an Enumerable that yields hashes
 engine.index(records)

 #Search for data
 q = Lucene::Search::TermQuery.new("name", "Moonstone")
 documents = engine.search(q)
 documents.each {|d| puts d['name']}

That's it in a nutshell. There are some more examples in the README on github, and more documentation is coming soon.

Happy searching!

Beholder: A Ruby Template Engine

noreply@blogger.com (Jason) — Wed, 13 May 2009 04:28:00 +0000

I started up a new project to create a template engine for Ruby web apps. The beginnings of it are on github here. It's very, very rough, so don't judge yet. :-)

I know there are a ton of template engines out there. But here's my complaint with them: often the person developing the front end of an app is primarily an HTML/CSS/JavaScript developer. They may not know Ruby at all. So template engines like Markaby and Hoshi are out. ERB is the most HTML-like template engine, but a) it's still got Ruby mixed into it, so it isn't ideal for strictly front-end developers, and b) it's a mixture of Ruby and HTML, which is ugly and spaghetti-ish.

Enter Beholder.

Beholder is a template engine comprised of HTML tags. Dynamic behavior is accomplished through the use attributes. So, for example, if you have a page and you want to show a chunk of it conditionally, you could do something like this:

<html>
<head>
<title>Hello World</title>
</head>
<body>

Body of 'if' component


Body of 'elsif' component


Body of 'else' component

</body>
</html>

Which would be rendered as:

<html>
<head>
<title>Hello World</title>
</head>
<body>
Body of 'if' component
</body>
</html>

The 'component' attribute can either refer to a built in control flow structure, such as 'if', or 'foreach', or it can refer to a partial, so you can embed mini-beholder templates in your main template. There is also a 'yield' component, so each component can act like a layout, generating it's HTML, and then yielding the content within the component node in the template.

In addition, any attribute can be made dynamically by including the 'prop:' prefix. So if you have a template like this:

<html>
<head>
<title>Hello World</title>
</head>
<body>

</body>
</html>

And a partial called simple_component.beh like this:

What's up, world?

It would be rendered like this:

<html>
<head>
<title>Hello World</title>
</head>
<body>
What's up, world?
</body>
</html>

The 'prop:' prefixed attributes get evaluated as (in this order) a) the value of the parent component's attribute with that name, b) the value of a local variable of that name, or c) a method in the helper class. (Note that I've only implemented a) right now... so you'll just have to trust me that that's where I'm going.)

This is modeled after Tapestry templates (Java) and Kid templates (Python). Anyway, there's a lot of work to be done on it (particularly around the evaluation of 'prop:' attributes), but I like the idea of it a lot.

Ruby HTML Template Engines

noreply@blogger.com (Jason) — Mon, 04 May 2009 02:35:00 +0000

I've been thinking a bit about template engines in Ruby. There's a ton of them out there. Here's a good review of a bunch of them. We generally use either Hoshi or Markaby at my job right now. For our purposes, these have been great. We all work on all aspects of a project, from front to back, and we'd all rather write Ruby than HTML. However, in several jobs I've had, we've had a front-end developer doing all the HTML and CSS. The problem is that people who really specialize in front-end development often don't know Ruby. So Hoshi and Markaby are out. In those situations, we've used ERB templates. But then you've got Ruby and HTML mixed together, and that's never pretty. What I'd really like is a template engine that just looks like HTML, with no Ruby mixed into it. Something along the lines of Python's Kid, or Java's Tapestry templates. I've been looking around a bit and haven't found anything like that yet in Ruby. Sounds like time to spin up a new project! More to come...

More Logic Games

noreply@blogger.com (Jason) — Wed, 29 Apr 2009 04:39:00 +0000

The two position-based logic games (broadcast and piano_instructor) are working correctly now, with all rules and facts coming from the DSL, including the rules inferred by the combination of other rules.

It ain't pretty though... The inference of rules is very non-generic, and very spaghetti code-ish. I really just wanted to get the logic straight in my head first. I'll look at pretty-ing it up next. But it works! Better to have ugly, but working code today, right?

Logic Games: Almost There!

noreply@blogger.com (Jason) — Sat, 25 Apr 2009 20:21:00 +0000

Made a bit more progress on the Logic Games project today. I have all of the rules for both the broadcast game and the piano instructor game set up generically, so that all of the base rules are specified in the DSL. Here's an example, taken from the broadcast game:

new_game
called "Broadcast"
described_as("Seven consecutive time slots... etc")

with_property "Position"
with_range 1, 7
for_entities "G", "H", "L", "O", "P", "S", "News"

new_question
described_as "If G is played 2nd... etc"
with_fact "G", "Position", :is, 2
determines ["News", "H", "L", "O", "S"], "Position", :is, 3

#L must be played immediately before O
new_rule "L", :before, "O", 1
#The news tape must be played at some time after L
new_rule "News", :after, "L"
#There must be exactly two time slots between G and P, regardless of
# whether G comes before P or whether G comes after P
new_rule "G", :separated_by, "P", 2

evaluate

That generates almost all the facts and rules for the game. There are a few rules that are implied by the combination of these rules - since "O" is immediately after "L", and "News" is sometime after "L", then "News" must be at least 2 after "L". So that's next: figure out how to imply rules from combinations of explicit rules.

The Start of a DSL

noreply@blogger.com (Jason) — Fri, 17 Apr 2009 00:50:00 +0000

I've started refactoring my logic games into a DSL that more closely approximates the English language logic games questions. Here's what I have so far:

#Set up game description
new_game
called "Broadcast"
described_as(
"Seven consecutive time slots for a broadcast, numbered in chronological order 1 through 7, will be filled by six song tapes - G, H, L, O, P, S - and exactly one news tape. Each tape is to be assigned to a different time slot, and no tape is longer than any other tape. The broadcast is subject to the following restrictions:
L must be played immediately before O
The news tape must be played at some time after L
There must be exactly two time slots between G and P, regardless of whether G comes before P or whether G comes after P"
)
with_property "Position"
with_range 1, 7
for_entities "G", "H", "L", "O", "P", "S", "News"

#Create the questions
new_question
described_as "If G is played second, which one of the following tapes must be played third?"
with_fact "G", "Position", :is, 2
determines ["News", "H", "L", "O", "S"], "Position", :is, 3

This replaces the first 70 lines of the game. It sets up the game, and adds all the standard rules, like one-place-at-a-time rules, mutual-exclusion rules, and last-available-position rules.

My goal was to make this read more or less like the English version of the game. One interesting requirement for that has been that it needs to remember context. So if I say "new_question" on one line, then "described_as ..." on the next line, the game needs to remember that "described_as" applies to the new question we just created. I'm doing this by maintaining state. So each action keeps a record of the thing it acted upon, so that the next action knows what the context is. The alternative was to string together actions, like "new_game.described_as(description).with_fact(...)" etc. I didn't like that approach because it looks less like English, which was, again, my goal.

The next step in the DSL will be a simple way to specify the rules. I want it to be close to the English version of the rule, so

"Henry's lesson is later in the schedule than Janet's"

might turn into something like

new_rule "Henry", "Position", :after, "Janet"

Which will then get broken up into the 20 or so rules that that implies behind the scenes.

Victory!

noreply@blogger.com (Jason) — Wed, 08 Apr 2009 04:18:00 +0000

The Logic Games project now officially solves its first game! It's admittedly a pretty manual process right now. I still have to break the logic game up into all the initial rules and facts. But then it successfully runs through the rule engine and generates all the facts that can be inferred, and answers the question.

Here's the game it solves right now:

Seven consecutive time slots for a broadcast, numbered in chronological order 1 through 7, will be filled by six song tapes - G, H, L, O, P, S - and exactly one news tape. Each tape is to be assigned to a different time slot, and no tape is longer than any other tape. The broadcast is subject to the following restrictions:

L must be played immediately before O
The news tape must be played at some time after L
There must be exactly two time slots between G and P, regardless of whether G comes before P or whether G comes after P

If G is played second, which one of the following tapes must be played third?

The news
H
L
O
S

If you grab the code from github, and run

ruby logic_games.rb games

it will correctly tell you L is in the 3rd position.
Yay!

It was interesting to me that there were a lot of rules that I was using intuitively when I solved the problem by hand, but that I neglected to add to rule base because I never explicitly acknowledged the rule in my head. An example of this is the rules and facts generated by the combination of the fact that L must be played immediately before O, and the News must be played some time after L. What that implicitly means is that the News must be at least 2 slots after L, because the slot immediately after L is taken up by O. These types of rules will be the hardest to generalize, because they need to take external knowledge (previous statements) into account.

So the next step is to start generifying the logic for creating rules and facts. I would like to come up with some sort of DSL for specifying knowledge in a way that approximates the written game statements. So, for example, to specify that L must be played immediately before O, you might have something like

"L".before("O", 1)

which would translate into "The entity with the name of 'L', must be positionally before the entity named 'O', by 1 position." This would then generate the 20 or so rules that this implies, like "If L is in position 1, then O is in position 2", etc.

So, to accomplish this, I'm going to work on implementing several other games so I can start getting a feel for the types of generalizations I'll need to implement. Then I'll go from there.

Good times.

Rule Engine

noreply@blogger.com (Jason) — Tue, 17 Feb 2009 01:55:00 +0000

So I am basically at the point now where I have a functioning rule engine for the logic games project. It's all out on github. Here's the gist of it:

The class structure is described here, from a few posts ago. The rule evaluation is the new part. The RuleBase stores a list of Facts, which are in a hash keyed by the Entity and the Property to which they apply.

A Clause can be evaluated by determining if there is a Fact with the same information. So the Clause's truth is evaluated by looking at the RuleBase's facts hash with the Clause's Entity and Property. If a Fact is found for that Entity and Property, and the Fact's property_value and comparator match those of the Clause, then the Clause evaluates as TRUE. If the Fact's property_value matches that of the Clause, but the comparator is NOT equal to the Clause's, then the Clause evaluates as FALSE. In all other situations, the Clause evaluates as UNKNOWN.

A ClauseCluster is evaluated by looking at the rhs and lhs (right hand side and left hand side of the clause) and using the operator to perform Boolean logic. So if the operator is AND, then the lhs and rhs must both be TRUE for the ClauseCluster to evaluate to TRUE, and if the operator is OR, then the lhs and the rhs must both be FALSE for the ClauseCluster to evaluate to FALSE. If the truth of the ClauseCluster can't be determined (for example, if the operator is AND and the lhs is TRUE but the rhs is UNKNOWN, then the ClauseCluster evaluates to UNKNOWN.

Rule's are evaluated by evaluating the Clause or ClauseCluster that is the antecedent. All the work is delegated to the antecedent's evaluation method. The interesting part of the Rule's evaluation is what happens after the truth of the antecedent is determined. If the antecedent is TRUE, then a new Fact gets added to the RuleBase's facts hash based on the consequent. If the antecedent is TRUE or FALSE (i.e. not UNKNOWN), then a flag gets set marking the Rule as having been fired.

The RuleEngine gets evaluated by evaluating all of its Rules. It iterates over all of its Rules, evaluating any Rule that has not already been fired (i.e. who's truth is still UNKNOWN) until either a) all Rules have been fired, or b) the remaining unfired Rules cannot be evaluated because we don't have enough information. In the case of the latter, this is determined by completing a full iteration without inferring any new knowledge. So if all Rules get evaluated, and no new Facts get generated, then the no new Facts will be generated in the next iteration either, so we can stop trying.

My next step is to start putting together a suite of tests that represent real logic games data. For right now, I am going to manually convert a set of logic games into sets of Rules and Facts just to test out the rule engine. After that, the really hard work begins: parsing a logic game, turning natural language into a set of Rules.

Finally, Some Progress

noreply@blogger.com (Jason) — Sun, 01 Feb 2009 00:47:00 +0000

Whew, I have finally had enough time to get going on the logic games project. It's out on github at http://github.com/diminish7/logic-games/. Right now it just the model, some basic validations and specs. More to come, I swear!

Crazy Busy...

noreply@blogger.com (Jason) — Mon, 12 Jan 2009 01:01:00 +0000

So, I have been so crazy busy lately that I didn't even notice that my blog was down for like two weeks... Sorry, all of my loyal readers (that's funny because right now that's just my wife...).

I hope to make some more progress on the logic games project next weekend. I've been doing some stuff with natural language processing at work. So I am rethinking how I want to persist the data: rather than trying to persist it relationally, I am thinking more and more about trying to parse the text of the logic games questions into these objects on the fly, so all that needs to be persisted is the text.

So I think I will simplify phase one of the project a little by cutting persistence out of the picture (this means you DataMapper).

More on this next weekend (I hope). And hopefully more progress next weekend.

Rule Grammar Persistence

noreply@blogger.com (Jason) — Sun, 07 Dec 2008 19:48:00 +0000

Here is a very high-level diagram of the grammar for storing rules in the logic games project.

RuleBase is the top-level class that stores the collection of Rules and the collection of known Facts. A Rule consists of an Antecedent (the "if" portion of the rule) and a Consequent (the "then" portion of the rule). The consequent is a simple Clause, which consists of an Entity / Property pair a comparator and a value for the property. So to represent a car being painted blue, we would have an Entity of "car", a property of "color", a comparator of "equals" and a value of "blue". The antecedent is a ClauseCluster, which represents one or more Clauses joined by the Boolean operators AND, OR and NOT. To represent this, a ClauseCluster has a left-hand side (lhs) and a right-hand side (rhs), each of which can either be a Clause, or another ClauseCluster. So you get a tree of ClauseClusters, where the leaves of the tree are Clauses, and the depth of the tree represents different levels of parenthesization.

I want to be able to persist RuleBases. It's not really necessary for this project, but it will help with testing, and since this is all just a way for me to learn more about knowledge representation, I wanted to make sure I could persist that knowledge as well.

I started working with DataMapper as the persistence layer. I've done a bunch of work with ActiveRecord, and I wanted to try something new. DataMapper has several features that make it really interesting to me. I like the query syntax, and I love that it only keeps one instance of each object in memory at a time. However, one thing it is lacking that I need in this project is polymorphic associations. Since the lhs and rhs of a ClauseCluster can either be a Clause or another ClauseCluster, I need a way to define a relationship based on both id and type. I only need to ever walk the tree from top to bottom, so only need one side of the polymorphic relationship (i.e. a ClauseCluster has one lhs and has one rhs, but I don't care if the lhs and rhs know who their parent ClauseCluster is). So I'm putting together a very simple implementation of polymorphic associations for DataMapper. It's too simple to be of much use to anyone outside of this project, but I'll post the code when it's ready.

Brute Force

noreply@blogger.com (Jason) — Thu, 27 Nov 2008 21:39:00 +0000

Thinking some more about the Logic Games project, my first attempt is going to be brute force. Each of the statements in the logic game text can be converted into a series of Boolean rules (rules whose conditions either evaluate to true or false), and then I can create a rule engine to iteratively generate facts until the question has been answered.

Here's an example, taken from another LSAT question:

A piano instructor will schedule exactly one lesson for each of six students - Grace, Henry, Janet, Steve, Tom and Una - one lesson per day for six consecutive days. The schedule must conform to the following conditions:
Henry's lesson is later in the schedule than Janet's lesson
Una's lesson is later in the schedule than Steve's lesson
Steve's lesson is exactly three days after Grace's lesson
Janet's lesson is on the first day or else the third day
If Janet's lesson is scheduled for the first day, the the lesson for which of the following students must be scheduled on the sixth day - Grace, Henry, Steve, Tom or Una?

From this, we can generate a large number of Boolean rules to describe the problem. These rules will take the form of if ... then ... statements. Taking a look at the first condition - Henry's lesson is later in the schedule than Janet's lesson - we can derive the following rules:

If Janet is in the fifth position, then Henry is in the sixth position.
If Janet is in the fourth position, then Henry is NOT in the third position
If Janet is in the fourth position, then Henry is NOT in the second position
If Janet is in the fourth position, then Henry is NOT in the first position
If Janet is in the third position, then Henry is NOT in the second position
If Janet is in the third position, then Henry is NOT in the first position
If Janet is in the second position, then Henry is NOT in the first position
If Henry is in the second position, then Janet is in the first position
If Henry is in the third position, then Janet is NOT in the fourth position
If Henry is in the third position, then Janet is NOT in the fifth position
If Henry is in the third position, then Janet is NOT in the sixth position
If Henry is in the fourth position, then Janet is NOT in the fifth position
If Henry is in the fourth position, then Janet is NOT in the sixth position
If Henry is in the fifth position, then Janet is NOT in the sixth position

In addition, we can derive two facts from the first condition:

Janet is NOT in the sixth position
Henry is NOT in the first position

Then there are three types of additional rules that are implied for all combinations of person/position:

If person A is in position X, then persons B, C, D, E, and F are NOT in position X
If person A is in position X, the person A is not in any of the other positions
If person A is NOT in positions 1, 2, 3, 4, or 5, then person A is in position 6

So, for example, we would have a set of rules for Henry like this:

If Henry is in position 1, then Grace is NOT in position 1
If Henry is in position 1, then Janet is NOT in position 1
If Henry is in position 1, then Steve is NOT in position 1
etc...

And

If Henry is in position 1, then Henry is NOT in position 2
If Henry is in position 1, then Henry is NOT in position 3
If Henry is in position 1, then Henry is NOT in position 4
etc...

And

If Henry is NOT in position 1, and Henry is NOT in position 2, and Henry is NOT in position 3, and Henry is NOT in position 4, and Henry is NOT in position 5, then Henry is in position 6
etc...

Once you have generated all of the rules, the way that the algorithm will work is to iterate over the rules deriving new facts. We start off with 1 fact: Janet is in position 1. So as we iterate over the rules, we can fire at least 10 additional rules that will derive new facts: Grace is NOT in position 1, Henry is NOT in position 1, Steve is NOT in position 1, Tom is NOT in position 1, Una is NOT in position 1, Janet is NOT in position 2, Janet is NOT in position 3, Janet is NOT in position 4, Janet is NOT in position 5, Janet is NOT in position 6.

After you make a pass across every rule, you start over at the top, testing each rule again given the facts that we derived from the previous pass, then continue until you have gathered enough facts to answer the question (in this case, Una is the correct answer).

Because this is a brute force approach, we get a lot of rules to test, so the algorithm will need to keep track of which rules have already been fired (i.e. which rules have a known answer), and on each iteration, only test the unfired rules.

Now, there is still a lot of hard manual work to do to solve this problem - for each condition, we have to manually break it up into a series of Boolean rules. So, in the long run, I will want to at least make some sort of DSL to allow me to put in the conditions in a more-or-less English syntax, and let the system generate all the rules for me. But let's call that phase 2 :-) For now, I want to focus on building the rule engine. I am looking through the book Constructing Intelligent Agents Using Java by Joseph and Jennifer Bigus. The fourth chapter, Reasoning Systems, outlines a rule inference engine that I am planning on using as a model for mine. Their engine does a lot of stuff that I don't need for mine, like accounting for fuzzy logic, so mine will be a lot simpler. Also, I'll be working in Ruby rather than Java, and I think that the dynamic nature of Ruby will also simplify the code quite a bit. So it isn't exactly a port of the Java code to Ruby, I'm just using it as a good starting point.

I hope to get started over the long weekend, and I'll stick my code up on Github.

Logic Games Project

noreply@blogger.com (Jason) — Fri, 14 Nov 2008 00:44:00 +0000

Lately I've become interested in knowledge representation as it applies to computer science. I'm no expert on the subject. The opposite, really. But interest is a good place to start, I guess. So, I wanted to start a project that would give me a good excuse to really explore the topic.

I've been following Ola Bini's blog, and he's had a really interesting series of posts where he has been porting the code from Peter Norvig's book, Paradigms of Artificial Intelligence Programming, from Common Lisp to Ruby. I've been sitting on that book for a couple of years now, and every time I pick it up, my lousy Lisp skills get in the way, and I eventually drop it. But having Bini's Ruby code to compare it with has re-inspired me to pick my way through it again.

One of the things that really stands out with early AI research is how AI is defined. The Turing Test is one of the best known intelligence indicators. It goes like this: A human participates in two conversations, one is with another human, and the other is with a computer program. If the person can't tell the difference between the two, then the computer program has demonstrated intelligence.

There's a competition every year where programmers try to pass the Turing Test. No one has won yet, but people are coming close. What I really find interesting about it, though, is how people are coming close. If you look at some of the code that is producing human-like conversations, you find that a lot of it doesn't seem "intelligent" at all. At least not in the way that we intuitively think of "intelligence" - it has no understanding of the conversation. Take a look at Eliza, for example. Eliza is a very early attempt (1966) to pass the Turing Test. Eliza basically looks for patterns in the human statements and maps those patterns to responses. As a simple example, you might say to Eliza, "I want a new car" and Eliza's response might be "What would it mean to you if you got a new car?". So "I want X" gets mapped to "What would it mean to you if you got X?".

This is obviously a very simple example, Eliza is capable of a lot more complexity, but it is still pattern matching, not understanding. In addition, Eliza is 40 years old - a lot has happened in AI in the last 40 years. However, thinking about this approach to passing the Turing Test got me thinking about other measures of intelligence, and whether or not it would be possible to solve various intelligence tests programmatically without actually achieving what the average person would intuitively know as "intelligence". So here's what I landed on: I want to try to solve certain types of standardized test questions. Specifically the type of logic games you find on the LSAT and GRE.

Here's an example (pulled from an old LSAT):

Seven consecutive time slots for a broadcast, numbered in chronological order 1 through 7, will be filled by six song tapes - G, H, L, O, P, S - and exactly one news tape. Each tape is to be assigned to a different time slot, and no tape is longer than any other tape. The broadcast is subject to the following restrictions:
L must be played immediately before O
The news tape must be played at some time after L
There must be exactly two time slots between G and P, regardless of whether G comes before P or whether G comes after P
If G is played second, which one of the following tapes must be played third?
The news
H
L
O
S

The way I see it, there are two major parts in solving something like this programmatically. First, you have to parse the English language into some sort of knowledge system that your software can understand, then you need to use that knowledge to infer an answer. For the moment, I am going to concentrate on the latter. For two reasons: I need to know what type of knowledge representation I am going to end up with before I can start trying to parse the English, so this seems like the better place to start, and it's the part of the problem I find more interesting (and more attainable...)

So there you have it. That's my project.

For a while I am going to solve a bunch of logic games manually to start picking out patterns. I'll post the more interesting ones, and what I learned from them. Once I start getting some code written, I'll post that as well.

I have a bad habit of getting really interested in a project for a short while, and then dropping the ball. I'm hoping that committing to it here will keep me honest. As long as there's a chance (however unlikely) that someone is reading this, I'll be shamed into finishing the project ;-)

More to come soon!

Welcome to Jason's Blog

noreply@blogger.com (Jason) — Mon, 10 Nov 2008 01:09:00 +0000

Hello! Welcome to Jason's blog!