Skip to content

It’s not that AI is taking over the world but…

Artificial Intelligence (AI) has been in the news at a constant burn over the last year. Having worked with AI tools and exposed to the 5th generation project in the 1980’s in Japan had given me some perspective and a latent interest in the domain, but not enough to spend my savings or my career on it.

In those (bad old?) days there was this dream of finding the universal AI solution and that we would be abandoning our classic programming languages soon. None of that happened (and much of it I suspect had to deal with the fact that our brains aren’t really wired for the kind of languages that were touted as the future fifth generation languages).

AI then was seen as being able to completely drive a process from start to end. That never worked because all the variance that exists in the real world could never be properly predicted and addressed. Many attempts I saw ended up in a mess of coding where the effort to extend the knowledge base started to grow exponentially with every increment in that knowledge base.

However it looks like AI has undergone a revolution where product managers have taken the AI baton from AI researchers. Instead of trying to develop a generic AI solution and then looking for problems to solve, we now see AI evolution occurring in very specific domains, solving needs in very narrow problem domains that are becoming all too important. Self Driving Cars and Personal Assistants are two domains that come to mind.

So over the Christmas period I decided to take a closer look at one of these (I don’t have a self driving car, although I’d love one) and started investigate the world of chat bots. Chat bots are now quite common — Amazon Alexa, Apple Siri, Microsoft Cortana are but a few of them. They all rely on interpreting the spoken word and responding in an intelligent fashion. The difficulty here is two fold — first the device needs to understand spoken sentences and that is quite difficult to do in a generic way. Then secondly it needs to understand the intent of what was said and react to it in a way that makes sense to our expectations. So when I ask ‘what is the weather’ then I would like to what the weather is like outside of where I am, not in another continent.

I spent some time perusing frameworks and settled on API.AI to create a sample chat bot for booking rooms. It was quite efficient to develop a reasonably complete set of intents and responses and to tie this into a back end that would do the details of actually booking rooms and managing extras for the rooms (e.g. catering, projectors etc). From a creators perspective the technology is quite straight forward. You create intents (book a room, cancel that room,…), add entities (such as nr of people, catering required, etc) and then add phrases that trigger the intent.

What I really appreciated was that I could see the machine learning behind the scene (API.AI mentions machine learning but they don’t go about pushing it front and center). What the machine learning does is that it takes your phrases and applies it to the language recognition. If I had a phrase ‘book a room for today’, then it knows that today is a date and it will automatically recognise the phrase ‘book a room for tomorrow’.

I also suspect that the actual language recognition is helped by this approach. Typically, unless you are a very clear speaker without accent (which is not me) the system will have multiple interpretation to what I said. So ‘book a room’ could be interpreted as ‘Booker rule’. The machine learning engine will however score these interpretations against how well they meet the defined phrases (and their automatic derivatives).

Where does this lead us?

So I had lots of fun playing with this technology but it also gave me much to think about. The people at API.AI certainly demonstrated that AI and machine learning can improve productivity considerably in the software development domain. And this is by no means unique. A year back I played with IBM’s Watson Analytics. In data analytics, when you start looking at a problem you spend a lot of time exploring data and building and testing hypotheses. Watson Analytics simply took the data and did a lot of this aforementioned rather mind numbing foot work, eliminating all the obvious dead ends in a short time and letting you focus on the leads that look promising.

So my guess is that we are set for a shake up. Not just my profession of software engineering. I think all of us will run into narrow AI tools that will focus on making us more productive. You need to organise a party? Well your assistant may have a conversation with you and then start making suggestions on how to create a theme, when to start ordering the food and maybe even selecting the right music for you.

The original problem of universal AI is still with us and I suspect it would be a long time before we really make substantial inroads. Yes we have seen Chess AI and GO AI, but these are still narrow AI systems. To my mind the future lies in the concept of AI as an assistant that augments our abilities and let’s us focus on our creative side. Successful AI implementations will be those where the designer understands what needs to be in the domain of the AI and what needs to be in the domain of the human being. A key issue will be that of the interface between the two. There is the question of human dignity: we are very finely attuned to sense the distinction between what is helpful vs what is overbearing. Get it wrong and us humans won’t touch it.

Advertisements

Playing more with Data

I recently watched a documentary on Tsunamis and they showed an animation of a large meteor slowly tumbling while approaching earth (to explain that in the past Tsunamis could be created by meteor strikes). In an idle speculation moment I wondered at what speed meteors and other small bodies actually tumble around in space (I had also just watched the trailer for ‘Gravity’ which makes use of this idea to dramatic effect).

So I looked around and found the  JPL small body database and its API for retrieving data . I donwloaded data for bodies that have a measured rotational period and did some analysis. My naive expectation was that there would be a rather uniform distribution of rotational periods, after all there would be very few limiting interactions.
Well the first insight was that rotational period is a Poisson distribution with a peak at 10 hours. So far so good. It indicates that there is some physical origin determining that rotation speed. I am cool with that, given that many such bodies originate from the asteroid belt and therefore some commonality is not surprising.

Image

Then I decided to do a scatter diagram between diameter and rotational period and got a result that is the opposite of what I would expect. Basically the smaller the diameter the wider the distribution and the higher the median rotational period. In short, larger bodies rotate faster!?!

Image

I would have expected larger bodies to have longer rotational periods, just as real big bodies (i.e. planets (let;s ignore moons)) do.

Do I make a fundamental error here?

Update 17 September

Well I did some more analysis and found out a few things. First of all I calculated the median wrong – using a proper package like NumPy highlighted that very quickly.

Median_of_Rotation_Period

As you can see the median does not change as drastically towards the smaller bodies,

Second I grouped the records by sizes and then  plotted the distribution,

RotPeriodbyDiameter

So this shows that the differences are becoming much less of an issue. And smaller bodies do now appear to rotate slightly faster.

The upshot: be careful with visualisation! The scattergram gave an impression that upon more detailed analysis does not stand up.

So the big contradiction appears to have gone away but it is still interesting that there is a distribution. Where does it come from?

Mining the Web

I recently had a colleague over from Germany and each morning I would pick him up and we drive over to our client in Parramatta, a trip that takes about an hour. That twice daily commute gives us ample opportunity to chat and we cover a variety of topics. One day he remarked that it appeared to him that there were more duplicate street names in Sydney than was the case in Germany. That raised the question how to test such a hypothesis. First of all where to get relevant data. We quickly settled that Open Streetmap (openstreetmap.org) would be the likely best source. So next morning I checked and found that not only does it have the required data but also that there is a powerful query language to retrieve all roads and their road names.

In the end it took all of 20 minutes to download the road segment data for Berlin and Sydney and about 60 lines of python to construct and identify the unique roads (They are actually quite comparable: Sydney has about 12,500 roads and Berlin 11,700 roads).

Lo and behold, turns out that there is very little difference between the two cities. In Berlin about 88% of all road names are used only once, in Sydney it is 85% – hardly a difference.

This is what the internet revolution has actually brought us, the general availability of data. In contrast, 30 years ago when I was working as a programmer in an econometrics institute, all data had to be painstakingly researched from publication and typed in by legions of students.
Yes it still requires expertise to retrieve and process the data but at least it is available.

Postscript:
I have since compared other cities such as Munich, Hamburg, Paris, London, Rome and Denver. A great surprise that the results for all but two of them were within 1-2% points. Originally we speculated that this might be a matter of age. So the hypothesis we had was that this was caused by integration of nearby communities as cities grew older. By that hypothesis older cities would have more duplication than newer ones. As it turns out the opposite occurred. Rome has 97% unique street names whereas Denver has 71% unique street names.

Another surprise is that the plot of how many street names are used once, twice etc. follows a power distribution, i.e. the number of street names used twice are 10% of the number of unique names and the number of street names used 4 times is 1%.   Again the exceptions are Rome and Denver.

Reuse_of_Roadnames_-_loglog

When Seakayaking and Programming Meet

I did never expect that seakayaking would intersect with my SW Engineering side but it has happened recently. A few of us, after a day’s paddling were talking about how hard it is to teach the Greenland roll. This manoeuvre, which returns you to an upright position after capsizing in the kayak, is a complex body movement that can be hard to learn and hard to teach. At the core of it is the fact that it is contrary to the instinctive reaction of the capsized paddler wanting to get their head above water as soon as possible. That alone is the most common cause for a failed roll.

