Jumbo and results

This section of reading, in its entirety, is a good illustration of Hofstadter’s earlier statement regarding the two divisions of programming. That is, there’s programming for results and then programming in respect to modeling processes. (More or less, if nothing else, the reference is there and this is how I understood his statement.) I’m hesitant to say that though, because it makes programming intended to model some process sound less useful in terms of getting actual results. I’m not sure if there’s really a rift here or if I’m just thinking there’s one because the difference was expressed.

That said, the descriptions of the processes applied by Jumbo are quite poetic. It’s hard not to appreciate the way it works. I wish I could actually see the code for it. Regardless, I think that the whole thing would be an interesting concept to apply to other problems. If nothing else, I’m interested in playing with some of the concepts myself. To clear up some of the vagaries here, I’m talking about the idea of individual chunks of data having “preference” as to which other things they’re glommed with. Off the top of my head, I’m not entirely sure what other sorts of data you can apply this to.

On a total side note, I’d be interested to see the sort of thing Jumbo does be applied to other languages with separate rules. Can you make a framework that accepts some table of preferences for the individual characters and then lead it to construct actual pseudo-words? What about the languages that don’t use things similar to our idea of an alphabet? (Chinese/Japanese?)

I must think more on this.

spatial manipulation

Funny thing we should be reading about anagrams.

The ability to rearrange mental objects is important for us. Is this a core part of our ability to problem solve? This topic is somewhat familiar to me in regards to computer science. I tend to draw, when confronted with some arbitrary project assignment, lots of directed graphs to illustrate the interrelationships of different modules. This, of course, goes hand in hand with manipulating them mentally. Drawing them in a procedural way helps simplify and perhaps impose some order on the mental juggling. (I probably don’t realize now exactly how many little example trees I scribbled in my notebook when I had to write my first B-Tree.) Sometimes it can be revealing if two people share their own directed graphs; the differences in perspective can help solve or convey the solution to the problem.

In any case, maybe this goes back to the conceptual spheres from last time. Why does visualizing things in some spatial sense help us understand relations? Words have a simple spatial component. Then there are path-finding problems which obviously rely on spatial skills. We seem to encounter this problem all the time and we manage to solve it reflexively in most cases. This is a bit removed from how Hofstadter described the tossing up and rearrangement of letters though. The striking point with that idea is that it comes to us so naturally. So naturally its overlooked most of the time. Its just not one of those things you usually think about and its hard to catch in the first place if you’re not looking for it.

visualization

This section discusses variation, among other things. There’s this idea of conceptual spheres somewhere in variation that, I think, does a great job of modeling variation if tracked from a source. Distance from the center of any particular sphere indicates deviation, and distance towards something may stand for variation with another sphere in mind. This is… variation with respect to another idea. Hofstadter kind of illustrates this in the text by bringing one of his number sequences full-circle, ending up with something similar to one of the initial squares and triangles derivations.

Some other ideas that come to mind with the idea of conceptual spheres is the abstract space they reside in. The term itself got me to think of three dimensional space (If this relation wasn’t intended from the start.). Visualize some different conceptual “spheres”. How far apart are they? What does the distance represent? Do they overlap? When does something, when moving from one sphere to another by way of variation, start appearing more like one thing than another? Do the spheres have boundaries? ( … in reference to Hofstadter’s blurry line between ideas.) Think of bringing new ideas into this space. One concept can overlap an infinite amount of others and connect previously unrelated things. (Maybe change other places between spheres or concepts permanently. Does this describe a large change in perspective for the individual?) If you can add spheres, can you take them away?

Maybe I’m too far off topic or have taken a simple term far too literally. Its fun stuff to think about in any case. :)

malleability and self modification

So far I probably sound a little one sided. I’ve only commented on metacognition’s effect on computing. I find this particularly interesting because I am a programmer. Focusing on computation as a topic in cognitive science can have a pretty big impact on your perception of code and the process of creating software. Hofstadter mentions this in previous sections: the difference between constructing an algorithm or a program for results versus one to illustrate abstract questions. Each viewpoint seems to, in some way, go against the others. That is, programming with or without thinking about the way a human goes about it, programming for results, programming (or attempting to program) intelligence, etc.

I guess you can’t have the best of all of the methods very easily, if at all.

Hofstadter talks about the inflexibility of programs or instructions in programs. Hard coded determinism is a difficult medium with which to describe a mental process. He mentions constructing templates which are flexible or modifiable. This reminded me of the idea of self modifying code (SMC?). I can’t say I’m particularly knowledgeable about the subject, but it does bring to mind some ideas. It’d be incredibly dangerous if code were just allowed to be modified anywhere on the fly, of course. Think of it in the terms Hofstadter puts it though – with regards to templates. Malleability is key in representing the mind I think. This seems to be a fundamental sort of flaw in converting between fluid things like thoughts and some rigid, procedural sort of thing like a program. Hofstadter, in this section, continues to point out the difficulties in translating exactly how we evaluate a sequence into the applicable computing concepts. This problem seems similar in some way to natural language translation. There are always concepts that don’t carry over well. Some have to be modified (heavily) before being transferred to the target language. Others just don’t work at all.

Knowledge and Traps

It seems to be the case more and more that, in a programming context, people go the knowledge route versus thinking about the actual processes involved just a bit more. Quantity over quality perhaps? But then, its exceedingly easy to get carried away and miss the big picture so to speak when it comes to these sorts of things.

A great deal of people notice these things in retrospect but then of course its somewhat too late. As before though, one benefits from well documented processes. The author makes note that there is more to be gained from notes that detail the processes rather than the steps to the solution. And what isn't better in drafts? The first attempt at anything, even pattern recognition algorithms should provide valuable insights to the process.

It seems to be difficult to program in a general sort of way. That is. with thought processes in mind. Most programming goals are mundane in that they lack much usefulness outside of a specific application. This tailor-made approach, however, might have its place with the compartmentalized view of the mind in some disciplines. The idea of modularization in computing and the mind seem somehow similar.

So, with this, one should ultimately be able to improve programs that attempt to do things we can do with some thought about ourselves. I'm not personally sure how much thought is given to this while people think about different algorithms to use. It only makes sense that everyone that produces code should think about it. The machine's strengths are somewhat obvious when compared to us, I think. So the idea seems to be to use the machine's positive characteristics and imprint our own methods on it – even if only partially. Now heres the question of usefulness with expert systems versus those who are not knowledge based. Is the question actually “Which is better: to know vast amounts or to be able to learn?”

Turning thoughts against themselves

Number sequences have an appeal, of course, because of the natural ability for humans to recognize patterns. More useful perhaps than just the ability to recognize patterns is the act of thinking about those processes and separating them from another. Does metacognition give an individual more control over a process simply by being aware of it, perhaps? Beyond that, this seems a fantastic way to apply concepts to computers. Emulation of natural phenomenon, particularly of the mind, tends to be a sure fire way to approach most problems computationally.

If you think about this borrowing process from a perspective that considers evolution – why not engage in mimicry? There are thousands of years of trial and error backing the method up, so it ought to be pretty good. Of course that's not saying that there wont be a better method out there, but in general, translating a natural process for a program will result in something that's functional at the very least.

In the case of a game program, for example, this results in a bit of irony. One could assume that at some point someone had to sit and think about the processes that go on in our heads when someone plays chess. This ends up being turned against a human of course, and so we're playing with machines pretending to do things as we do. But then, thats the whole point anyway. We're challenged by something thats imitating us... on some constrained playing field, on our terms. So theres quite a bit to take into account in mirroring just one facet of our cognitive ability.

And so it seems that understanding the process is greater than simply finding the solution. Its the path to the solution and the solution itself. Teaching a machine to recognize patterns isn't as important as figuring out how exactly we do it. The former couldn't properly exist for us without the latter. So in this regard, the challenge is only partially complete once a solution is found. Then we turn our thoughts to ourselves for better understanding.