A car and a person?

Surprisingly the blob on the right is identical to the one on the left after a 90deg rotation.

In the absence of enough information of object's identity one search for contextual evidence to force fitting categorization with respect to the world regularities.

As we seen before in this blog, the contextual cognitive module might be unique and it acts as the same for every human task. This is an image processing example, but it could be a natural language processing example.

Even when objects can be identified via intrinsic information, context can simplify the object discrimination by cutting down on the number of object categories, scales and positions that need to be considered.

http://people.csail.mit.edu/torralba/IJCVobj.pdf

Help wanted: Open sourcing a slipnet viewer

(This page will be updated with further details as soon as soon as possible)
Hello world!

After reading this fantastic book and playing with this, I think one good way to proceed is to open-source some parts of a FARG framework which are not its core, but are extremely useful and everyone could benefit from them.

I'm thinking first about a slipnet viewer. A java class that receives a list of nodes and links, and creates a nice view of the ongoing slipnet at any point in time. A node might consist of its activation levels and a bitmap to display inside the node (sometimes we may want to display something other than a string), while a link might include just the nodes it connects, (perhaps) a direction, and a string (to show up distances and for those with IS-A beliefs).

The class would get this information and create another bitmap, now with a beautiful view of the current slipnet: close nodes appear close to each other, distant nodes appear distant, and their activity levels are displayed. From my past life in combinatorial optimization, I have a hunch that this is NP-hard, so we may be resorting to some heuristic that works.

It should be in java, to run in everybody's machine, and also because everyone knows java and could either make a call to it from their own weirdo language or rewrite the code for their project.

In this initial stage, no windows or anything fancy should be done. Just get the data in and output a bitmap with the slipnet. But if our collaboration works, we could go bigger, triggering a window in a new thread and having a great display running in true parallel style. That would, I think, be a first step that everyone would benefit from.

This is small stuff, of course, but it's annoying to redo it everyday in every single project. It takes some time to do, and distracts from the core issues. Our productivity will rise. So, as Micheal Roberts once said, instead of having "obsessive geniuses" working under the basement, we should finally stop doing the same things over and over again. We should finally start collaborating like a small research group.

Or like a start-up company.

What is a relation?

Each relation has some elements, each element usually has a role within that relation. Moreover, there is a function, which takes this elements and creates new elements. A relation finds items of certain kinds (their roles), and creates other items of certain kinds, maybe even with a particular value

For example, in NUMBO:
Multiplication: item1 (operand) item2 (operand) item3 (result)

COPYCAT:
SUCESSOR: item1 (letter_value) item2 (Letter_Value) Alphabetic_Distance(Item1,Item2)=1 (number);

CHESS: Attack: item1(piece) item2(piece) move_distance(item1,item2)=1(number) (attacker in item1) (attacked in item2)

This is why I've found the quote from DeMorgan so sinister.

That's some massively parallel temperature right there, Dude!

I've been thinking about massively parallel FARG, distributed temperature, and distributed coderacks:

Now, whenever a codelet is about to change something up, why add it to the global, central, unique, coderack? I don’t see a good reason here, besides the “that’s what we’ve always done” one. If a codelet is about to change some structures in STM, why not have (i) a list (or a set, or a collection, etc.) of structures under question & (ii) create a list-subordinated coderack on the fly? Instead of throwing codelets into a central repository, they go directly to the places in which they were deemed necessary. There are multiple repositories for codelets, multiple coderacks.

I argued that I liked the idea because (i) it enables parallelism of the true variety, (ii) it helps us to solve the stale codelets issue, and (iii) programming can (in principle) be done gradually, still in simulated parallel.

Now, I was wrong about temperature all along. Here's a new idea:

Imagine that each of the coderacks has the following behavior: Get a RANDOM codelet, then run it.

That's massively parallel temperature right there. Have a nice day. Thanks for stopping by.

