About Me

I'm just someone struggling against my own inertia to be creative. My current favorite book is "Oh the places you'll go" by Dr. Seuss

Thursday, March 27, 2008

Relational Model; Ur doin it wrong.

Databases: did you know that if you follow the convention of naming columns that represent the same things, with the same name (for instance, part id's named Part_Id in all tables), then you can use the SQL keyword "NATURAL JOIN" to join two tables, without having to add a bunch of "where partid=id" style clauses to your query?



Let me put this a different way: If you're following a poor naming convention, you're making your SQL queries longer and more difficult than they need to be!

Well, suppose we assume that everyone follows the "Same thing=same name" convention. Then SQL could potentially assume that you mean NATURAL JOIN by default when you say "JOIN".


Well, now that we have that assumption, I can't think of a situation where you would need to mention more than one table in a query, if you weren't joining them. (can you?). So let's assume that whenever a query contains the names of more than two tables, you mean to join them. It'll join on likenamed columns automatically, and you've just saved yourself a whole lot of trouble.


in fact, why do we need to mention the table names twice? Once in the select clause, and again in the from clause. We already know which tables these fields are from!


We also know that the PRODUCTNAME field can only be found on the products table, and that the PARTNAME field can only be found in the PARTS table, and that the column that they both have in common is the PARTID column, so that's where we can join. So simply by examining the schema, we can get most of this information ourselves. So ultimately all the database really needs from the user to perform this query is


But aren't most queries going to be a select? We can optimise this even further by assuming that the user means select unless they say otherwise. Just don't name any of your columns "INSERT" ;)


Wow. So my thinking is that SQL is asking way more from the user than it really needs to perform a query- As long as the schema follows a very common convention which is best practice anyway.

We went from this:


and through our optimisations went to this:

Admittedly, there's a lot of little gotchas which I haven't covered in this blog post, but none of them are insurmountable, and surmounting them is well worth the time and effort saved by from typing all those big confusing SQL queries! Also, I have only covered the most basic of queries. There are ways to optimise the more complex queries as well.

In conclusion, SQL sucks, and we need something new, and something better designed.

Saturday, March 22, 2008

Live Robot Walking; Another AI thought.

Lots of people have tried and failed to make robots walk upright on two legs. Those that have succeeded, made a robot that walks stiffly, and rather unnaturally. What makes me think that I can do better? I have no idea. In fact, no, I can't. But at the same time, I can't help but have ideas about how I would tackle the problem.

Because while it's apparently difficult to make a physical robot walk, I have seen a number of computer physics simulations where a simulated spring based robot seems to have no problem walking. It's possible, even if the simulations cheat to make it happen.

This is how humans walk though, in a sense. We have in our minds a physics simulation, with a simulated image of ourselves within it. Before we're able to walk as children, we simulate countless times the image of ourselves walking. We attempt to walk, and compare the results to our physics simulation, and adjust our image of physics to closer match reality. In fact, we may even adjust our image of ourselves, and the weight, length and size of our limbs to try and match the results that our senses have delivered to us.

I think to make a robot walk it needs a few things: the program controlling it needs a simulation of the robot's body configuration, and its environment. The robot needs some sensors, such as an accelerometer, to deliver to the program its physical orientation, and the configuration of its limbs. An attempt at walking must be made, perhaps random at first, and the results of an attempt must be compared to the results of the same attempt in the simulation, and in particular the simulations simulated sensors.

Then the physical simulation can be adjusted such that the simulated sensors match the results of the real sensors. Then multiple simulated attempts at walking take place, until something resembling a successful walk is achieved. It is then attempted in the real robot, the results are recorded and fed back into the simulation. One might use a number of different methods for getting the physics simulations to match the results of the real robot: Genetic, Neural network, etc. But the fact is, the more data one can get about the results of the real physics, the closer one can get the simulated physics- AT least, for this one domain: Walking.

I don't know how many iterations of practice, and real attempts it would take to make a robot walk. But research has shown that this process of repeatedly imagining ourselves doing a task, does considerably speed the time it takes for a human to aquire this task. So it stands to reason, that simulating this process in an AI, for a robot may have the same effect.

Thursday, March 20, 2008

Atari Nostalgia

I've been on a kick of nostalgia lately. It's very strange, 1970's nostalgia. What's strange about it, is I was born in 1981, so why on earth should I be nostalgic? Well, It's not really that I'm nostalgic for the 1970's so much as I'm fascinated by the distorted world depicted by advertisements and movies from the 1970's. There is a very recognizable design Aesthetic. Particularly in the videogame systems, and advertisements for them.

Wood panelling, huge metal switches, trapezoidal shapes and angles. Black joysticks, rounded corners, big red round buttons. Big round friendly typeface. It's got one foot in the 70's and one foot in the 80's. There is a very certain and recognisable design language bound up in the Atari 2600. It has a strange effect on me that I can't describe. The sort of warm fuzzy effect something can only have on you if it formed a central role in your early developing childhood. I can remember with some fondness centipede, pacman, space invaders, missile commander, pitfall, and others.

Because the atari 2600 has a design language, it means you can speak the language in art and design, and reproduce it in new works. You could make a room, for instance, that looks like an atari 2600. The grated wood paneling along the walls, trapesoidally angled shelves, big round metal switches for the lights, labelled with that friendly round bauhaus inspired typeface. stained glass windows with big blocky shapes and primary colors. Black furniture with rounded colors, and recliners activated by big round red buttons.

You could make a TV in the same language, with an integrated atari console, all bound up in what might have been thought of as the pinnacle of gaming in 1979. Have a look at the earlier Atari consoles- They have some extra switches, additional to "power" and "reset". There was also "Game A <-> Game B" and "Difficulty Level: Hard, Medium, Easy". They give a sense of modularity and uniformity in the games that was never realized in the actual software. But what if it was? What if games continued along those same lines of thought? What if a sequel console to the atari featured not just those switches, but also two cartridge slots?

Two cartridge slots? What would that mean? Well, perhaps it would finally give meaning to the "Game A <--> Game B" switch. But what if you plugged in two cartridges and it combined them in some way? The rules of one game's character being applied to the other game's mechanics and levels. Or the colors from one applied to the backgrounds to the other? Or maybe they'd be played split screen, with player one playing game A, while player 2 plays game B. If there's no player 2, perhaps player 1 plays both games simultaneously, her controller input being fed into both games at once.

Maybe instead of split screen, they are overlayed?

Maybe the atari has more switches. Aside from game difficulty, you're also able to swap out things like graphics sets, or fine grained control like paddle size ( As you can configure in some modern pong games).

It's a world that never existed, because it can't work in reality. But it can work in a painting or a sculpture. A whole parallel world of gaming, a pathway we never went down. What if we explore it now?

Saturday, March 15, 2008

Funny obsessive ideas

Video game AI constructed from an adapting Stochastic Matrix. The matrix would encode N states- however many situations one wants the AI to be aware of, and M state transitions- The actions that the AI would take given that situation. A random state transition is chosen weighted according to the stochastic matrix probabilities. If the state transition results in success, then the weight for that transition's weight is incremented. If it results in failure, all other transitions are incremented instead. it may be possible to trace back a decision path several steps, and increment several of the transitions leading up to the success or failure.

It may also be possible to do that by stating that several previous conditions constitute a single "state".

The player's behavior can be observed to produce a stochastic matrix as well, and AI behavior could be an average between the computer's own learning, and observing the player.

I'd like a program that analyzes a body of text, and highlights words and letters depending on their relative probability. This would help spot errors in esoteric texts.

I would also like to use stochastic matrices for compression of text. If a run of text conforms to the predictions of a stochastic matrix, then one can specify a character of text by the rank of its prediction. That is, if presented with the digraph Th, the matrix would predict "e" as the most likely letter to occur, and thus encode e as "1", a as the second most likely choice, would be encoded as "2" etc. I haven't tried it, but my hope is that this would produce encodings along the lines of "111111111211121113211111111211132111111311112" Not only can encodings like this be very efficiently run length encoded, but if the predictions stay below low powers of 2, each character needs significantly less than 8 bits to encode it!