As we were discussing the techniques Rob, who is a senior instructor, suggested of maybe developing a program on the IPad to use its internal gyroscope and accelerometer as a feedback tool to teach this movement on dry land before attempting it in the water. Now the geek in me really responds to such a suggestion and so I decided to investigate this further. First impressions showed that there are several options to implement a feedback tool, the IPad being one of them, Microsoft Kinect and maybe even the Wii being contenders.

I have to start somewhere and I decided to use the opportunity to learn about Cocoa programming. I set down a path to follow over the next few weeks:

  1. Learn Objective-C
  2. Learn Cocoa Programming on the MAC
  3. Learn IOS programming on the IPad

Step 1 has been completed and I have made good progress on step 2. As an avowed TDD follower I selected an appropriate goal, which is to port the TestLink adapter to OCUnit, the Mac’s unit testing framework. It took a few days but tonight it finally started working, reporting the results of its own Unit Tests to Testlink.

It will take a few more days to review how to package this module. Unlike the NUnit and MBUnit approaches, the Xcode based unit testing is a bit more raw and hence will require more detailed instructions for others to be able to use it.

Once that is done it is off to step 3, IOS programming. Unfortunately I will have to shell out $100 for Apple to allow me to actually run an app on my Ipad….

Testlink Adapter v 1.3

A few years ago, when I had a bit of spare time I was evaluating test management applications as part of developing a testing course. I came upon Testlink (www.teamst.org) which is an OpenSource tool test management. I chose to incorporate this into my course and investigated it further. As I continue to do small software development for a number of personal projects I integrated it to my development cycle. I tend to use a test driven development approach with Mbunit (and now Gallio) as my testing framework. So on finding that Testlink offered an XML RPC based API, I developed an adapter between Gallio and Testlink, so that I can run my test harness and import the results into Testlink automatically. I open sourced this work and added an Nunit adapter as well. That was in 2009 and while I continued using it at home, I kind of neglected the open source site over the years.
A few months ago I received an email from a gentleman in India who wanted to use the adapter but couldn’t make it work with the new version of Testlink. So he asked me if I could update the adapter. As I had been content with the older version of Testlink I hadn’t bothered upgrading from V 1.8 to V1.9 which turned out to be quite a change functionally as well as in its API.
Well after a few weeks of work I am happy to have a new version that incorporates almost all of the new API. It has been hard work. A lot of which went into growing the regression test library into more than 90 testcases. In case you ask: yes the regression test library is fully automated and yes it makes use of the framework and the Gallio adapter to report its results into Testlink.
I can’t say enough how much this approach validates itself. With major changes to implement I have been able to find defects that I doubt I would have found with manual testing.
If you are interested to give it a try go over to http://code.google.com/p/gallio-testlink-adapter/

P.S. about a year ago I adopted python as my main development & scripting language, so maybe I will do something comparable for python. However python is easier to integrate with Testlink, so there may be not as much of a need.

Working in an environment like this

I guess it’s time I also did a bit of blogging on the social side of it. As I am between projects I have, and enjoy, the luxury to get out a bit and take in the scenery, even while blogging such as my previous Testpad blog. Take a look at what Is in front of me right now.

20120608-135458.jpg

A useful little app

I work quite a lot with tools and regard them as essential to my work. However tools are two-edged swords: while extremely useful when used appropriately, they tend to be complex and require careful training of your team members.
Especially wHen you have business users involved in user acceptance testing you need to be careful on how to introduce them to tool such as test management ones, that tend to be complex. So it was a very refreshing change to encounter this little chrome app called testpad. https://ontestpad.com/

Testpad is a minimalist application, that does allow creating very simple test scenarios and track execution against it (I guess the similarity to the name Notepad is intentional).
The user interface is simple but still slick, there are a few keyboard shortcuts which, once memorized, make work easy. It supports mobile devices so someone can use their android or iPad to record test outcomes. Collaboration is quite simple where you email someone the URL of the test script.
I have always appreciated well crafted small tools, ever since I ran into this concept in the early Unix ages so popularized by Kernighan et.al. They tend not to force you overly into specific approach to your tasks and you tend to have better interoperability between tools. The downside is that you will have to do some tool crafting of your own to make it all work, but the overall benefit makes it worth it.