In this section, Hofstadter talks mostly about the "Eliza Effect" and relating it to other critically acclaimed programs in the field of artificial intelligence. Hofstadter defines the Eliza Effect as, "The susceptibility of people to read far more understanding than is warranted into strings of symbols - especially words - strung together by computers". In short, this means that people tend to give computers too much credit in terms of it's "intelligence" rather than it's systematic functionality. To a computer, a string is a string, whether that string is a name or a incomprehensible combination of random letters, has no meaning to the computer. This is a misunderstanding that the general public has.
Much of this section is used by Hofstadter to demonstrate that exact point. In particular, Hofstadter uses the ACME program, which received much praise, to demonstrate this. The ACME program takes a set of objects and predicates, and strings them together to create a pattern or "story". Hofstadter makes his point by merely substituting these some of these strings for single letter representations. This makes the resulting pattern look like nothing more than random clutter. While the programs Hofstadter mentions in this section do accomplish something are deserve some credit, this Eliza Effect gave way to them being viewed as something much greater than they really are.
Wednesday, October 28, 2009
Monday, October 5, 2009
The Numerical Jumbo - Numbo
In this section, Hofstadter introduces another project which he calls 'Numbo". To put it simply, this is a combination of Hofstadter's Jumbo project and the crypto problems we have been working on. However, there are two differences between Numbo problems and crypto problems. The first one is that only addition, subtraction, and multiplication may be used. There is no division unlike in crypto. The second is that every number, or brick, may be used either 0 or 1 times to get the solution, unlike crypto where each number has to be used once.
While the game of Numbo works almost identical to crypto, the program itself seems as if it will work very similarly to Jumbo. The only noticeable difference I recognized thus far, is that Numbo will use a combination of both bottom-up and top-down approaches than Jumbo. Similar to Jumbo, Numbo will use landmarks and other techniques to build "gloms" from the ground up to find the solution. These landmarks are merely just numerical versions of common syllables used in Jumbo.
The main difference between Numbo and Jumbo besides the obvious, is that Numbo will have to be much more random in its search to find some solutions. For example, in Puzzle #6 (Target: 146, Bricks: 12,2,5,7,18), Hofstadter suggests finding a way to make 12*12 to get 144 as a landmark. While this is the way Hofstadter suggests, there are many other ways that a user may realistically take to get the result. In short, Numbo seems like it will have to be much more random in the ways it tries to get a solution to compensate for the many different ways any single user may take.
While the game of Numbo works almost identical to crypto, the program itself seems as if it will work very similarly to Jumbo. The only noticeable difference I recognized thus far, is that Numbo will use a combination of both bottom-up and top-down approaches than Jumbo. Similar to Jumbo, Numbo will use landmarks and other techniques to build "gloms" from the ground up to find the solution. These landmarks are merely just numerical versions of common syllables used in Jumbo.
The main difference between Numbo and Jumbo besides the obvious, is that Numbo will have to be much more random in its search to find some solutions. For example, in Puzzle #6 (Target: 146, Bricks: 12,2,5,7,18), Hofstadter suggests finding a way to make 12*12 to get 144 as a landmark. While this is the way Hofstadter suggests, there are many other ways that a user may realistically take to get the result. In short, Numbo seems like it will have to be much more random in the ways it tries to get a solution to compensate for the many different ways any single user may take.
Wednesday, September 30, 2009
How Jumbo Works
In this section, Hofstadter talks in detail about how the process of how Jumbo works. In the previous section, Hofstadter just talked about the process of building different "gloms" to form a word. This time around, however, Hofstadter talks about how these gloms get built and are judged.
Hofstadter uses the term "happiness" and "temperature" to determine the likelihood that these gloms are building towards a viable answer. I find this as a very interesting idea and would be curious to find out what type of algorithms Hofstadter uses to determine the "happiness" of a glom. While these ideas are very easy and simple to understand in abstract, they seem like they would be extremely complex when it comes to coding this gauge.
Hofstadter also talks about how if a glom has a low happiness, it is "undone" by going step by step backwards looking for different possible branches it may have taken. This too seems like a simple idea in principle, but a complicated one in implementation. I would be very interested to see just how Jumbo would decipher "pang-loss", "pong-lass", and "pan-gloss" all to have different "temperatures". Overall this whole project sounds like one that is simple to explain in theory, but a very difficult task to convert from theory to code; more so than any other program I have seen before most likely.
Hofstadter uses the term "happiness" and "temperature" to determine the likelihood that these gloms are building towards a viable answer. I find this as a very interesting idea and would be curious to find out what type of algorithms Hofstadter uses to determine the "happiness" of a glom. While these ideas are very easy and simple to understand in abstract, they seem like they would be extremely complex when it comes to coding this gauge.
Hofstadter also talks about how if a glom has a low happiness, it is "undone" by going step by step backwards looking for different possible branches it may have taken. This too seems like a simple idea in principle, but a complicated one in implementation. I would be very interested to see just how Jumbo would decipher "pang-loss", "pong-lass", and "pan-gloss" all to have different "temperatures". Overall this whole project sounds like one that is simple to explain in theory, but a very difficult task to convert from theory to code; more so than any other program I have seen before most likely.
Subscribe to:
Posts (Atom)