Monday, February 25, 2008

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.

Thursday, February 21, 2008

Raging against the machine

He can bring people together, but can he make history?

Wednesday, February 20, 2008

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.

Monday, February 18, 2008

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.

Sunday, February 17, 2008

A new commentary piece in Behavioral and Brain Sciences

Here's a new commentary on a target article, to appear in Behavioral and Brain Sciences. The full piece is available through email.

==
Dynamic sets of potentially interchangeable connotations: A theory of mental objects

Alex Linhares

Abstract: Analogy-making is an ability with which we can abstract from surface similarities and perceive deep, meaningful similarities between different mental objects and situations. I propose that mental objects are dynamically changing sets of potentially interchangeable connotations. Unfortunately, most models of analogy seem devoid of both semantics and relevance-extraction, postulating analogy as a one-to-one mapping devoid of connotation transfer.

Tuesday, February 12, 2008

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!

Monday, February 4, 2008

The internet's backbone

Despite all the talk about Apple and Google, Adobe is the coolest company on earth. With flash, and soon, AIR, they are the backbone of the net. If you want to be stunned and see what they are up to; take a look at these two product lines:

Video. They are moving from low-quality (read: YouTube) videos to high-quality, high-def. In Flash! That is an amazing feat.

Check it out for yourself. Double-click for fullscreen video.

http://www.flashvideofactory.com/test/DEMO720_Heima_H264_500K.html

(Hat tip to an amazing flash video blog).

This is going to have an impact in TV broadcasting in the following years.

If that is not enough, check out Sprout, a new web2.0 company; also using flash, and soon, AIR. It's enormously powerful stuff, and enormously easy to use.

You really have to hand it to those guys. This is beautiful work. They are really changing the curve of the curve.

Sunday, February 3, 2008

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.