Unconvinced? Think about this: some coderacks will start to become really small (as Abhijit pointed out in the comments previously), with one or two codelets, then being emptied and destroyed. That means that at that particular point (or thing) in STM, temperature is really low. However, other coderacks will be full of stuff waiting to run; which means that there, temperature is running high. Distributed temperature with high randomness in hot spots, low randomness in cool spots.

Maybe this has to be coupled with some information about concepts, but I'm not sure anymore. I think that it just might be one of those wonderful, marvelous, emergent effects we take so much pleasure in playing with.

Three types of connotations

I believe, and this is a central aspect of development in the Human Intuition Project Framework, that there are three types of connotations: properties, relations, and chunks.

A property is anything that has a value. It could be a numerical value, a name, or anything else.

A chunk is a mental object, holding stuff together. Any mental object is a chunk.

Finally, a relation maps from a set of (properties, chunks, and relations) to create new properties, chunks, or relations. It is very much like the term used in mathematical relations. And this quote from Augustus DeMorgan, mixing psychology and mathematics, is just eerie to my ears:

"When two objects, qualities, classes, or attributes, viewed together by the mind, are seen under some connexion, that connexion is called a relation."

Massively parallel codelets?

Some of the things I've been thinking about concern this question: how to make FARG massively parallel? I've written about parallel temperature, and here I'd like to ask readers to consider parallel coderacks.

Like temperature, the coderack is another global, central, structure. While it only models what would happen in a massively parallel minds, it does constrain us from a more natural, really parallel, model. Though I'm not coding this right now, I think my sketched solution might even help the stale codelet problem Abhijit mentioned:

We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may refer to some structure in the workspace. While the codelet is awaiting its turn to run, this workspace structure may be destroyed. At the very least, we need code to recognize stale codelets to prevent them from running.

Consider that most codelets fit into one of three kinds: (i) they can propose something to be created/destroyed, (ii) they can evaluate the quality of such change, and (iii) they can actually carry it out.

Now, whenever a codelet is about to change something up, why add it to the global, central, unique, coderack? I don't see a good reason here, besides the "that's what we've always done" one. If a codelet is about to change some structures in STM, why not have (i) a list (or a set, or a collection, etc.) of structures under question & (ii) create a list-subordinated coderack on the fly? Instead of throwing codelets into a central repository, they go directly to the places in which they were deemed necessary in the first place.

Why do I like this idea? First, because it enables parallelism of the true variety. Each of these STM-structure-lists-bound coderacks can be running in their own thread. Moreover, it helps us to solve the stale codelets issue, by simply destroying the coderack when something needed inside the lists is gone. If a structure is destroyed, and a codelet was waiting to work on it, the codelet--in fact all the coderacks associated with the structure--can go.

(I don't know when I'll be able to try this idea out, but hopefully soon.)

Does that make any sense?

A burst of FARG activity

Last week saw an immense burst of FARG activity. A new blog has been set up, as have other initiatives. It seems that Michael Roberts is now officially developing a Framework (and applying it to Copycat). More as story unfolds.

Top-down AND bottom-up thinkodynamics

If something, anything, is "thinkable", then it is bottom-up; it can be seen or felt and change mental context (e.g., alter contents on the slipnet).

And anything thinkable, however abstract, can also be imagined--thus it also exerts top-down pressure.

A small thought for man, a big leap for FARG computational modeling.

Essence and Accident: Convergence to Michael Roberts' ideas

Take a look at a dolphin and a shark and think about convergent evolution.

I've of course read a bunch of times Michael Robert's ideas on a FARG core engine, encapsulating the essential from the accidental in a domain.

But after some email exchanges, I'm stunned to see that many of the ideas we're proposing on this website had also been in his vision. Which brings up the question:

Is it convergence? Are we both right to pose (i) domain-free codelets, (ii) distributed temperature, (iii) slipnet nodes with structure? Are we converging to the same ideas because these are, in a sense, the right ideas?

