2018-06-05

First June post! Okay, so lots of interviews last week has highlighted a lot of my weaker areas. Some interesting things to work on, like learning how to think about systems design better.

I'm caught up on the Algorithmic Toolbox class, still just doing the bare minimum to pass for reasons of time.

I'm pretty ahead of the curve with the linear algebra class; I think my next assignments for both classes are due in two weeks. There was a fun matrix problem that took me a while to solve, but that was because I misunderstood how to solve the problem. The problem is something like:

Convert A to row-echelon form (solve for the a's and r's below):

|   1   1   1 |   | 15 |  → |  1   a1  a2 |   | r1 |
|   3   2   1 | → | 28 |  → |  0   1   a3 | → | r2 |
|   2   1   2 |   | 23 |  → |  0   0   1  |   | r3 |

What I missed was that the substitution part is equivalent to doing substitution in a system of equations: you do pairs of rows, not operating on all three. Once I had figured that out, it was easy to write some Python to run on my new numworks calculator and solve the problem without having to stare at my laptop. The first time I took the quiz with the problem, I failed. The next round, I passed because I understood on a more intuitive level what was going on, and I could use my calculator to handle the tedious parts of calculation.

As for programming, I've been working on a query engine. To quote the email I sent to a mailing list:

In a previous post, I talked about some of the stuff I was thinking about regarding natural computing. I've been working on realizing some of these ideas in practice, starting with the memory part. To recap, the idea is to represent memory as a neural network. There a bunch of questions I have about this in practice (is adding a new memory "training"? how does one mark a memory as false? etc...)

However, to have something to work with, I've started building a memory system using a non-neural-network approach. I'm calling it a query engine (QE), for reasons that I'll explain later. The code's on github under kisom/aqe.

The basic principles of this system are

  • A memory is a "fact" and expresses a relationship between objects. I'm starting with fixed two-object systems. This can be represented as a tuple: ('is', 'sky', 'blue').

  • One of the basic features of this query engine is that it can add or remove facts (via the tell and retract methods), and it can be queried using the ask function.

  • A simple level, ask can just return whether a given fact is true or not (which is really whether or not the fact is in the knowledge base (KB)).

  • At a more complex level, we should be able to ask the KB something like ('is', 'sky', None) and have it return relevant facts (like [('is', 'sky', 'blue')]). We should also be able to get multiple facts, too: ('is', None, 'blue') might return [('is', 'water', 'blue'), ('is', 'sky', 'blue')].

The QE system also has a concept of actions, which have the following attributes:

  • positive preconditions, i.e. those that must be true (ask should return something)
  • negative preconditions, i.e. those that must be false (ask should return nothing)
  • retractions, the facts that should be retracted after the action is complete
  • updates, the facts that should be added after the action is complete

So inference basically takes the KB, a list of actions, and a set of facts that represents the desired end state. This is one area where I'm not sure what I'm doing (though I know it falls under the ægis of automated planning).

There's also the problem where I'm not sure how to express something like "two objects are at the same location." So for example, given the facts

('at', 'plane', 'oak')
('at', 'cargo', 'oak')

if I was defining an action load, how would I express (and ('at', 'plane', x) ('at', 'cargo', x)). Thinking out loud, maybe I can make the subjects a comma-separated list? Not sure, I'll have to play with it.


Tags: