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?

Before, ( in psuedo SQL): SELECT PARTS.ID, PARTS.NAME, PRODUCTS.NAME FROM PARTS JOIN PRODUCTS WHERE PARTS.ID = PRODUCTS.PARTID


After: SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS NATURAL JOIN PRODUCTS

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".

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS JOIN PRODUCTS

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.

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME FROM PARTS, PRODUCTS

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!

SELECT PARTS.PARTID, PARTS.PARTNAME, PRODUCTS.PRODUCTNAME

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

SELECT PARTNAME, PRODUCTNAME

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" ;)

PARTNAME, PRODUCTNAME

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:

SELECT PARTS.ID, PARTS.NAME, PRODUCTS.NAME FROM PARTS JOIN PRODUCTS WHERE PARTS.ID = PRODUCTS.PARTID

and through our optimisations went to this:
PARTNAME, PRODUCTNAME


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.

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.

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?

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!

Another dream I had

It was another school regret dream, with a few massive Dalek invasions thrown in. (my my, the panicky crowds of people scrambling to get away!) But it had a couple decent ideas for paintings.

Choose a book, paint a fictional landscape based on that book. But paint it flat first, just flat colors as the sketch.- Then paint it onto an image of a book, such that it appears like the landscape is extending out of the book- 3 dimensionally. Kind of like a pop up book. The process is to copy the flat sketch onto the book first- and then project the dimensional extension out of that.

The other project was kind of strange- It had to do with fictional pop culture characters placed twice across a cloudscape. (Alphred E. Newman, The Simpsons) One pose is large enough to see facial expressions, the other small enough to see body pose. The challenge is to compose it all into a single painting.


I'm not quite sure what the educational purpose of either of these projects were meant to be, but for some reason I felt quite guilty about not being able to do them properly. We'll see about that.

Bouncy Pixelly Creature

This makes me happy.
Pixels make me happy.

Thus, I wanna make a bouncy pixely creature person thing, made from good ol fashioned homegrown pixels, CSS sprites, and javascript. But the road would not be easy going.

Step #1.

Design, using pencils, the creature that I want to create

Step #2.

Break the thing down into seperate individual movable body parts, that can be animated

Step #3.

Model the parts in 3D and render from all angles that will be visible, 360 degrees around, above and below at some reasonable interval, (say, 8*8?)

Step #4.

Trace over the renders to give the parts some hand drawn pixelly juice.

Step #5.

create dom elements for each body part.
create javascript routines to move a body part to any arbitrary on screen coordinate, and switch the frame to any arbitrary frame in its body party category.

Step #6.

Create springs for each limb

Step #7.

Figure out how ventrella did the upright stance for his creatures. Creatures need balance!

Helma's documentation is confusing. Here's what _parent really means.

helma's documentation has this to say about _parent

The _parent entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their href() function.

_parent = property1, property2.collectionX, root.collectionY

If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object.

Hrrrwhat?

This is confusing, because _parent is a very specific and tacked on solution to a very specific problem with how helma is architected.

Helma works by mapping a javascript object graph to a url space. Helma lets you map the same object or collection of objects to more than one part of the URL space. There frequently comes a situation where you'll want to generate a link on an html page to a specific object: Say you have a wiki page with a link, and an object representing the page it links to. You'd want to be able to generate the URL to that linked to page on the fly.

Helma provides a function on each object: the href function. This href automatically generates a URL which points at the object that it's called on. So for instance, root.wiki.pages[547].href() may return the url /wikiprogram/wiki/pages/547/. The problem is that an object has no way of knowing which url you want, if it can be accessed by more than one url.

The problem comes when that page 547 is also in another collection. Say, root.wiki.history.pages[547]

Which url should href return? /wikiprogram/wiki/pages/547/ or /wikiprogram/wiki/history/pages/547/ ?

What helma does is pick whichever url that you access the object from *first*, after the application is started, and use that URL henceforth. That is, unless you specify _parent in type.properties.

So, in the page prototype's type.properties file you can add


_parent = root.wiki

and the href function for that object will always return /wikiprogram/wiki/pages/547/

if instead you specify

_parent = root.wiki.history

then the result will always be /wikiprogram/wiki/history/pages/547/

Thus, _parent lets you choose the canonical URL for an object.

The documentation quoted above appears to indicate that _parent can do more than this, but that is something that will have to wait for another post, since I have not yet deduced what that is.