Or have crimes been committed? Have I simply stolen his blueprints and am now, years later, claiming that I've stumbled into them, and just feel like they're mine because time has passed and when I went back to the drawing board all I could see was what was already in my mind?

Under the advice of my prestigious law firm of Cravath, Swaine & Moore LLP, I plead not guilty.

First, I couldn't understand details of Michael's ideas back then. I had to study a lot of design patterns along the way in order to see a new kind of flexibility in software, and the full meaning of encapsulation and polymorphism. Years, later, having developed Capyblanca to a certain extent, I can appreciate the difficulties inherent in separating essence from accident in FARG. With this baggage I've stumbled upon so many similar ideas, like distributed temperature. He argues for distributed temperature, but he doesn´t mention explicitly why. And many of his and mine ideas are still a little bit different. (I've yet to convince him of connotation thing, if he doesn't grasp its reasons quite immediately.)

I seriously think this has been the product of convergent evolution. Which makes me optimistic.

We're on the right track.

What if codelets are only bossing around?

What if codelets are only bossing and bitching around?

I mean, from what I get from all the code I've seen in so many projects, codelets actually do things. They work directly on representations. Sometimes they scout STM for something to be created; sometimes they build some stuff out there; sometimes they trigger other codelets, etc.

But what if they only sent signals? What if they only were bossing around?

This is something that the Starcat team has started, but can be done in a deeper way. The advantage of it would be simple: you could encapsulate all codelets, for any domain existing in the universe, and cleanly separate them from the accidental features of your problem.

But here comes Christian's Law, once again: "Language compiles everything".

Back to the compiler.

Damn!

Copycat's codelets, refactored (i)

From Analogy-Making as Perception (By Melanie Mitchell), MIT Press.

Here is Melanie's classification of codelets:

DESCRIPTION BUILDING CODELETS

1. Bottom-up description scout.
2. Top-down description scout.
3. Description strength tester.
4. Description builder.

BOND BUILDING CODELETS

1. Bottom-up bond scout
2. Top-down bond scout (deals with categories, such as successor)
3. Top-down bond scout (deals with direction of strings)
4. Bond-strenght tester
5. Bond Builder

GROUP BUILDING CODELETS

1. Top-down group scout (for categories)
2. Top-down group scout (for direction)
3. Group-string scout
4. Group strength tester
5. Group builder

CORRESPONDENCE BUILDING CODELETS

1. Bottom-up correspondence scout
2. Important-object correspondence scout
3. Correspondence strength tester
4. Correspondence builder

RULE BUILDING CODELETS

1. Rule scout
2. Rule Strength tester
3. Rule Builder
4. Rule Translator

OTHER CODELETS

1. Replacement finder
2. Breaker

24 codelets in all. Interesting. Not so many.

I wonder how we could use polymorphism to reduce duplicate code and enable the separation of essence from accident.

For example, take the codelet groups:

DESCRIPTION BUILDING CODELETS
BOND BUILDING CODELETS
GROUP BUILDING CODELETS
CORRESPONDENCE BUILDING CODELETS
RULE BUILDING CODELETS

Each of these groups have a number of different codelets. But look again, and a clear pattern emerges: Each of the groups has scouts, has testers, and has builders. (Also, scouts are either bottom-up or top-down.) I can't convince myself that there isn't another, better, way to design this than by programming each one individually.

We have to separate FARG essence from copycat's letter-string's accidental features. And, in the way towards that road, we will stumble upon general codelets: the holy grail. Codelets that are general enough to work on any domain; codelets that follow the principle of closed for modification, and open for extension. If we can finish this design in this first semester, that will be a powerful moment.

Semantic web dreams and a strategy for Yahoo!

From a cognitive science perspective, the semantic web is still years and years and years away--at least a full decade. What I mean is the set of complex mechanisms that involve creating meaning, not the usual ridicule hyperbole out there.

Consider, for example the fact that when the TAM flight crashed in SP last July, the news were full of contextual ads suggesting readers to "Fly TAM".

Or maybe take a look of these contextual ads (hat tip to Digg):



The best ideas over this issue are by Bob French--though he doesn't particularly address 'contextual ads'--but the whole problem of meaning extraction from text databases in which semantic web engineers are falling upon. This paper is one of the funniest, and most intelligent, things I've ever read.

The "long tail" will always be algorithmic. The "fat head" will always be mainstream. The "middle ground" will be social. This naturally suggest a strategy for Yahoo! (which TechCrunch says is failing--and it just might be).

Yahoo! isn't mainstream media, nor algorithmic (like Google). From this point of view, I think what they should do becomes clear: They should strive to dominate the middle space.

Yahoo! should go beyond del.icio.us and acquire digg. It should subordinate all of its strategy to having all content, including ads, brought up by social voting. If an ad is buried, let it go; just like every piece of content. In the short-run, most likely, only ads from Apple or Ron Paul will appear; in the long-run, only good, socially targeted content should arise.

Meanwhile, algorithmic contextual ads will keep suggesting to stone people to death, to find debt, and to burn babies.

Some thoughts on Temperature

Intrinsic to FARG architectures is the notion of temperature. From John Rehling's thesis:

"All of the three modules and the Letter Spirit loop incorporate, each in its own way, temperature – a means of modulating the randomness of behavior – or something very much like it. The Letter Spirit loop, for instance, decreases the amount that style influences the Drafter's attempts at rendering a particular letter category when it has already undergone several attempts at drafting without the Examiner having recognized them as members of the intended letter category. It also turns up the amount of randomness in drafting as a run goes on, under the premise that novel letterforms are more useful at that point than good ones that had been drafted previously. In all of its guises, the use of temperature employs the principle encapsulated by the phrase "desperate times call for desperate measures"—a principle seen at work in many kinds of human behavior." (Rehling p.346-347)

While I do love the notion, I am not satisfied with current implementations.

We know the mind is massively distributed. Imagine, in the future, Fluid Concept architectures running in thousands of processors. It is with this in mind that your blogger asks you to follow his wild speculations.

Today, temperature is implemented as a central variable that the whole system depends upon. As an appetizer, ask yourself: Is this sustainable for a massively parallel future? Do our brains have a central floating point number to access the state of entropy in any given situation? That's highly unlikely, I think.

Now for the main course: how can we change this? How can we turn a single, central, variable, into massively distributed stuff? I'm going to speculate here, but I think that this can be implemented fairly easily, and perhaps by the end of 2008 we can have some running examples.

How does temperature work? It both measures the state of coherence (or, to flip it, the state of disorder), and feeds back that information, so that the system may "behave" itself or go "balooney".

By behaving itself, I mean, of course, that the system should remain concentrated in the most promising ideas. It should ignore most possibilities. If temperature is low, that means that a coherent global view is coming into shape, and we don't want to mess it up by destroying work done--which inevitably happens if a "new" idea comes up.

By going balooney, I mean that the system has not yet figured out what to do. It has not yet built in STM structures that represent, in any cogent way, what the situation is like. Any node in the slipnet is welcome to become as agitated as it wants.

Now, how can that be massively distributed?

Here's a hunch.

What if, during a run, the system is able to track codelets that are destroying previously built structure? If the nodes that are creating and destroying stuff can be tracked by STM chunks, then what about creating, temporarily, "inhibitor" links in the slipnet nodes responsible for the creation and destruction of the structure in question?

With these mechanisms in place, I think they can be managed to gradually increase inhibition between competing worldviews.

After some time, with high enough inhibition, we would have "clusters" of self-reinforcing nodes, and these clusters should inhibit other competing clusters. The emergent behavior should in principle be just like the impact of a lowered temperature. "New", unwanted ideas should rarely creep into the party.

If the system gets stuck on a snag, then it could try moving to another cluster. But how would it find out that it is stuck, without having temperature (a centralized variable), to tell it that "this is probably not the best idea concerning our current situation"?

The structures built, since they would be tracking (some) activity in the slipnet, might become more and more dissatisfied with the top-down "orders" they are receiving. At one point, they might send a message to "shut-up", and bring activation of such node to zero. Maybe also this zero activation might spread to (the cluster's) associated nodes, or maybe even it could flow directly to the inhibited nodes. Perhaps the inhibited nodes (who were dying out) could be instantly activated by such triggering. This could make the system rapidly jump between competing worldviews, rather like our perception of Necker cubes or the Vases/Faces illusion.

Of course, as Christian says, language compiles everything. It may be very tricky to get this working. I do, however, think that it would (coupled with other new ideas) enable massive parallelism (on the tech side), and, more than that, reflect the distributed nature of our own information-processing (on the scientific side). Perhaps this may be one of the right moves in turning that Rubik's cube.

(more than ever, comments very welcome)

The Mystical "AS-A" relationship

It's fair to say that object-oriented languages presuppose metaphysical realism; that is, a world composed with objects, properties, and relations, independent of any understanding. OO-goodness instantly provides the IS-A relationship (by inheritance), and the HAS-A relationship (an object with other objects as properties). It does not, however, provide the much needed "AS-A" relationship. This is to me, the single greatest reason for the failure of AI and Cognitive Science.

There are so many different examples of seeing one thing in terms of others; just use language and they will come up by the thousands. To take one example I've mentioned earlier:

Take the iPod mp3 player--it is a hit product that "saved Apple Computer". On the day the first iPod was announced, people did not have the category "iPod" in their minds, so they had to resort to previous categories... making all kinds of analogies you can imagine. In fact, I decided to collect some analogies on the iPod, to use someday in a paper in Marketing. Here are some [taken from real people debating on the web]:

THE iPod can be seen...
"as a mobile phone" [future prospect]
"as a canvas for expression"
"as a bootable drive"
"as a security threat"
[video iPod] "as a marketing tool"
"as a data repository"
"as a unit of measure" [believe it or not: in terms of money, height, and so on; e.g., how many iPods to circle the Earth?]
"as key for security"
"as a platform" [such as the Solaris platform]
"as a legislative force"
"as an Ebook"
"as a presentation device"
"as a business tool"
"as a phone phreaking device"
"as a portable DVD player"
"as a learning tool"

Crazy, right? But that's perception at it's core... understanding something in terms of other, better understood things.

I think that we have nailed this one--though I can't disclose the solution until we have a full paper. I think we really nailed it. But a blog is not an outlet for this discussion--and it may have implications, not only for cognitive models, but for programming languages also. We are building a first implementation, and I hope to post a link to the papers as soon as they are born.

And the best part? It's not complex as it seems. It's simple. Sometimes you have to go through an immense amount of complexity in order to find something that's crystal-clear and dead simple. It's simple, and it is beautiful.

The Starcat project: a thought

The Starcat project is an intriguing project being developed at San Diego State University. It's hard to distill exactly what they are doing, or how (most papers are short, and they have numerous different application areas, but there are two which are not), but one idea strikes my as fantastic.

They have decoupled the slipnet (long-term memory), the workspace (short-term memory), and the coderack. They are using patterns of observers, and there is a mediator between these systems that takes care of their interactions.

One thing that I have some objections to is the idea of having "codelet events carry[ing] the necessary instructions to drive the system" in each of its now-decoupled subsystems. I cannot argue vigorously against this yet, but I envision "general" codelets which will be applicable to any domain. Until we can get these general codelets running in a system, it stays as a hunch. And even then, their idea may be complementary to ours (we just don't know yet). As strange as it may sound, I think that a fixed set of codelets should exist, in any domain. Of course, the accidental characteristics of each domain will still need to be programmed, but I feel that responsibility won't be placed on the codelets.

And here's what I find it fascinating: first, these subsystems can be implemented in parallel. Moreover, a change in the code of one of the system should not introduce bugs (the cognitive model may go haywire, of course, but it should still work as a program). The systems are encapsulated, and you can study and manipulate them in isolation from each other. I find this idea fascinating, and Kudos to their team!

Essence and accident

Quoting from "the success of open source", by Steven Weber, Harvard University Press, 2004, p. 57:

[Software engineer Fred Brooks once] wrote a paper entitled "No silver bullet: essence and accidents of software engineering".

Brooks use Aristotelian language to separate two kinds of problems in software engineering. Essence is the difficulty inherent in the structure of the problem. Accident includes difficulties that in any particular setting go along with the production of software, or mistakes that happen but are not inherent to the nature of the task.

One of the goals of The Human Intuition Project is to build a robust framework on which to develop FARG architectures on a much larger and faster scale--or, to use the economist's favorite word, to increase productivity. Brook's distinction is extremely important here. Each project has had its accidental characteristics: NUMBO deals with numbers and operations, Tabletop deals with objects in a dinner table, Phaeaco deals with Bongard problems, Copycat and Metacat deal with letter strings, Letter Spirit deals with font styles, Capyblanca deals with chess, newcoming projects handle music sequences, number sequences, and so forth.

All of these projects have a shared essence; a shared set of ideas employed to create the system. And all of them have accidental characteristics to deal with. If we are successful, then two things will happen: designers of new computational models will be able to concentrate attention to the accidental features of the problem; and, more importantly, we will be able to concentrate on the essential features of human cognition in separation from the accidental features of any particular domain. If we all agree on the same set of ideas, it should be a non-brainer to encapsulate them and have them outside any particular domain and its accidental characteristics.

In search of productivity gains

It's January 2008, we wish you all a great new year, but first and foremost we wish ourselves a great new year. We do have big plans for the year. One such goal is to improve productivity in developing FARG models by a large factor, perhaps 10 times easier. If Capyblanca took 5 years to develop, and it's still with its rough edges, a major new rewrite based on the framework codebase should take 5x12 months div 10, which equals 6 months, which seems about right.

Note that there is only one problem here.

Like honest man, calm women, and fire-breathing dragons, that codebase does not exist.

But we have a vision for it, and the vision is beautiful. It's as elegant as Giselle on Armani. I think some words of explanation are needed here: Why is it beautiful? And why is that important?

It's closed for modification and open for extension. Which means two things; first, we'll have basic FARG functionality provided, for free, with no need to deal with it's internals (slipnets, codelets, temperature, coderack, maybe even hedonic feedback regulation will make it to v. 1.0). Our evolving system is based on the notion of connotations. And the idea of connotation explosion is explored in full. All you should need to do to create a new FARG system is to develop the right connotations. For Copycat, that might be, "Letter B", "First", "three", "Sameness group", "Sucessorship Group", "opposite", and so on. Write some code for these, and the system should run, beautifully.

If that ever happens, and the codebase is robust (i.e., it accepts other, new, domains, without having to rewrite its internals), then that codebase should be getting closer and closer to the truth. That being something the likes of figure 49 of Harry's thesis--note, as an aside, that in the paper I've linked here I think that Harry underestimates Jeff Hawkins.

But it is beautiful, also, because it employs recursion, symmetry, polymorphism, in such new, very new, ways. I think even people interested in programming languages might be interested in seeing what we are coming up with. It has some repercussions in that arena. But that's only for when we have a good, solid working model. So our first task for this year is to delve on hedonic feedback and autoregulatory learning (i.e., autoprogramming), and a connotation transfer-based form of programming. After we have some reports on these, we should be able to enjoy large gains in productivity.

And as any economist will tell you, a productivity gain is one of the greatest things you can ever achieve in your endeavors. Large productivity gains change everything. There were cars before Henry Ford, and there was such as thing as a "world-wide web" before Netscape. But those brought productivity gains, changing "the curve of the curve". This is what FARG needs. So here's some reasoning for optimism, in spite of the ugly economic downturns ahead:

1. FARG changes everything; with it we have a scientific model, and an agenda, for understanding what understanding itself is all about.
2. BUT FARG is hard to implement. Very hard to build. Nasty problems abound.
3. A large productivity gain in FARG development could help bring massive change in this second point; and
4. If that gain comes through a solid codebase, the though constrains imposed on the codebase to reflect human cognition should, in the long run, provide a better perspective towards a full theory of human high-level cognition.

So there it is. Have a great 2008! As a general policy, it's always better to start a year with ambitious, optimistic dreams, and leave the screwing up for later, on the coming months.

Wrapping up our course; and preparing for 2008

| View | Upload your own

Largest island in a lake on an island in a lake on an island

Talk about some recursion.
Since chunking mechanisms use a lot of recursion, perhaps we may want to start a class on them by visiting the largest island in a lake on an island in a lake on an island.

THIS IS THE ORIGINAL SOURCE, and kudos to them!

(All I've done was mash it up; the credit is all theirs).

~~
Largest island
Greenland

View Larger Map

~~
Largest lake
Caspian Sea (RUS/KAZ/AZE/TKM/IRN)

View Larger Map


~~
Largest lake on an island
Nettilling Lake on Baffin Island (CAN)

View Larger Map

~~
Largest island in a lake
Manitoulin Island in Lake Huron (CAN)

View Larger Map


~~
Largest island in a lake on an island
Pulau Samosir in Danau Toba on Sumatera (INA)

View Larger Map

~~
Largest lake on an island in a lake
Lake Manitou on Manitoulin Island in Lake Huron (CAN)

View Larger Map

~~
Largest lake on an island in a lake on an island
Crater Lake on Vulcano Island in Lake Taal on Luzon (PHI)

View Larger Map

~~
Largest island in a lake on an island in a lake on an island
Vulcan point in Crater Lake on Vulcano Island in Lake Taal on Luzon (PHI)

View Larger Map

Stumbling upon something new

We are turning some good cranks on that Rubik's cube.

From the start of the PhD course we had wanted to publish everything on, the slides, and slidecasts of the whole thing. But at one point these last weeks a real dilemma came up. What we were talking about, and doing, and seeing it run on the screen, was new. Something that most likely has not been done before, and that, if the underlying philosophical premises are correct, might have quite an impact in both computer science and cognitive science.

My mind goes like this: what to do with it? Publish the classes, as the original plan called for? Publish as a series of papers? Get a PhD candidate to work on it and see what's up? Write up a patent? If we're correct than it could potentially have wide applicability.

I think we made an advance on what we've called autoprogramming before. So I'm on Jekyll-and-Hyde mode on this one.

And the thing is... I think there's more. I think that there's another important idea clearing up... something like "concept-oriented programming"... or maybe "encapsulating object encapsulation". Just to give a glimpse of the idea: in language and cognition we use analogy all the time, of course. But how can we say that "that lawyer is a vampire", that "if independent, Quebec will become a small boat in a big storm", or something I said the other day, that "I really hope that Dr "dude" Lisi is a new Einstein. We really need a new Einstein."

In Object-oriented programming, objects have state and interfaces. But in human concepts, we apply the interfaces and properties and relations that belong to one class to almost anything else. A Canadian state becomes a boat, a lawyer becomes a fantastic figure dreamed up in novels, someone becomes an "Einstein".

How can we design classes and objects that reflect this? Even with polymorphism, inheritance and all that OO-goodness, it seems far-fetched. But I think we're stumbling on the answer. And it is beautiful. This week I'm designing the blueprint & requirements, and I hope to have a proof-of-concept (pun intended) by next week.

There's a parallel here with what Garret Lisi says about his work: either our model will be extremely simple and elegant, or it will fail spectacularly. While neither Jekyll nor Hyde wins the fight, we can't say much for now.

In the meantime, feel free to check out the possible theory of everything in the universe below.