You know those little plastic tree-like structures left over when you're done building a model? They're called runners - part of the injection molding process and basically a waste. For most products, the factory recycles runners as the parts are detached, but for models they are left on to make live easier for the builder. Well, some folks over at ummmm....a place in Japan, took a boat-load of these runners and made a 3-meter tall Gundam. Check it out! And the video.

On Wed, Sep 1, 2010 at 11:51 AM, Mike Tintner <tintner@blueyonder.co.uk>wrote:

> [I was a bit surprised that Hofstadter thinks some of this]:
>
> An Interview with Douglas R. Hofstadter, following ''I am a Strange Loop''
> Reviewed by Tal Cohen Wednesday, 11 June 2008
>
>
I found it easier to read this interview with the formatting on this web
page:

http://tal.forum2.org/hofstadter_interview

-Philip

                           

During filming for the Transformers 3 movie, a stunt went terribly wrong and an extra was injured. The accident involved several vehicles with an object going through a windshield hitting the driver resulting in a serious head injury. Filming was taking place in Hammond in northwestern Indiana. Several videos exist of the movie shooting in Chicago on Youtube, along with some funny trailers. Transformers 3 is scheduled for a July 2011 release.

I think I came up with a way to do it...

I've been trying to find software tools that will give me the flexibility to
just jot down ideas quickly, animate as necessary, even do some simulation
and such. I took a look at visio, but it is very unintuitive, slow and a bit
inflexible. It's just not fast and friendly enough for my purposes. Plus
it's missing a whole bunch of functionality, such as the ability to animate.


So, the requirements I need in the software is a very tall order! I don't
even know everything I want to do yet.

So, I realized that the perfect tool may be visual studio, which I love
anyway. Visual Studio allows you to create visual interfaces for programs.
But, the cool thing is that I can also use it to create workflows... or
animate, or I could build in detail links, etc. I mean, it is everything I
need. Plus, I already am very familiar with visual studio and C#. I can make
it so that it allows me to create multiple levels of the design. So that
when you click dive into a section of the design it can go into more detail
and simulate sub components. etc.

So, I think this is how I'm going to build the Pseudo Simulations and Pseudo
AGI design.

Dave

On Thu, Sep 2, 2010 at 9:08 AM, David Jones <davidhere40@gmail.com> wrote:

> Abram,
>
> What I mean is rough to fine design of an AGI. Instead of implementing it
> as you work out the details of the design, which is what people currently
> do, you create a fake simulation.... which is an animation. The reason it is
> fake is that it is a simplification of the real process and you have to make
> more assumptions than you might in an actual simulation.
>
> Here is a great example: http://www.youtube.com/watch?v=xbJ0nbzt5Kw&NR=1
>
> This animation is really, really cool. Imagine if you could show how your
> AGI design works at a level of detail that was so convincing that it would
> be very hard for people to deny. I think this is a great way to accomplish
> that. Implementation requires too much detailed work and man power, but a
> pseudo simulation could get close enough to show that it would work without
> actually implementing it.
>
> This is similar to how you might write pseudo programming code. But, AGI is
> too complicated to solve the problem with pseudo code such as that alone.
> So, we also need pseudo test data and pseudo simulation of the algorithms on
> that data. You could take real data and convert it to a pseudo form that the
> simulation could work with.
>
> The major difference here is that when you try to implement something, you
> waste time on the details of flawed designs. If we were to work out the
> higher level details ahead of time and show that the design wouldn't work
> sooner rather than later, we wouldn't have the problems we have now. We
> should be sure about each level of design as we develop from rough to fine.
> This saves us time because we don't have to declare a project a failure
> after 10 years of effort. I mean look at CYC! 26 years and counting! We
> would have been much better off just analyzing it for a year and showing
> that it really doesn't do what we want it to do. But, no.... people are in
> too big of a hurry to implement before fully justifying the "solution".
> Until we do something about this, we will continue to fail over and over and
> over again. In fact, I will predict that all existing AGI projects will fail
> to get anywhere near what they want without *drastic* changes that will
> throw out most of their previous work. They'll do little better than
> existing narrow methods could do. Why? Because their designs are
> unjustified.
>
> Dave
>
>
> On Wed, Sep 1, 2010 at 6:36 PM, Abram Demski <abramdemski@gmail.com>wrote:
>
>> David,
>>
>> It is not entirely clear what you mean by pseudo design or pseudo
>> simulation. Can you be more specific? Perhaps a semi-formal definition?
>>
>> --Abram
>>
>> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com>wrote:
>>
>>> I've been to think lately that the solution to creating a realistic AGI
>>> design is psuedo design. What do I mean? Not simulation... not practical
>>> applications... not extremely detailed implementations. The design would
>>> start at a high level and go deeper into detail as possible.
>>>
>>> So, why would this be a solution? Well, before I mention the cons to this
>>> approach, consider the following:
>>>
>>> *Problems it would solve:*
>>> 1) There is no money and little interest for AGI. Even if you could get
>>> money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>>> supposed to be trying to get us money, not dissuade it. But, I really think
>>> we are repeating the mistakes of earlier researchers that promised too much
>>> on unjustified ideas. Then when they failed, it created AI winters, over and
>>> over and over again. History repeats itself.
>>>
>>> So, getting us more money would likely do harm in addition to too little
>>> good, the way it would be spent, for me to care. Extremely few people are
>>> interested in AGI and among those that are, their ideas about it are very,
>>> very flawed. We tend to approach the problem using our typical heuristics
>>> and problem solving techniques, but the problem is no longer amenable to
>>> these techniques. For example, the idea that patterns finding is sufficient
>>> for intelligence. It has not been proven beyond my reasonable arguments
>>> against it. Yet, people are getting funding and pursuing entire
>>> architectures based on it. Does that really make sense? Nope. We must pseudo
>>> test and pseudo design our algorithms first. Why? Because after spending
>>> several years on these designs that I can reasonably predict will fail with
>>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>>> much better off figuring that out earlier rather than later through fast
>>> prototyping techniques, such as the one I mentioned (pseudo design and
>>> testing)?
>>>
>>>
>>> 2) Implementations tend to get overwhelmed by the desire to show
>>> immediate results or achieve practical short-term goals. This completely
>>> throws off AGI implementations, because these other constraints are not
>>> compatible with more important AGI constraints.
>>>
>>>
>>> 3) We could find a solution much faster... AGI is a massively constrained
>>> CSP (Constraint Satisfaction Problem). The eternity puzzle is a great
>>> example of such a problem. If you approach the eternity puzzle using
>>> heuristics alone to generate a likely solution, such as how pretty the
>>> pattern is, or how plausible it is that the designers created this design,
>>> it is guaranteed to fail. This is especially true if it takes you even a few
>>> minutes to reject the design. The puzzle has so many possibilities that if
>>> you were to try to look at each one to see if it was a solution, it would
>>> literally take an eternity.
>>>
>>> So, how do you solve such problems? You start with the most constrained
>>> parts of the puzzle first, and you use heuristics to guide your search for
>>> solutions paths that are likely to contain a solution and avoid solutions
>>> paths that are less likely to contain a solution. Most importantly, you have
>>> to try a lot of solutions and reject the bad ones quickly, so that you can
>>> get to the right one. How does this apply to AGI? It's almost exactly the
>>> same. Current researchers are spending a lot of time on solutions that were
>>> generated using bad heuristics (unjustifiable human reasoning heuristics).
>>> Then they take forever to test them out (years) before they inevitably fail.
>>> A better way is to test solutions with as minimal effort and time as
>>> possible, such as by using pseudo design and testing techniques. This way
>>> you can settle onto the right solution path much, much faster and not waste
>>> time on a solution that clearly wouldn't work if you simply spent a bit more
>>> time analyzing it. Yes, such an approach has problems also, such as
>>> dishonesty or delusion in how the algorithms would actually work. I'll
>>> mention these more below. But, we have those delusions and problems already
>>> :) So, overall, this approach seems to be significantly better.
>>>
>>>
>>> 4) if we could show that a pseudo AGI design works in sufficient detail
>>> and with sufficient plausibility, it would likely change the minds of:
>>> -many people that don't think AGI is possible,
>>> -those that think it isn't possible in their lifetimes, and
>>> -those that think it isn't worth investing in.
>>> In other words... we would get the money, help and interest needed to
>>> make it happen. Demos are great at generating interest in things that are
>>> very complicated. This would be a fantastic demonstration.
>>>
>>>
>>> *Pros:*
>>> 1) Fast design testing and rejection
>>> 2) Rough to fine design... would arrive at a solution faster because it
>>> uses the "*Most*-*Constrained*-Variable-First" heuristic (such as has
>>> been used to solve the eternity puzzle... you solve the most constrained
>>> portion first to avoid having to try out many possibilities that will fail
>>> at the most constrained part).
>>> 3) Less pressure for practical applications and more focus on important
>>> AGI issues... this removes extra constraints that are not compatible with
>>> AGI constraints.
>>> 4) More man power because the design is less costly, less time consuming
>>> and requires less detail-oriented expertise.
>>> 5) Can you think of other pros?
>>>
>>> *Cons:*
>>> 1) People will make assumptions that are false and will delude themselves
>>> about these assumptions even if you point out flaws.
>>>
>>> I don't think there is anything we can do about this except for people
>>> that have not accepted the mistake to create different designs in parallel.
>>> If you disagree with someone, then you'll have to create another branch of
>>> the design or start a new design. At such a point, new comers will have to
>>> decide who is right and who is wrong and choose the project they believe in
>>> the most.
>>>
>>> 2) Important and honest assumptions may be wrong.
>>>
>>> I claim that this is ok because those assumptions would have been made
>>> anyway. At least many of these assumptions can be thrown out at the
>>> hypothetical stage before spending tons of time and money on a bad design.
>>> In addition, I think the work on the rest of the design will likely still be
>>> of value and will allow an implementation project to fix the assumption
>>> mistake and move on.
>>>
>>> 3) Often real world testing provides us with unexpected, new insights.
>>>
>>> While this is true, I don't think it's worth the down side of current
>>> approaches... which is that they take forever to fail and stay stuck on
>>> flawed designs, while trying to convince others that they are right.
>>>
>>>
>>> *Realistic Testing*
>>> I would also suggest to pretend that the pseudo design is a real design
>>> whenever it makes sense to do so. So, how do we decide when to go into
>>> detail and when not to? It depends on the value of that detail. If we can
>>> make reasonable assumptions and then keep moving forward with the design, we
>>> should. If we can't, then we need to go into more detail. Sometimes we might
>>> go into detail just because we can. But, what we shouldn't do is get stuck
>>> in detail that may have to change later on. We would be better served
>>> resolving the higher level portions of the design first (remember the "*
>>> Most*-*Constrained*-Variable-First" heuristic). It is extremely
>>> important to use this heuristic when working on such complicated design
>>> projects
>>>
>>> Thoughts?
>>>
>>> Dave
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>> <http://www.listbox.com&gt;
>>>
>>
>>
>>
>> --
>> Abram Demski
>> http://lo-tho.blogspot.com/
>> http://groups.google.com/group/one-logic
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com&gt;
>>
>
>

Abram,

What I mean is rough to fine design of an AGI. Instead of implementing it as
you work out the details of the design, which is what people currently do,
you create a fake simulation.... which is an animation. The reason it is
fake is that it is a simplification of the real process and you have to make
more assumptions than you might in an actual simulation.

Here is a great example: http://www.youtube.com/watch?v=xbJ0nbzt5Kw&NR=1

This animation is really, really cool. Imagine if you could show how your
AGI design works at a level of detail that was so convincing that it would
be very hard for people to deny. I think this is a great way to accomplish
that. Implementation requires too much detailed work and man power, but a
pseudo simulation could get close enough to show that it would work without
actually implementing it.

This is similar to how you might write pseudo programming code. But, AGI is
too complicated to solve the problem with pseudo code such as that alone.
So, we also need pseudo test data and pseudo simulation of the algorithms on
that data. You could take real data and convert it to a pseudo form that the
simulation could work with.

The major difference here is that when you try to implement something, you
waste time on the details of flawed designs. If we were to work out the
higher level details ahead of time and show that the design wouldn't work
sooner rather than later, we wouldn't have the problems we have now. We
should be sure about each level of design as we develop from rough to fine.
This saves us time because we don't have to declare a project a failure
after 10 years of effort. I mean look at CYC! 26 years and counting! We
would have been much better off just analyzing it for a year and showing
that it really doesn't do what we want it to do. But, no.... people are in
too big of a hurry to implement before fully justifying the "solution".
Until we do something about this, we will continue to fail over and over and
over again. In fact, I will predict that all existing AGI projects will fail
to get anywhere near what they want without *drastic* changes that will
throw out most of their previous work. They'll do little better than
existing narrow methods could do. Why? Because their designs are
unjustified.

Dave

On Wed, Sep 1, 2010 at 6:36 PM, Abram Demski <abramdemski@gmail.com> wrote:

> David,
>
> It is not entirely clear what you mean by pseudo design or pseudo
> simulation. Can you be more specific? Perhaps a semi-formal definition?
>
> --Abram
>
> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> I've been to think lately that the solution to creating a realistic AGI
>> design is psuedo design. What do I mean? Not simulation... not practical
>> applications... not extremely detailed implementations. The design would
>> start at a high level and go deeper into detail as possible.
>>
>> So, why would this be a solution? Well, before I mention the cons to this
>> approach, consider the following:
>>
>> *Problems it would solve:*
>> 1) There is no money and little interest for AGI. Even if you could get
>> money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>> supposed to be trying to get us money, not dissuade it. But, I really think
>> we are repeating the mistakes of earlier researchers that promised too much
>> on unjustified ideas. Then when they failed, it created AI winters, over and
>> over and over again. History repeats itself.
>>
>> So, getting us more money would likely do harm in addition to too little
>> good, the way it would be spent, for me to care. Extremely few people are
>> interested in AGI and among those that are, their ideas about it are very,
>> very flawed. We tend to approach the problem using our typical heuristics
>> and problem solving techniques, but the problem is no longer amenable to
>> these techniques. For example, the idea that patterns finding is sufficient
>> for intelligence. It has not been proven beyond my reasonable arguments
>> against it. Yet, people are getting funding and pursuing entire
>> architectures based on it. Does that really make sense? Nope. We must pseudo
>> test and pseudo design our algorithms first. Why? Because after spending
>> several years on these designs that I can reasonably predict will fail with
>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>> much better off figuring that out earlier rather than later through fast
>> prototyping techniques, such as the one I mentioned (pseudo design and
>> testing)?
>>
>>
>> 2) Implementations tend to get overwhelmed by the desire to show immediate
>> results or achieve practical short-term goals. This completely throws off
>> AGI implementations, because these other constraints are not compatible with
>> more important AGI constraints.
>>
>>
>> 3) We could find a solution much faster... AGI is a massively constrained
>> CSP (Constraint Satisfaction Problem). The eternity puzzle is a great
>> example of such a problem. If you approach the eternity puzzle using
>> heuristics alone to generate a likely solution, such as how pretty the
>> pattern is, or how plausible it is that the designers created this design,
>> it is guaranteed to fail. This is especially true if it takes you even a few
>> minutes to reject the design. The puzzle has so many possibilities that if
>> you were to try to look at each one to see if it was a solution, it would
>> literally take an eternity.
>>
>> So, how do you solve such problems? You start with the most constrained
>> parts of the puzzle first, and you use heuristics to guide your search for
>> solutions paths that are likely to contain a solution and avoid solutions
>> paths that are less likely to contain a solution. Most importantly, you have
>> to try a lot of solutions and reject the bad ones quickly, so that you can
>> get to the right one. How does this apply to AGI? It's almost exactly the
>> same. Current researchers are spending a lot of time on solutions that were
>> generated using bad heuristics (unjustifiable human reasoning heuristics).
>> Then they take forever to test them out (years) before they inevitably fail.
>> A better way is to test solutions with as minimal effort and time as
>> possible, such as by using pseudo design and testing techniques. This way
>> you can settle onto the right solution path much, much faster and not waste
>> time on a solution that clearly wouldn't work if you simply spent a bit more
>> time analyzing it. Yes, such an approach has problems also, such as
>> dishonesty or delusion in how the algorithms would actually work. I'll
>> mention these more below. But, we have those delusions and problems already
>> :) So, overall, this approach seems to be significantly better.
>>
>>
>> 4) if we could show that a pseudo AGI design works in sufficient detail
>> and with sufficient plausibility, it would likely change the minds of:
>> -many people that don't think AGI is possible,
>> -those that think it isn't possible in their lifetimes, and
>> -those that think it isn't worth investing in.
>> In other words... we would get the money, help and interest needed to make
>> it happen. Demos are great at generating interest in things that are very
>> complicated. This would be a fantastic demonstration.
>>
>>
>> *Pros:*
>> 1) Fast design testing and rejection
>> 2) Rough to fine design... would arrive at a solution faster because it
>> uses the "*Most*-*Constrained*-Variable-First" heuristic (such as has
>> been used to solve the eternity puzzle... you solve the most constrained
>> portion first to avoid having to try out many possibilities that will fail
>> at the most constrained part).
>> 3) Less pressure for practical applications and more focus on important
>> AGI issues... this removes extra constraints that are not compatible with
>> AGI constraints.
>> 4) More man power because the design is less costly, less time consuming
>> and requires less detail-oriented expertise.
>> 5) Can you think of other pros?
>>
>> *Cons:*
>> 1) People will make assumptions that are false and will delude themselves
>> about these assumptions even if you point out flaws.
>>
>> I don't think there is anything we can do about this except for people
>> that have not accepted the mistake to create different designs in parallel.
>> If you disagree with someone, then you'll have to create another branch of
>> the design or start a new design. At such a point, new comers will have to
>> decide who is right and who is wrong and choose the project they believe in
>> the most.
>>
>> 2) Important and honest assumptions may be wrong.
>>
>> I claim that this is ok because those assumptions would have been made
>> anyway. At least many of these assumptions can be thrown out at the
>> hypothetical stage before spending tons of time and money on a bad design.
>> In addition, I think the work on the rest of the design will likely still be
>> of value and will allow an implementation project to fix the assumption
>> mistake and move on.
>>
>> 3) Often real world testing provides us with unexpected, new insights.
>>
>> While this is true, I don't think it's worth the down side of current
>> approaches... which is that they take forever to fail and stay stuck on
>> flawed designs, while trying to convince others that they are right.
>>
>>
>> *Realistic Testing*
>> I would also suggest to pretend that the pseudo design is a real design
>> whenever it makes sense to do so. So, how do we decide when to go into
>> detail and when not to? It depends on the value of that detail. If we can
>> make reasonable assumptions and then keep moving forward with the design, we
>> should. If we can't, then we need to go into more detail. Sometimes we might
>> go into detail just because we can. But, what we shouldn't do is get stuck
>> in detail that may have to change later on. We would be better served
>> resolving the higher level portions of the design first (remember the "*
>> Most*-*Constrained*-Variable-First" heuristic). It is extremely
>> important to use this heuristic when working on such complicated design
>> projects
>>
>> Thoughts?
>>
>> Dave
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com&gt;
>>
>
>
>
> --
> Abram Demski
> http://lo-tho.blogspot.com/
> http://groups.google.com/group/one-logic
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>

I was just trying to think of a justification for the effort I have made on
this non-agi project when I discovered a possible partial solution to a long
standing AGI problem. Suppose you want to make an AGI program so that it
had a slight bias for symmetry, solidity of surfaces for a certain size, and
graceful movements. How do you do this. If you wanted an AGI program to
react with a slight bias for the symmetry of a face how do you go about it.
You might try to include some innate images of symmetry so that every time
the program saw symmetry it would react to it. Or you might rely on some
abstruse mathematical algorithms that represented symmetry. But how many
thousands of images would you need to use so that the program could match a
particular face with one of the images. Remember, the computer might not
see the face straight on, properly framed to maximize the symmetry. Ok, how
about graceful movements? How is it possible to provide an AGI program with
examples of every possible type of graceful movement for it to react to it
when it sees it? There would have to be thousands of examples and it would
just take too long for the program search through all of them to find the
one example which could be matched with the sample observation.

By finding algorithms that can generate apparent movements that would appear
graceful (in an animation for instance) and then choose those subset of
algorithms that were easily modifiable by a large variety of possible
reference points, a simple, very efficient grace detection method could be
based on a parameter driven generative algorithm.

This doesn't solve the major AGI problems but it does show how an old idea
can be fit into a long standing problem as a solution. And it shows how the
creative generation algorithm challenge may lead to some novel insights
about AGI even though it is not itself an AGI program.

Jim,

So, you seem to want to simulate natural language processing first, then it
would associate the hypothesized words with their associated concepts and
relationships. In addition it sounds like you want it to search for
experience associated to the interpreted concepts and then decide, based on
experience and goals, how to manipulate the data. In the case, the
manipulation of the data would be whether to refer to water as a substance
or a countable object? Well, that's all I could glean from what you wrote.

Your description is a bit more abstract than what I described above. But,
from above, can you see where I'm going with this? You would have to pseudo
simulate how word parsing and match searching would retrieve possible
concepts and decide which ones were correct and which were not. Based on
experience, you might have specialized "programs" or rules that
heuristically manipulate data in ways that have been successful in the past.
An example program or rule might be to use count syntax for non-substance
objects, but not to use it for substances.

Make sense? So, you might store this non-substance and substance rule as
experience. This is one assumption... that you already have that experience.
Then you would have to resolve this assumption by showing how such
experience would be learned in the same way you would show how the above
scenario would be processed.

You would do this as a rough level at first, but as you finish the high
level description all across the AGI's design, you would go into deeper
detail.

Dave

On Wed, Sep 1, 2010 at 8:00 PM, Jim Bromer <jimbromer@gmail.com> wrote:

> At first the structure of the simulation would be completely created by
> me. I would start with concrete references - probably using a simplified
> version of natural language to refer to objects of a simple sim world of a
> few objects. The linguistic references would be concrete. As I design a
> program, in order to find a few ways to make the program more efficient I
> end up with cases that generally work, but which require special algorithms
> for some unusual cases. These might be considered as technical
> complications and would be handled in the customary manner by writing more
> algorithms to handle the special cases. However, there are going to be
> knowledge objects (or knowledge-like object references) in which special
> cases are best understood to be reason-based. One such reason is a lack of
> experience with an alternative method. So children and most adults do not
> understand why water, in the most natural observation, is not considered to
> be a countable object even though we can refer to it as if it were. On the
> other hand, we do have reasons for treating a machine that is new and
> useful. (The reason is that it is useful.)
> Jim Bromer
>
>
>
> On Wed, Sep 1, 2010 at 6:07 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Jim,
>>
>> I'm not clear on what type of problem or type of reasoning you would like
>> to simulate... so I'm a bit confused. You might have to be specific
>> regarding a problem that you would expect to be solved or a type of
>> reasoning on an example problem.
>>
>> Dave
>>
>> On Wed, Sep 1, 2010 at 5:53 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>
>>> Assisted Simulation.
>>> I was just thinking that I could start with something real simple. By
>>> using arrays for all the global variables (and the transcripts and other
>>> data that needs to be saved), then when I was ready to quit, I could just
>>> save the variables that I used to resume where I left off. This would
>>> simplify the first stage of the test because I don't have to worry about
>>> disk access data structures during the initial test phase. I might start
>>> with concrete examples to test my ideas. Then I would throw slightly more
>>> complicated examples at the conceptual integration process. I would have to
>>> apply the higher intelligence but since I believe conceptual integration is
>>> directly involved with structures and relations that are necessary for
>>> intelligence, I would be defining a system that should exhibit
>>> emergent partial intelligence. If my test was successful, then some aspects
>>> of intelligence would be emergent so while I would still have to supply the
>>> higher intelligence the program should be able to take on some of the
>>> easier management of intelligence.
>>>
>>> Conceptual Integration involves both the data structures and the
>>> processes of knowledge. There may not be a clear distinction between data
>>> and process but it is not important. A concept will be an agglomeration of
>>> many different ideas or sub-ideas and will require the use of different
>>> kinds of processes and different relations to other concepts or sub-ideas
>>> depending on the context. Reasons will be used to determine the reasons
>>> behind the choice of operations and data objects. The program would not be
>>> able to know all the reasons why I would do something, and that's why I
>>> would have to supply the higher intelligence in the assisted simulation.
>>>
>>> My ideas about conceptual integration are not completely new, but I see
>>> it as part of the need for a much greater reliance on more sophisticated
>>> data structures, relations and processes than have been used in the past.
>>> Just as the different parts of a mathematical process play different roles
>>> in computational processes, different conceptual structures would play
>>> different kinds of roles in a conceptually integrated AGI program.
>>> Jim Bromer
>>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>

I have tried to explain that an AGI program has to react to input. I don't
know how I can make this any clearer other than to realize that there aren't
many of you who actually read the stuff that I write and the effort is
pretty much a waste of time.
I have tried to explain that if an AGI program was able to learn to design a
font (or other icon) through a truly intelligent method, then there must be
a non-intelligent algorithm that could create the font as well. If there
wasn't, then it would be impossible for a computer to design the font.
To take it to the next level there must be a generative program that would
create the font as one of many possible fonts that were similar in some way.

I can explain this a little better. A closed program, that lacked exposure
to visual representations of lions of any kind, would not be able to come up
with an idea that the base of an icon might be portrayed as standing on
lions paws. However, a program that was able to decorate the various
representations of the icon that it turned out might portray the icon with
various kinds of blobs or shapes around it. One of these images might look
a little like the icon was standing on a pedestal of lions paws.

If the program ran on a reinforcement scheme, this particular image might be
reinforced and each time the program made something that looked a little
more like the icon was standing on a pedestal of carved lions paws it was
reinforced again, the program might eventually portray the desired image
even though it never saw an image of anything that remotely resembled lions
paws.

I decided to take this challenge, not because I wanted to prove something to
anyone, but because I thought I might discover something interesting in the
process. And I have.
Jim Bromer

Dave,

Look again. The same basic method - improvisation - trial and error - incl. "just acting out rough to fine motor commands" [except they don't have to be precise commands - robots don't always do that now - they can "jiggle" around] - will work for ALL AGI problems. It's the only one that will work.

Preplanning a step-by-step procedure before you've even seen the problem and know what elements you will have to work with, won't work for any problems let alone AGI period ..

P.S. If you'd thought still more - and you're now starting to get places - you'd realise that your version of "my" problems is hasty and exaggerated.

By definition, if you think about the A font problem, and indeed as I defined it in practice, the problemsolver, human or machine, must of course already have a selection of A fonts (and know that they classify as "A" fonts) - or in your words, "have experience."

The creative problem is then either how do they produce a new kind of font using a new kind of element that does not in any logical way "follow" from those known? - or how do they *recognize" a new kind of font that s.o. else has designed, ?.

The A font problem, I agree, may not first appear like an archetypal AGI problem, but in fact it is. Try and find a real AGI problem that is different in kind.

And note below - you've done a QED on what I claimed - precisely because the problem is so accessible, you've had little difficulty thinking about it, once you put your mind to it. You will not understand this - but there's an art to identifying such problems.

P.S. The rock wall problem is a similarly accessible problem. It's AGI because no matter how many rock forms you've handled and laid together, you will continually be faced with new kinds of rock forms, which you must discover new ways to handle and lay. And indeed this is the reality of human rocklaying - it is actually a continuously somewhat difficult problem. And no program or maths can handle it - as distinct from bricklaying.


From: David Jones
Sent: Wednesday, September 01, 2010 9:52 PM
To: AGI
Subject: Re: [agi] Re: Compressed Cross-Indexed Concepts


Jim,

I was responding to mikes "Visual Object Recognition - recognize all those fonts as "A"" challenge....

As for the generate a new font problem... sure, that could be considered an AGI problem if the AGI had experience. But the thing is, we don't program AGI's with that sort of experience from the beginning. It doesn't make sense as an AGI problem because that assume that the AGI should be able to perform such feats without other general abilities and quite a bit of experience to draw from. This assumption is required because I can't just say well the AI has drawing experience and bla bla bla. Because mike will yell bullshit and mysticism. But the truth is that drawing and such creativity DOES draw on a lot of experience. So, to make it a fundamental problem doesn't make one wit of sense.

But, for arguments sake... let's assume that I had to suggest how an AI might do this.... Well, I could say that the AI has the ability to perform trial and error actions. It attempts something and then evaluates it. It is able to recognize fonts in similar ways that humans do, so it will recognize when a font has the right properties to be recognized by other people as an A. It might know that nice twists and curves are kinda cool and creative because it has seen them before. It might know that AI's typically have certain major features such as the lowercase version has a large curve from the top-right to the left-middle and then down to the bottom-right. It also typically has a curving line from the top-right to the bottom-right. So, given all these "creative" ideas, it could start trial and error generation of new fonts using a search for ideas from past experience as well as just acting out rough to fine motor commands. All the while the AI is evaluating whether the evolving form is going to have the patterns that a person would expect of an "A", which is could recognize. If it creates a pattern that it feels should be rejected because it probably wouldn't be evaluated as an "A", then it would erase and try again, etc.

You see? There is an immense amount of trial and error, as well as very complicated general reasoning going on. Why in the world would I start with that problem when building AGI? I certainly wouldn't. It's a nice example to keep in mind and analyze. But it is certainly not the most fundamental problem I would want to think about. If I designed specifically for this, I would likely over engineer a solution that doesn't make sense for most other problems.

Dave


On Wed, Sep 1, 2010 at 4:38 PM, Jim Bromer <jimbromer@gmail.com> wrote:

David,
You are missing something here. While it is impossible for a program or a person to "design" every possible font without any realistic contextual cues, inforation and experience, and it would therefore be a waste of time to try, it is not a waste of time to try to consider what kind of program would be needed to have the potential to design any kind of font. Such a process cannot be intelligently done just by copying fonts from other sources for example, so it becomes very relevant to at least start thinking about what kind of knowledge structures would be necessary to maximize the potential for it to learn.

I am considering the problem from the point of view of whether or not I can write a closed program that can produce such a vast number of variations of an icon, because in solving the problem I have seen that I can get a better handle on the nature of the data structures and relations between data objects might be needed for a better designed AGI program.

I realize that Mike has no idea about what I am talking about, but I am surprised that you don't get it.

Jim Bromer

On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com> wrote:

Mike,
Have you ever considered that maybe it is impractical and irrational to design an AGI system to recognize all possible fonts for "a" without any realistic contextual cues, info and experience? Did you ever consider that maybe that's the dumbest way to design an AGI ever?

People can't take any possible random and unexpected pattern out of context and figure out what it is. Intelligence doesn't work that way. We use cues to twist what we see into what we expect. If you could see out of your tunnel, you might realize this.

So, recognizing any possible "a" font is not a realistic or pragmatic AGI problem. And I would be an idiot to spend any time trying to solve it.

AGI | Archives | Modify Your Subscription



AGI | Archives | Modify Your Subscription

At first the structure of the simulation would be completely created by me.
I would start with concrete references - probably using a simplified version
of natural language to refer to objects of a simple sim world of a few
objects. The linguistic references would be concrete. As I design a
program, in order to find a few ways to make the program more efficient I
end up with cases that generally work, but which require special algorithms
for some unusual cases. These might be considered as technical
complications and would be handled in the customary manner by writing more
algorithms to handle the special cases. However, there are going to be
knowledge objects (or knowledge-like object references) in which special
cases are best understood to be reason-based. One such reason is a lack of
experience with an alternative method. So children and most adults do not
understand why water, in the most natural observation, is not considered to
be a countable object even though we can refer to it as if it were. On the
other hand, we do have reasons for treating a machine that is new and
useful. (The reason is that it is useful.)
Jim Bromer



On Wed, Sep 1, 2010 at 6:07 PM, David Jones <davidhere40@gmail.com> wrote:

> Jim,
>
> I'm not clear on what type of problem or type of reasoning you would like
> to simulate... so I'm a bit confused. You might have to be specific
> regarding a problem that you would expect to be solved or a type of
> reasoning on an example problem.
>
> Dave
>
> On Wed, Sep 1, 2010 at 5:53 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>
>> Assisted Simulation.
>> I was just thinking that I could start with something real simple. By
>> using arrays for all the global variables (and the transcripts and other
>> data that needs to be saved), then when I was ready to quit, I could just
>> save the variables that I used to resume where I left off. This would
>> simplify the first stage of the test because I don't have to worry about
>> disk access data structures during the initial test phase. I might start
>> with concrete examples to test my ideas. Then I would throw slightly more
>> complicated examples at the conceptual integration process. I would have to
>> apply the higher intelligence but since I believe conceptual integration is
>> directly involved with structures and relations that are necessary for
>> intelligence, I would be defining a system that should exhibit
>> emergent partial intelligence. If my test was successful, then some aspects
>> of intelligence would be emergent so while I would still have to supply the
>> higher intelligence the program should be able to take on some of the
>> easier management of intelligence.
>>
>> Conceptual Integration involves both the data structures and the processes
>> of knowledge. There may not be a clear distinction between data and process
>> but it is not important. A concept will be an agglomeration of many
>> different ideas or sub-ideas and will require the use of different kinds of
>> processes and different relations to other concepts or sub-ideas depending
>> on the context. Reasons will be used to determine the reasons behind the
>> choice of operations and data objects. The program would not be able to
>> know all the reasons why I would do something, and that's why I would have
>> to supply the higher intelligence in the assisted simulation.
>>
>> My ideas about conceptual integration are not completely new, but I see it
>> as part of the need for a much greater reliance on more sophisticated data
>> structures, relations and processes than have been used in the past. Just
>> as the different parts of a mathematical process play different roles in
>> computational processes, different conceptual structures would play
>> different kinds of roles in a conceptually integrated AGI program.
>> Jim Bromer
>>
>

Please you guys. It is purely narrow AI thinking to talk about "designing every possible font." Why? Because you think in terms of sets of options and all the variations possible. There are no sets of options/parts in creative/AGI problems.

The requirement for an AGI is to be able to "endlessly diversify". That means you may only have to design one or a few new fonts to begin with. Maybe you haven't worked in a professional creative department of any kind. Creatives are not required to produce "all possible solutions to this problem." That is a meaningless or at any rate completely unrealistic concept in creativity. [But narrow AI-ers can legitimately think in those terms]. Creatives are required typically to produce a selection of solutions. And if none of them are good enough, back to the drawing board for some more. And if neces., then back again. And again. "Endlessly diversify" simply means the capacity to keep bringing in new kinds of parts, keep entering new fields - not "all" fields. Jeez..

All this takes a long time, and it will take an AGI machine a relatively long time. Searching through a world of possibilities involves a lot of blanks and pauses often, before you can even think of a field to search. A lot of "groping in the dark" pace Einstein.

You really do have to do what I've told you to re actually tackling creative problems - it's a sine qua non. Don't talk about "sex," if you haven't had it.



From: Jim Bromer
Sent: Wednesday, September 01, 2010 9:38 PM
To: AGI
Subject: Re: [agi] Re: Compressed Cross-Indexed Concepts


David,
You are missing something here. While it is impossible for a program or a person to "design" every possible font without any realistic contextual cues, inforation and experience, and it would therefore be a waste of time to try, it is not a waste of time to try to consider what kind of program would be needed to have the potential to design any kind of font. Such a process cannot be intelligently done just by copying fonts from other sources for example, so it becomes very relevant to at least start thinking about what kind of knowledge structures would be necessary to maximize the potential for it to learn.

I am considering the problem from the point of view of whether or not I can write a closed program that can produce such a vast number of variations of an icon, because in solving the problem I have seen that I can get a better handle on the nature of the data structures and relations between data objects might be needed for a better designed AGI program.

I realize that Mike has no idea about what I am talking about, but I am surprised that you don't get it.

Jim Bromer

On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com> wrote:

Mike,
Have you ever considered that maybe it is impractical and irrational to design an AGI system to recognize all possible fonts for "a" without any realistic contextual cues, info and experience? Did you ever consider that maybe that's the dumbest way to design an AGI ever?

People can't take any possible random and unexpected pattern out of context and figure out what it is. Intelligence doesn't work that way. We use cues to twist what we see into what we expect. If you could see out of your tunnel, you might realize this.

So, recognizing any possible "a" font is not a realistic or pragmatic AGI problem. And I would be an idiot to spend any time trying to solve it.

AGI | Archives | Modify Your Subscription

David,

It is not entirely clear what you mean by pseudo design or pseudo
simulation. Can you be more specific? Perhaps a semi-formal definition?

--Abram

On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com> wrote:

> I've been to think lately that the solution to creating a realistic AGI
> design is psuedo design. What do I mean? Not simulation... not practical
> applications... not extremely detailed implementations. The design would
> start at a high level and go deeper into detail as possible.
>
> So, why would this be a solution? Well, before I mention the cons to this
> approach, consider the following:
>
> *Problems it would solve:*
> 1) There is no money and little interest for AGI. Even if you could get
> money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
> supposed to be trying to get us money, not dissuade it. But, I really think
> we are repeating the mistakes of earlier researchers that promised too much
> on unjustified ideas. Then when they failed, it created AI winters, over and
> over and over again. History repeats itself.
>
> So, getting us more money would likely do harm in addition to too little
> good, the way it would be spent, for me to care. Extremely few people are
> interested in AGI and among those that are, their ideas about it are very,
> very flawed. We tend to approach the problem using our typical heuristics
> and problem solving techniques, but the problem is no longer amenable to
> these techniques. For example, the idea that patterns finding is sufficient
> for intelligence. It has not been proven beyond my reasonable arguments
> against it. Yet, people are getting funding and pursuing entire
> architectures based on it. Does that really make sense? Nope. We must pseudo
> test and pseudo design our algorithms first. Why? Because after spending
> several years on these designs that I can reasonably predict will fail with
> a high likelihood, we'll be back as the same place we were. Wouldn't we be
> much better off figuring that out earlier rather than later through fast
> prototyping techniques, such as the one I mentioned (pseudo design and
> testing)?
>
>
> 2) Implementations tend to get overwhelmed by the desire to show immediate
> results or achieve practical short-term goals. This completely throws off
> AGI implementations, because these other constraints are not compatible with
> more important AGI constraints.
>
>
> 3) We could find a solution much faster... AGI is a massively constrained
> CSP (Constraint Satisfaction Problem). The eternity puzzle is a great
> example of such a problem. If you approach the eternity puzzle using
> heuristics alone to generate a likely solution, such as how pretty the
> pattern is, or how plausible it is that the designers created this design,
> it is guaranteed to fail. This is especially true if it takes you even a few
> minutes to reject the design. The puzzle has so many possibilities that if
> you were to try to look at each one to see if it was a solution, it would
> literally take an eternity.
>
> So, how do you solve such problems? You start with the most constrained
> parts of the puzzle first, and you use heuristics to guide your search for
> solutions paths that are likely to contain a solution and avoid solutions
> paths that are less likely to contain a solution. Most importantly, you have
> to try a lot of solutions and reject the bad ones quickly, so that you can
> get to the right one. How does this apply to AGI? It's almost exactly the
> same. Current researchers are spending a lot of time on solutions that were
> generated using bad heuristics (unjustifiable human reasoning heuristics).
> Then they take forever to test them out (years) before they inevitably fail.
> A better way is to test solutions with as minimal effort and time as
> possible, such as by using pseudo design and testing techniques. This way
> you can settle onto the right solution path much, much faster and not waste
> time on a solution that clearly wouldn't work if you simply spent a bit more
> time analyzing it. Yes, such an approach has problems also, such as
> dishonesty or delusion in how the algorithms would actually work. I'll
> mention these more below. But, we have those delusions and problems already
> :) So, overall, this approach seems to be significantly better.
>
>
> 4) if we could show that a pseudo AGI design works in sufficient detail and
> with sufficient plausibility, it would likely change the minds of:
> -many people that don't think AGI is possible,
> -those that think it isn't possible in their lifetimes, and
> -those that think it isn't worth investing in.
> In other words... we would get the money, help and interest needed to make
> it happen. Demos are great at generating interest in things that are very
> complicated. This would be a fantastic demonstration.
>
>
> *Pros:*
> 1) Fast design testing and rejection
> 2) Rough to fine design... would arrive at a solution faster because it
> uses the "*Most*-*Constrained*-Variable-First" heuristic (such as has been
> used to solve the eternity puzzle... you solve the most constrained portion
> first to avoid having to try out many possibilities that will fail at the
> most constrained part).
> 3) Less pressure for practical applications and more focus on important AGI
> issues... this removes extra constraints that are not compatible with AGI
> constraints.
> 4) More man power because the design is less costly, less time consuming
> and requires less detail-oriented expertise.
> 5) Can you think of other pros?
>
> *Cons:*
> 1) People will make assumptions that are false and will delude themselves
> about these assumptions even if you point out flaws.
>
> I don't think there is anything we can do about this except for people that
> have not accepted the mistake to create different designs in parallel. If
> you disagree with someone, then you'll have to create another branch of the
> design or start a new design. At such a point, new comers will have to
> decide who is right and who is wrong and choose the project they believe in
> the most.
>
> 2) Important and honest assumptions may be wrong.
>
> I claim that this is ok because those assumptions would have been made
> anyway. At least many of these assumptions can be thrown out at the
> hypothetical stage before spending tons of time and money on a bad design.
> In addition, I think the work on the rest of the design will likely still be
> of value and will allow an implementation project to fix the assumption
> mistake and move on.
>
> 3) Often real world testing provides us with unexpected, new insights.
>
> While this is true, I don't think it's worth the down side of current
> approaches... which is that they take forever to fail and stay stuck on
> flawed designs, while trying to convince others that they are right.
>
>
> *Realistic Testing*
> I would also suggest to pretend that the pseudo design is a real design
> whenever it makes sense to do so. So, how do we decide when to go into
> detail and when not to? It depends on the value of that detail. If we can
> make reasonable assumptions and then keep moving forward with the design, we
> should. If we can't, then we need to go into more detail. Sometimes we might
> go into detail just because we can. But, what we shouldn't do is get stuck
> in detail that may have to change later on. We would be better served
> resolving the higher level portions of the design first (remember the "*
> Most*-*Constrained*-Variable-First" heuristic). It is extremely important
> to use this heuristic when working on such complicated design projects
>
> Thoughts?
>
> Dave
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>



--
Abram Demski
http://lo-tho.blogspot.com/
http://groups.google.com/group/one-logic

I just thought of a great analogy for my idea...

Imagine that AGI like trying to create a movie like Avatar that beats every
money making record in movie history.

In the analogy, the way researchers make AGI movies right now is that they
let people come in with an idea about a movie that they express in about one
paragraph. If the producers like it, they run with it and dump a billion
bucks into it. Now, for movies this sometimes works, but sometimes it flops.
But for a billion bucks? No one in their right mind signs a check for a
billion buck movie after hearing one paragraph.

If you wanted to make such a movie, you would test it hypothetically until
you were sure that it would work, then you would design how to shoot the
movie hypothetically in stages, then you would draw up how you were going to
shoot it. Finally you should shoot (implement) the movie. Before any
implementation starts though, you would run surveys, create cartoons, do
mockups, test technology such as the one for capturing actors facial
expressions, etc.

Not until you've worked the whole thing out and can show that you can not
only implement it, you know how much it costs, how much people will like it
and you can even say how long it will take! You even have a cartoon or comic
strip that looks like the movie will in many ways.

What I am suggesting is all this preparation and especially the cartoon.
Because with the cartoon and comic-strip you can even show people what the
movie will be like and see their reactions. This is similar to the same
effect this pseudo simulation would have for fund raising. People will be
able to understand immediately and you will know if it will work or not. If
you just handed a group of potential movie viewers a 2,000 page script and
asked them what they thought, the odds are that they would have no clue and
it wouldn't be clear if it would work.

Make sense?

Dave

On Wed, Sep 1, 2010 at 3:40 PM, David Jones <davidhere40@gmail.com> wrote:

> Maybe a better term for what I'm talking about it Pseudo Simulation
>
> Dave
>
>
> On Wed, Sep 1, 2010 at 3:15 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Jim,
>>
>> Right, we might be missing important algorithms that we might need to move
>> forward on a design. But, we can make assumptions at various levels and
>> probably even assume that the algorithm works. We can estimate the risk that
>> it will work or won't work. We can see how the algorithm integrates with the
>> rest of the system.
>>
>> You may find out that even if the algorithm works, it won't do what you
>> wanted because the system fails at a different point. So, my point is to
>> avoid spending years on such a mistake and find it much faster through
>> pseudo testing. I see this precise mistake repeated over and over and over
>> again in AI.
>>
>> Most algorithms do not have to be implemented to test an AGI design.
>> People go about implementing things because they are in a hurry and we feel
>> better if we are working on something tangible. But, I think this problem's
>> extreme difficulties are going to force us to solve AGI hypothetically
>> before actually implementing it. If we implement it before having
>> sufficiently tested our ideas on hypotheticals, I think we will waste an
>> immense amount of time... in fact, we've already spent decades on failed AI
>> projects. How about a little better planning now?
>>
>> Dave
>>
>>
>> On Wed, Sep 1, 2010 at 3:00 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>
>>> Grammatical Correction:
>>> Now maybe my feeling that no one gets this is like Mike's presumption
>>> that no AGI'ers have ever used meta cognition to think about how they go
>>> about solving a problem as they worked on an actual problem, but I haven't
>>> seen anything beyond the most superficial assertion that people have
>>> considered conceptual integration in much detail.
>>>
>>> On Wed, Sep 1, 2010 at 2:57 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>>
>>>> There is something missing. There are some algorithms that you
>>>> absolutely need that you don't have. My example of the lack of
>>>> sophisticated conceptual integration represents an extraordinary gap in my
>>>> thinking. (Freudian error. I meant to say something like, to my mind it
>>>> represents an extraordinary gap, but it errantly came out as a gap in my
>>>> thinking. However, I am able to acknowledge that there are aspects of
>>>> conceptual integration that I haven't figured out yet. That's why I wish it
>>>> was a topic that people would think about.) I think one person actually
>>>> discussed this idea with me in a way that suggests that he had any idea
>>>> about what I was talking about. I presume that every advanced AGI
>>>> conjecture includes some aspects of conceptual integration, but no one
>>>> actually converses with me in a way that would suggest that he actually gets
>>>> what I am talking about. Now maybe my feeling that no one gets this is like
>>>> Mike's presumption that no AGI'ers have never used meta cognition to think
>>>> about how they go about solving a problem after they have solve it, but I
>>>> haven't seen anything beyond the most superficial assertion that people had
>>>> thought about this.
>>>> Jim Bromer
>>>>
>>>> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>
>>>>> I've been to think lately that the solution to creating a realistic AGI
>>>>> design is psuedo design. What do I mean? Not simulation... not practical
>>>>> applications... not extremely detailed implementations. The design would
>>>>> start at a high level and go deeper into detail as possible.
>>>>>
>>>>> So, why would this be a solution? Well, before I mention the cons to
>>>>> this approach, consider the following:
>>>>>
>>>>> *Problems it would solve:*
>>>>> 1) There is no money and little interest for AGI. Even if you could get
>>>>> money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>>>>> supposed to be trying to get us money, not dissuade it. But, I really think
>>>>> we are repeating the mistakes of earlier researchers that promised too much
>>>>> on unjustified ideas. Then when they failed, it created AI winters, over and
>>>>> over and over again. History repeats itself.
>>>>>
>>>>> So, getting us more money would likely do harm in addition to too
>>>>> little good, the way it would be spent, for me to care. Extremely few people
>>>>> are interested in AGI and among those that are, their ideas about it are
>>>>> very, very flawed. We tend to approach the problem using our typical
>>>>> heuristics and problem solving techniques, but the problem is no longer
>>>>> amenable to these techniques. For example, the idea that patterns finding is
>>>>> sufficient for intelligence. It has not been proven beyond my reasonable
>>>>> arguments against it. Yet, people are getting funding and pursuing entire
>>>>> architectures based on it. Does that really make sense? Nope. We must pseudo
>>>>> test and pseudo design our algorithms first. Why? Because after spending
>>>>> several years on these designs that I can reasonably predict will fail with
>>>>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>>>>> much better off figuring that out earlier rather than later through fast
>>>>> prototyping techniques, such as the one I mentioned (pseudo design and
>>>>> testing)?
>>>>>
>>>>>
>>>>> 2) Implementations tend to get overwhelmed by the desire to show
>>>>> immediate results or achieve practical short-term goals. This completely
>>>>> throws off AGI implementations, because these other constraints are not
>>>>> compatible with more important AGI constraints.
>>>>>
>>>>>
>>>>> 3) We could find a solution much faster... AGI is a massively
>>>>> constrained CSP (Constraint Satisfaction Problem). The eternity puzzle is a
>>>>> great example of such a problem. If you approach the eternity puzzle using
>>>>> heuristics alone to generate a likely solution, such as how pretty the
>>>>> pattern is, or how plausible it is that the designers created this design,
>>>>> it is guaranteed to fail. This is especially true if it takes you even a few
>>>>> minutes to reject the design. The puzzle has so many possibilities that if
>>>>> you were to try to look at each one to see if it was a solution, it would
>>>>> literally take an eternity.
>>>>>
>>>>> So, how do you solve such problems? You start with the most constrained
>>>>> parts of the puzzle first, and you use heuristics to guide your search for
>>>>> solutions paths that are likely to contain a solution and avoid solutions
>>>>> paths that are less likely to contain a solution. Most importantly, you have
>>>>> to try a lot of solutions and reject the bad ones quickly, so that you can
>>>>> get to the right one. How does this apply to AGI? It's almost exactly the
>>>>> same. Current researchers are spending a lot of time on solutions that were
>>>>> generated using bad heuristics (unjustifiable human reasoning heuristics).
>>>>> Then they take forever to test them out (years) before they inevitably fail.
>>>>> A better way is to test solutions with as minimal effort and time as
>>>>> possible, such as by using pseudo design and testing techniques. This way
>>>>> you can settle onto the right solution path much, much faster and not waste
>>>>> time on a solution that clearly wouldn't work if you simply spent a bit more
>>>>> time analyzing it. Yes, such an approach has problems also, such as
>>>>> dishonesty or delusion in how the algorithms would actually work. I'll
>>>>> mention these more below. But, we have those delusions and problems already
>>>>> :) So, overall, this approach seems to be significantly better.
>>>>>
>>>>>
>>>>> 4) if we could show that a pseudo AGI design works in sufficient detail
>>>>> and with sufficient plausibility, it would likely change the minds of:
>>>>> -many people that don't think AGI is possible,
>>>>> -those that think it isn't possible in their lifetimes, and
>>>>> -those that think it isn't worth investing in.
>>>>> In other words... we would get the money, help and interest needed to
>>>>> make it happen. Demos are great at generating interest in things that are
>>>>> very complicated. This would be a fantastic demonstration.
>>>>>
>>>>>
>>>>> *Pros:*
>>>>> 1) Fast design testing and rejection
>>>>> 2) Rough to fine design... would arrive at a solution faster because it
>>>>> uses the "*Most*-*Constrained*-Variable-First" heuristic (such as has
>>>>> been used to solve the eternity puzzle... you solve the most constrained
>>>>> portion first to avoid having to try out many possibilities that will fail
>>>>> at the most constrained part).
>>>>> 3) Less pressure for practical applications and more focus on important
>>>>> AGI issues... this removes extra constraints that are not compatible with
>>>>> AGI constraints.
>>>>> 4) More man power because the design is less costly, less time
>>>>> consuming and requires less detail-oriented expertise.
>>>>> 5) Can you think of other pros?
>>>>>
>>>>> *Cons:*
>>>>> 1) People will make assumptions that are false and will delude
>>>>> themselves about these assumptions even if you point out flaws.
>>>>>
>>>>> I don't think there is anything we can do about this except for people
>>>>> that have not accepted the mistake to create different designs in parallel.
>>>>> If you disagree with someone, then you'll have to create another branch of
>>>>> the design or start a new design. At such a point, new comers will have to
>>>>> decide who is right and who is wrong and choose the project they believe in
>>>>> the most.
>>>>>
>>>>> 2) Important and honest assumptions may be wrong.
>>>>>
>>>>> I claim that this is ok because those assumptions would have been made
>>>>> anyway. At least many of these assumptions can be thrown out at the
>>>>> hypothetical stage before spending tons of time and money on a bad design.
>>>>> In addition, I think the work on the rest of the design will likely still be
>>>>> of value and will allow an implementation project to fix the assumption
>>>>> mistake and move on.
>>>>>
>>>>> 3) Often real world testing provides us with unexpected, new insights.
>>>>>
>>>>> While this is true, I don't think it's worth the down side of current
>>>>> approaches... which is that they take forever to fail and stay stuck on
>>>>> flawed designs, while trying to convince others that they are right.
>>>>>
>>>>>
>>>>> *Realistic Testing*
>>>>> I would also suggest to pretend that the pseudo design is a real design
>>>>> whenever it makes sense to do so. So, how do we decide when to go into
>>>>> detail and when not to? It depends on the value of that detail. If we can
>>>>> make reasonable assumptions and then keep moving forward with the design, we
>>>>> should. If we can't, then we need to go into more detail. Sometimes we might
>>>>> go into detail just because we can. But, what we shouldn't do is get stuck
>>>>> in detail that may have to change later on. We would be better served
>>>>> resolving the higher level portions of the design first (remember the "
>>>>> *Most*-*Constrained*-Variable-First" heuristic). It is extremely
>>>>> important to use this heuristic when working on such complicated design
>>>>> projects
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Dave
>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>>> <http://www.listbox.com/&gt;
>>>>>
>>>>
>>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>> <http://www.listbox.com&gt;
>>>
>>
>>
>

Jim,

I'm not clear on what type of problem or type of reasoning you would like to
simulate... so I'm a bit confused. You might have to be specific regarding a
problem that you would expect to be solved or a type of reasoning on an
example problem.

Dave

On Wed, Sep 1, 2010 at 5:53 PM, Jim Bromer <jimbromer@gmail.com> wrote:

> Assisted Simulation.
> I was just thinking that I could start with something real simple. By
> using arrays for all the global variables (and the transcripts and other
> data that needs to be saved), then when I was ready to quit, I could just
> save the variables that I used to resume where I left off. This would
> simplify the first stage of the test because I don't have to worry about
> disk access data structures during the initial test phase. I might start
> with concrete examples to test my ideas. Then I would throw slightly more
> complicated examples at the conceptual integration process. I would have to
> apply the higher intelligence but since I believe conceptual integration is
> directly involved with structures and relations that are necessary for
> intelligence, I would be defining a system that should exhibit
> emergent partial intelligence. If my test was successful, then some aspects
> of intelligence would be emergent so while I would still have to supply the
> higher intelligence the program should be able to take on some of the
> easier management of intelligence.
>
> Conceptual Integration involves both the data structures and the processes
> of knowledge. There may not be a clear distinction between data and process
> but it is not important. A concept will be an agglomeration of many
> different ideas or sub-ideas and will require the use of different kinds of
> processes and different relations to other concepts or sub-ideas depending
> on the context. Reasons will be used to determine the reasons behind the
> choice of operations and data objects. The program would not be able to
> know all the reasons why I would do something, and that's why I would have
> to supply the higher intelligence in the assisted simulation.
>
> My ideas about conceptual integration are not completely new, but I see it
> as part of the need for a much greater reliance on more sophisticated data
> structures, relations and processes than have been used in the past. Just
> as the different parts of a mathematical process play different roles in
> computational processes, different conceptual structures would play
> different kinds of roles in a conceptually integrated AGI program.
> Jim Bromer
>
> On Wed, Sep 1, 2010 at 4:57 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Jim,
>>
>> What are your conceptual integration ideas? I think it will depend on the
>> assumptions you want to make about concepts. I might have different
>> assumptions than you do. In a full AGI pseudo design, each level of
>> assumptions would also have to be tested. But, just for arguments sake, we
>> could try out conceptual integration by making assumptions to isolate it.
>>
>> Dave
>>
>> On Wed, Sep 1, 2010 at 4:48 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>
>>> David, Ok I understand what you are saying now. One of the mistakes made
>>> in simple simulations was in assuming (over and over again) that
>>> a successful simple test of a simple idea would be scalable.
>>>
>>> So how do I do a fast test of my conceptual integration ideas?
>>> Jim Bromer
>>>
>>> On Wed, Sep 1, 2010 at 4:39 PM, David Jones <davidhere40@gmail.com>wrote:
>>>
>>>> Jim,
>>>>
>>>> I mean pseudo simulation as if it were a real implementation. If this
>>>> has been done, where is the working pseudo simulation? If it is just in
>>>> people's heads and maybe they've tested problems on scratch paper, I don't
>>>> think that's enough. Even paper designs are not enough because that is
>>>> likely taking a frame out of a movie... it is hard to see what is really
>>>> happening. It would be much better to show a stick figure cartoon than to
>>>> give a single frame of that video. See the difference? The cartoon is the
>>>> sort of thing I'm talking about. It would not only allow visual
>>>> demonstration, but it also makes problems and inconsistencies pretty clear
>>>> before a real implementation is attempted. The problems are always more
>>>> clear when you go from a paper design to a simulation or implementation.
>>>>
>>>> These things could get so close to real implementations that you could
>>>> call it an actual simulation of some part of the system. But, such a
>>>> simulation seems better to me than trying to implement it because of the
>>>> massive amount of time required to even attempt an real implementation and
>>>> the likelihood that such an implementation may be wrong or not have enough
>>>> man power to be completed properly.
>>>>
>>>> The first problem I'm encountering is how to visualize and organize the
>>>> pseudo design intuitively and visually, but also allow for fake simulation
>>>> and other considerations. I can't think of a tool that would be just right.
>>>>
>>>> Dave
>>>>
>>>> On Wed, Sep 1, 2010 at 4:27 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>>>
>>>>> David,
>>>>> We are constantly planning, you have to test some of the theories
>>>>> against something. Many of us in this group have spent years
>>>>> pseudo-simulating our ideas for years. You have to keep moving and make it
>>>>> real. Conceptual integration, to the extent that I can explain it, can be
>>>>> tested on simple problems. If it scalable then it can be tested with more
>>>>> complicated problems. It can be pseudo simulated and veritably simulated as
>>>>> in an actual computer program. You have to do as much of both as possible
>>>>> if you want to be serious about this.
>>>>> Jim Bromer
>>>>>
>>>>>
>>>>> On Wed, Sep 1, 2010 at 3:15 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>>
>>>>>> Jim,
>>>>>>
>>>>>> Right, we might be missing important algorithms that we might need to
>>>>>> move forward on a design. But, we can make assumptions at various levels and
>>>>>> probably even assume that the algorithm works. We can estimate the risk that
>>>>>> it will work or won't work. We can see how the algorithm integrates with the
>>>>>> rest of the system.
>>>>>>
>>>>>> You may find out that even if the algorithm works, it won't do what
>>>>>> you wanted because the system fails at a different point. So, my point is to
>>>>>> avoid spending years on such a mistake and find it much faster through
>>>>>> pseudo testing. I see this precise mistake repeated over and over and over
>>>>>> again in AI.
>>>>>>
>>>>>> Most algorithms do not have to be implemented to test an AGI design.
>>>>>> People go about implementing things because they are in a hurry and we feel
>>>>>> better if we are working on something tangible. But, I think this problem's
>>>>>> extreme difficulties are going to force us to solve AGI hypothetically
>>>>>> before actually implementing it. If we implement it before having
>>>>>> sufficiently tested our ideas on hypotheticals, I think we will waste an
>>>>>> immense amount of time... in fact, we've already spent decades on failed AI
>>>>>> projects. How about a little better planning now?
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> On Wed, Sep 1, 2010 at 3:00 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>>>>
>>>>>>> Grammatical Correction:
>>>>>>> Now maybe my feeling that no one gets this is like Mike's presumption
>>>>>>> that no AGI'ers have ever used meta cognition to think about how they go
>>>>>>> about solving a problem as they worked on an actual problem, but I haven't
>>>>>>> seen anything beyond the most superficial assertion that people have
>>>>>>> considered conceptual integration in much detail.
>>>>>>>
>>>>>>> On Wed, Sep 1, 2010 at 2:57 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>>>>>
>>>>>>>> There is something missing. There are some algorithms that you
>>>>>>>> absolutely need that you don't have. My example of the lack of
>>>>>>>> sophisticated conceptual integration represents an extraordinary gap in my
>>>>>>>> thinking. (Freudian error. I meant to say something like, to my mind it
>>>>>>>> represents an extraordinary gap, but it errantly came out as a gap in my
>>>>>>>> thinking. However, I am able to acknowledge that there are aspects of
>>>>>>>> conceptual integration that I haven't figured out yet. That's why I wish it
>>>>>>>> was a topic that people would think about.) I think one person actually
>>>>>>>> discussed this idea with me in a way that suggests that he had any idea
>>>>>>>> about what I was talking about. I presume that every advanced AGI
>>>>>>>> conjecture includes some aspects of conceptual integration, but no one
>>>>>>>> actually converses with me in a way that would suggest that he actually gets
>>>>>>>> what I am talking about. Now maybe my feeling that no one gets this is like
>>>>>>>> Mike's presumption that no AGI'ers have never used meta cognition to think
>>>>>>>> about how they go about solving a problem after they have solve it, but I
>>>>>>>> haven't seen anything beyond the most superficial assertion that people had
>>>>>>>> thought about this.
>>>>>>>> Jim Bromer
>>>>>>>>
>>>>>>>> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> I've been to think lately that the solution to creating a realistic
>>>>>>>>> AGI design is psuedo design. What do I mean? Not simulation... not practical
>>>>>>>>> applications... not extremely detailed implementations. The design would
>>>>>>>>> start at a high level and go deeper into detail as possible.
>>>>>>>>>
>>>>>>>>> So, why would this be a solution? Well, before I mention the cons
>>>>>>>>> to this approach, consider the following:
>>>>>>>>>
>>>>>>>>> *Problems it would solve:*
>>>>>>>>> 1) There is no money and little interest for AGI. Even if you could
>>>>>>>>> get money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>>>>>>>>> supposed to be trying to get us money, not dissuade it. But, I really think
>>>>>>>>> we are repeating the mistakes of earlier researchers that promised too much
>>>>>>>>> on unjustified ideas. Then when they failed, it created AI winters, over and
>>>>>>>>> over and over again. History repeats itself.
>>>>>>>>>
>>>>>>>>> So, getting us more money would likely do harm in addition to too
>>>>>>>>> little good, the way it would be spent, for me to care. Extremely few people
>>>>>>>>> are interested in AGI and among those that are, their ideas about it are
>>>>>>>>> very, very flawed. We tend to approach the problem using our typical
>>>>>>>>> heuristics and problem solving techniques, but the problem is no longer
>>>>>>>>> amenable to these techniques. For example, the idea that patterns finding is
>>>>>>>>> sufficient for intelligence. It has not been proven beyond my reasonable
>>>>>>>>> arguments against it. Yet, people are getting funding and pursuing entire
>>>>>>>>> architectures based on it. Does that really make sense? Nope. We must pseudo
>>>>>>>>> test and pseudo design our algorithms first. Why? Because after spending
>>>>>>>>> several years on these designs that I can reasonably predict will fail with
>>>>>>>>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>>>>>>>>> much better off figuring that out earlier rather than later through fast
>>>>>>>>> prototyping techniques, such as the one I mentioned (pseudo design and
>>>>>>>>> testing)?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2) Implementations tend to get overwhelmed by the desire to show
>>>>>>>>> immediate results or achieve practical short-term goals. This completely
>>>>>>>>> throws off AGI implementations, because these other constraints are not
>>>>>>>>> compatible with more important AGI constraints.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3) We could find a solution much faster... AGI is a massively
>>>>>>>>> constrained CSP (Constraint Satisfaction Problem). The eternity puzzle is a
>>>>>>>>> great example of such a problem. If you approach the eternity puzzle using
>>>>>>>>> heuristics alone to generate a likely solution, such as how pretty the
>>>>>>>>> pattern is, or how plausible it is that the designers created this design,
>>>>>>>>> it is guaranteed to fail. This is especially true if it takes you even a few
>>>>>>>>> minutes to reject the design. The puzzle has so many possibilities that if
>>>>>>>>> you were to try to look at each one to see if it was a solution, it would
>>>>>>>>> literally take an eternity.
>>>>>>>>>
>>>>>>>>> So, how do you solve such problems? You start with the most
>>>>>>>>> constrained parts of the puzzle first, and you use heuristics to guide your
>>>>>>>>> search for solutions paths that are likely to contain a solution and avoid
>>>>>>>>> solutions paths that are less likely to contain a solution. Most
>>>>>>>>> importantly, you have to try a lot of solutions and reject the bad ones
>>>>>>>>> quickly, so that you can get to the right one. How does this apply to AGI?
>>>>>>>>> It's almost exactly the same. Current researchers are spending a lot of time
>>>>>>>>> on solutions that were generated using bad heuristics (unjustifiable human
>>>>>>>>> reasoning heuristics). Then they take forever to test them out (years)
>>>>>>>>> before they inevitably fail. A better way is to test solutions with as
>>>>>>>>> minimal effort and time as possible, such as by using pseudo design and
>>>>>>>>> testing techniques. This way you can settle onto the right solution path
>>>>>>>>> much, much faster and not waste time on a solution that clearly wouldn't
>>>>>>>>> work if you simply spent a bit more time analyzing it. Yes, such an approach
>>>>>>>>> has problems also, such as dishonesty or delusion in how the algorithms
>>>>>>>>> would actually work. I'll mention these more below. But, we have those
>>>>>>>>> delusions and problems already :) So, overall, this approach seems to be
>>>>>>>>> significantly better.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4) if we could show that a pseudo AGI design works in sufficient
>>>>>>>>> detail and with sufficient plausibility, it would likely change the minds
>>>>>>>>> of:
>>>>>>>>> -many people that don't think AGI is possible,
>>>>>>>>> -those that think it isn't possible in their lifetimes, and
>>>>>>>>> -those that think it isn't worth investing in.
>>>>>>>>> In other words... we would get the money, help and interest needed
>>>>>>>>> to make it happen. Demos are great at generating interest in things that are
>>>>>>>>> very complicated. This would be a fantastic demonstration.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Pros:*
>>>>>>>>> 1) Fast design testing and rejection
>>>>>>>>> 2) Rough to fine design... would arrive at a solution faster
>>>>>>>>> because it uses the "*Most*-*Constrained*-Variable-First"
>>>>>>>>> heuristic (such as has been used to solve the eternity puzzle... you solve
>>>>>>>>> the most constrained portion first to avoid having to try out many
>>>>>>>>> possibilities that will fail at the most constrained part).
>>>>>>>>> 3) Less pressure for practical applications and more focus on
>>>>>>>>> important AGI issues... this removes extra constraints that are not
>>>>>>>>> compatible with AGI constraints.
>>>>>>>>> 4) More man power because the design is less costly, less time
>>>>>>>>> consuming and requires less detail-oriented expertise.
>>>>>>>>> 5) Can you think of other pros?
>>>>>>>>>
>>>>>>>>> *Cons:*
>>>>>>>>> 1) People will make assumptions that are false and will delude
>>>>>>>>> themselves about these assumptions even if you point out flaws.
>>>>>>>>>
>>>>>>>>> I don't think there is anything we can do about this except for
>>>>>>>>> people that have not accepted the mistake to create different designs in
>>>>>>>>> parallel. If you disagree with someone, then you'll have to create another
>>>>>>>>> branch of the design or start a new design. At such a point, new comers will
>>>>>>>>> have to decide who is right and who is wrong and choose the project they
>>>>>>>>> believe in the most.
>>>>>>>>>
>>>>>>>>> 2) Important and honest assumptions may be wrong.
>>>>>>>>>
>>>>>>>>> I claim that this is ok because those assumptions would have been
>>>>>>>>> made anyway. At least many of these assumptions can be thrown out at the
>>>>>>>>> hypothetical stage before spending tons of time and money on a bad design.
>>>>>>>>> In addition, I think the work on the rest of the design will likely still be
>>>>>>>>> of value and will allow an implementation project to fix the assumption
>>>>>>>>> mistake and move on.
>>>>>>>>>
>>>>>>>>> 3) Often real world testing provides us with unexpected, new
>>>>>>>>> insights.
>>>>>>>>>
>>>>>>>>> While this is true, I don't think it's worth the down side of
>>>>>>>>> current approaches... which is that they take forever to fail and stay stuck
>>>>>>>>> on flawed designs, while trying to convince others that they are right.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Realistic Testing*
>>>>>>>>> I would also suggest to pretend that the pseudo design is a real
>>>>>>>>> design whenever it makes sense to do so. So, how do we decide when to go
>>>>>>>>> into detail and when not to? It depends on the value of that detail. If we
>>>>>>>>> can make reasonable assumptions and then keep moving forward with the
>>>>>>>>> design, we should. If we can't, then we need to go into more detail.
>>>>>>>>> Sometimes we might go into detail just because we can. But, what we
>>>>>>>>> shouldn't do is get stuck in detail that may have to change later on. We
>>>>>>>>> would be better served resolving the higher level portions of the design
>>>>>>>>> first (remember the "*Most*-*Constrained*-Variable-First"
>>>>>>>>> heuristic). It is extremely important to use this heuristic when working on
>>>>>>>>> such complicated design projects
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Dave
>>>>>>>>> *AGI* | Archives<https://www.listbox.com/member/archive/303/=now&gt;
>>>>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>>>>> <http://www.listbox.com/&gt;
>>>>>>>
>>>>>>
>>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>>>
>>>>>
>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>>> <http://www.listbox.com/&gt;
>>>>>
>>>>
>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>
>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>> <http://www.listbox.com/&gt;
>>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>

You won't be able to make Mike stop.

I don't read everything that is written in these groups either.


On Wed, Sep 1, 2010 at 5:18 PM, David Jones <davidhere40@gmail.com> wrote:

> Jim,
>
> I see... in that case, that sort of sounds beyond AGI, in the sense that
> not even generally intelligent people would know how to do it :)
>
> The reason I didn't see it before is because I don't read everything :) On
> occasion, I'll skim some, sometimes I'll ignore them altogether if the topic
> doesn't interest me. I decided to post back to Mike because he is constantly
> lecturing and I wanted to say something with the hope that he might stop. I
> mean, this mailing list is going to get pretty boring, annoying and
> monotonous if we have to listen to Mike's preaching in every other email.
>
> Dave
>
> On Wed, Sep 1, 2010 at 5:07 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>
>> David,
>> But you missed the point that I had made in a few previous comments. If
>> you actually started wondering how you would write a program to generate all
>> possible icons, just using twists and turns (and straight lines) would not
>> be enough because there is the issue of putting it all together and taking
>> advantage of other cool methods that were available. And then how do you
>> iterate through every possible variation? As I have been trying to explain,
>> that would crawl on for eons and be excruciatingly dull for anyone to
>> watch. You want to randomize the process in some way but still be able to
>> go off on some of the paths that are possible like learning from a previous
>> effort.
>>
>> I don't understand why you didn't occasionally wonder what I was talking
>> about in this thread. It's ok, its just a little odd because you have been
>> reading some of the thread.
>> Jim Bromer
>>
>> On Wed, Sep 1, 2010 at 4:52 PM, David Jones <davidhere40@gmail.com>wrote:
>>
>>> Jim,
>>>
>>> I was responding to mikes "Visual Object Recognition - recognize all
>>> those fonts as "A"" challenge....
>>>
>>> As for the generate a new font problem... sure, that could be considered
>>> an AGI problem if the AGI had experience. But the thing is, we don't program
>>> AGI's with that sort of experience from the beginning. It doesn't make sense
>>> as an AGI problem because that assume that the AGI should be able to perform
>>> such feats without other general abilities and quite a bit of experience to
>>> draw from. This assumption is required because I can't just say well the AI
>>> has drawing experience and bla bla bla. Because mike will yell bullshit and
>>> mysticism. But the truth is that drawing and such creativity DOES draw on a
>>> lot of experience. So, to make it a fundamental problem doesn't make one wit
>>> of sense.
>>>
>>> But, for arguments sake... let's assume that I had to suggest how an AI
>>> might do this.... Well, I could say that the AI has the ability to perform
>>> trial and error actions. It attempts something and then evaluates it. It is
>>> able to recognize fonts in similar ways that humans do, so it will recognize
>>> when a font has the right properties to be recognized by other people as an
>>> A. It might know that nice twists and curves are kinda cool and creative
>>> because it has seen them before. It might know that AI's typically have
>>> certain major features such as the lowercase version has a large curve from
>>> the top-right to the left-middle and then down to the bottom-right. It also
>>> typically has a curving line from the top-right to the bottom-right. So,
>>> given all these "creative" ideas, it could start trial and error generation
>>> of new fonts using a search for ideas from past experience as well as just
>>> acting out rough to fine motor commands. All the while the AI is evaluating
>>> whether the evolving form is going to have the patterns that a person would
>>> expect of an "A", which is could recognize. If it creates a pattern that it
>>> feels should be rejected because it probably wouldn't be evaluated as an
>>> "A", then it would erase and try again, etc.
>>>
>>> You see? There is an immense amount of trial and error, as well as very
>>> complicated general reasoning going on. Why in the world would I start with
>>> that problem when building AGI? I certainly wouldn't. It's a nice example to
>>> keep in mind and analyze. But it is certainly not the most fundamental
>>> problem I would want to think about. If I designed specifically for this, I
>>> would likely over engineer a solution that doesn't make sense for most other
>>> problems.
>>>
>>> Dave
>>>
>>> On Wed, Sep 1, 2010 at 4:38 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>
>>>> David,
>>>> You are missing something here. While it is impossible for a program or
>>>> a person to "design" every possible font without any realistic contextual
>>>> cues, inforation and experience, and it would therefore be a waste of
>>>> time to try, it is not a waste of time to try to consider what kind of
>>>> program would be needed to have the potential to design any kind of font.
>>>> Such a process cannot be intelligently done just by copying fonts from other
>>>> sources for example, so it becomes very relevant to at least start thinking
>>>> about what kind of knowledge structures would be necessary to maximize the
>>>> potential for it to learn.
>>>>
>>>> I am considering the problem from the point of view of whether or not I
>>>> can write a closed program that can produce such a vast number of variations
>>>> of an icon, because in solving the problem I have seen that I can get a
>>>> better handle on the nature of the data structures and relations between
>>>> data objects might be needed for a better designed AGI program.
>>>>
>>>> I realize that Mike has no idea about what I am talking about, but I
>>>> am surprised that you don't get it.
>>>>
>>>> Jim Bromer
>>>>
>>>> On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>
>>>>> Mike,
>>>>
>>>> Have you ever considered that maybe it is impractical and irrational
>>>>> to design an AGI system to recognize all possible fonts for "a" without any
>>>>> realistic contextual cues, info and experience? Did you ever consider that
>>>>> maybe that's the dumbest way to design an AGI ever?
>>>>>
>>>>> People can't take any possible random and unexpected pattern out of
>>>>> context and figure out what it is. Intelligence doesn't work that way. We
>>>>> use cues to twist what we see into what we expect. If you could see out of
>>>>> your tunnel, you might realize this.
>>>>>
>>>>> So, recognizing any possible "a" font is not a realistic or pragmatic
>>>>> AGI problem. And I would be an idiot to spend any time trying to solve it.
>>>>>
>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>> <http://www.listbox.com/&gt;
>>>>
>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com/&gt;
>

Assisted Simulation.
I was just thinking that I could start with something real simple. By using
arrays for all the global variables (and the transcripts and other data that
needs to be saved), then when I was ready to quit, I could just save the
variables that I used to resume where I left off. This would simplify the
first stage of the test because I don't have to worry about disk access data
structures during the initial test phase. I might start with concrete
examples to test my ideas. Then I would throw slightly more complicated
examples at the conceptual integration process. I would have to apply the
higher intelligence but since I believe conceptual integration is directly
involved with structures and relations that are necessary for intelligence,
I would be defining a system that should exhibit emergent partial
intelligence. If my test was successful, then some aspects of intelligence
would be emergent so while I would still have to supply the higher
intelligence the program should be able to take on some of the
easier management of intelligence.

Conceptual Integration involves both the data structures and the processes
of knowledge. There may not be a clear distinction between data and process
but it is not important. A concept will be an agglomeration of many
different ideas or sub-ideas and will require the use of different kinds of
processes and different relations to other concepts or sub-ideas depending
on the context. Reasons will be used to determine the reasons behind the
choice of operations and data objects. The program would not be able to
know all the reasons why I would do something, and that's why I would have
to supply the higher intelligence in the assisted simulation.

My ideas about conceptual integration are not completely new, but I see it
as part of the need for a much greater reliance on more sophisticated data
structures, relations and processes than have been used in the past. Just
as the different parts of a mathematical process play different roles in
computational processes, different conceptual structures would play
different kinds of roles in a conceptually integrated AGI program.
Jim Bromer

On Wed, Sep 1, 2010 at 4:57 PM, David Jones <davidhere40@gmail.com> wrote:

> Jim,
>
> What are your conceptual integration ideas? I think it will depend on the
> assumptions you want to make about concepts. I might have different
> assumptions than you do. In a full AGI pseudo design, each level of
> assumptions would also have to be tested. But, just for arguments sake, we
> could try out conceptual integration by making assumptions to isolate it.
>
> Dave
>
> On Wed, Sep 1, 2010 at 4:48 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>
>> David, Ok I understand what you are saying now. One of the mistakes made
>> in simple simulations was in assuming (over and over again) that
>> a successful simple test of a simple idea would be scalable.
>>
>> So how do I do a fast test of my conceptual integration ideas?
>> Jim Bromer
>>
>> On Wed, Sep 1, 2010 at 4:39 PM, David Jones <davidhere40@gmail.com>wrote:
>>
>>> Jim,
>>>
>>> I mean pseudo simulation as if it were a real implementation. If this has
>>> been done, where is the working pseudo simulation? If it is just in people's
>>> heads and maybe they've tested problems on scratch paper, I don't think
>>> that's enough. Even paper designs are not enough because that is likely
>>> taking a frame out of a movie... it is hard to see what is really happening.
>>> It would be much better to show a stick figure cartoon than to give a single
>>> frame of that video. See the difference? The cartoon is the sort of thing
>>> I'm talking about. It would not only allow visual demonstration, but it also
>>> makes problems and inconsistencies pretty clear before a real implementation
>>> is attempted. The problems are always more clear when you go from a paper
>>> design to a simulation or implementation.
>>>
>>> These things could get so close to real implementations that you could
>>> call it an actual simulation of some part of the system. But, such a
>>> simulation seems better to me than trying to implement it because of the
>>> massive amount of time required to even attempt an real implementation and
>>> the likelihood that such an implementation may be wrong or not have enough
>>> man power to be completed properly.
>>>
>>> The first problem I'm encountering is how to visualize and organize the
>>> pseudo design intuitively and visually, but also allow for fake simulation
>>> and other considerations. I can't think of a tool that would be just right.
>>>
>>> Dave
>>>
>>> On Wed, Sep 1, 2010 at 4:27 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>>
>>>> David,
>>>> We are constantly planning, you have to test some of the theories
>>>> against something. Many of us in this group have spent years
>>>> pseudo-simulating our ideas for years. You have to keep moving and make it
>>>> real. Conceptual integration, to the extent that I can explain it, can be
>>>> tested on simple problems. If it scalable then it can be tested with more
>>>> complicated problems. It can be pseudo simulated and veritably simulated as
>>>> in an actual computer program. You have to do as much of both as possible
>>>> if you want to be serious about this.
>>>> Jim Bromer
>>>>
>>>>
>>>> On Wed, Sep 1, 2010 at 3:15 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>
>>>>> Jim,
>>>>>
>>>>> Right, we might be missing important algorithms that we might need to
>>>>> move forward on a design. But, we can make assumptions at various levels and
>>>>> probably even assume that the algorithm works. We can estimate the risk that
>>>>> it will work or won't work. We can see how the algorithm integrates with the
>>>>> rest of the system.
>>>>>
>>>>> You may find out that even if the algorithm works, it won't do what you
>>>>> wanted because the system fails at a different point. So, my point is to
>>>>> avoid spending years on such a mistake and find it much faster through
>>>>> pseudo testing. I see this precise mistake repeated over and over and over
>>>>> again in AI.
>>>>>
>>>>> Most algorithms do not have to be implemented to test an AGI design.
>>>>> People go about implementing things because they are in a hurry and we feel
>>>>> better if we are working on something tangible. But, I think this problem's
>>>>> extreme difficulties are going to force us to solve AGI hypothetically
>>>>> before actually implementing it. If we implement it before having
>>>>> sufficiently tested our ideas on hypotheticals, I think we will waste an
>>>>> immense amount of time... in fact, we've already spent decades on failed AI
>>>>> projects. How about a little better planning now?
>>>>>
>>>>> Dave
>>>>>
>>>>> On Wed, Sep 1, 2010 at 3:00 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>>>
>>>>>> Grammatical Correction:
>>>>>> Now maybe my feeling that no one gets this is like Mike's presumption
>>>>>> that no AGI'ers have ever used meta cognition to think about how they go
>>>>>> about solving a problem as they worked on an actual problem, but I haven't
>>>>>> seen anything beyond the most superficial assertion that people have
>>>>>> considered conceptual integration in much detail.
>>>>>>
>>>>>> On Wed, Sep 1, 2010 at 2:57 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>>>>
>>>>>>> There is something missing. There are some algorithms that you
>>>>>>> absolutely need that you don't have. My example of the lack of
>>>>>>> sophisticated conceptual integration represents an extraordinary gap in my
>>>>>>> thinking. (Freudian error. I meant to say something like, to my mind it
>>>>>>> represents an extraordinary gap, but it errantly came out as a gap in my
>>>>>>> thinking. However, I am able to acknowledge that there are aspects of
>>>>>>> conceptual integration that I haven't figured out yet. That's why I wish it
>>>>>>> was a topic that people would think about.) I think one person actually
>>>>>>> discussed this idea with me in a way that suggests that he had any idea
>>>>>>> about what I was talking about. I presume that every advanced AGI
>>>>>>> conjecture includes some aspects of conceptual integration, but no one
>>>>>>> actually converses with me in a way that would suggest that he actually gets
>>>>>>> what I am talking about. Now maybe my feeling that no one gets this is like
>>>>>>> Mike's presumption that no AGI'ers have never used meta cognition to think
>>>>>>> about how they go about solving a problem after they have solve it, but I
>>>>>>> haven't seen anything beyond the most superficial assertion that people had
>>>>>>> thought about this.
>>>>>>> Jim Bromer
>>>>>>>
>>>>>>> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>>>>
>>>>>>>> I've been to think lately that the solution to creating a realistic
>>>>>>>> AGI design is psuedo design. What do I mean? Not simulation... not practical
>>>>>>>> applications... not extremely detailed implementations. The design would
>>>>>>>> start at a high level and go deeper into detail as possible.
>>>>>>>>
>>>>>>>> So, why would this be a solution? Well, before I mention the cons to
>>>>>>>> this approach, consider the following:
>>>>>>>>
>>>>>>>> *Problems it would solve:*
>>>>>>>> 1) There is no money and little interest for AGI. Even if you could
>>>>>>>> get money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>>>>>>>> supposed to be trying to get us money, not dissuade it. But, I really think
>>>>>>>> we are repeating the mistakes of earlier researchers that promised too much
>>>>>>>> on unjustified ideas. Then when they failed, it created AI winters, over and
>>>>>>>> over and over again. History repeats itself.
>>>>>>>>
>>>>>>>> So, getting us more money would likely do harm in addition to too
>>>>>>>> little good, the way it would be spent, for me to care. Extremely few people
>>>>>>>> are interested in AGI and among those that are, their ideas about it are
>>>>>>>> very, very flawed. We tend to approach the problem using our typical
>>>>>>>> heuristics and problem solving techniques, but the problem is no longer
>>>>>>>> amenable to these techniques. For example, the idea that patterns finding is
>>>>>>>> sufficient for intelligence. It has not been proven beyond my reasonable
>>>>>>>> arguments against it. Yet, people are getting funding and pursuing entire
>>>>>>>> architectures based on it. Does that really make sense? Nope. We must pseudo
>>>>>>>> test and pseudo design our algorithms first. Why? Because after spending
>>>>>>>> several years on these designs that I can reasonably predict will fail with
>>>>>>>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>>>>>>>> much better off figuring that out earlier rather than later through fast
>>>>>>>> prototyping techniques, such as the one I mentioned (pseudo design and
>>>>>>>> testing)?
>>>>>>>>
>>>>>>>>
>>>>>>>> 2) Implementations tend to get overwhelmed by the desire to show
>>>>>>>> immediate results or achieve practical short-term goals. This completely
>>>>>>>> throws off AGI implementations, because these other constraints are not
>>>>>>>> compatible with more important AGI constraints.
>>>>>>>>
>>>>>>>>
>>>>>>>> 3) We could find a solution much faster... AGI is a massively
>>>>>>>> constrained CSP (Constraint Satisfaction Problem). The eternity puzzle is a
>>>>>>>> great example of such a problem. If you approach the eternity puzzle using
>>>>>>>> heuristics alone to generate a likely solution, such as how pretty the
>>>>>>>> pattern is, or how plausible it is that the designers created this design,
>>>>>>>> it is guaranteed to fail. This is especially true if it takes you even a few
>>>>>>>> minutes to reject the design. The puzzle has so many possibilities that if
>>>>>>>> you were to try to look at each one to see if it was a solution, it would
>>>>>>>> literally take an eternity.
>>>>>>>>
>>>>>>>> So, how do you solve such problems? You start with the most
>>>>>>>> constrained parts of the puzzle first, and you use heuristics to guide your
>>>>>>>> search for solutions paths that are likely to contain a solution and avoid
>>>>>>>> solutions paths that are less likely to contain a solution. Most
>>>>>>>> importantly, you have to try a lot of solutions and reject the bad ones
>>>>>>>> quickly, so that you can get to the right one. How does this apply to AGI?
>>>>>>>> It's almost exactly the same. Current researchers are spending a lot of time
>>>>>>>> on solutions that were generated using bad heuristics (unjustifiable human
>>>>>>>> reasoning heuristics). Then they take forever to test them out (years)
>>>>>>>> before they inevitably fail. A better way is to test solutions with as
>>>>>>>> minimal effort and time as possible, such as by using pseudo design and
>>>>>>>> testing techniques. This way you can settle onto the right solution path
>>>>>>>> much, much faster and not waste time on a solution that clearly wouldn't
>>>>>>>> work if you simply spent a bit more time analyzing it. Yes, such an approach
>>>>>>>> has problems also, such as dishonesty or delusion in how the algorithms
>>>>>>>> would actually work. I'll mention these more below. But, we have those
>>>>>>>> delusions and problems already :) So, overall, this approach seems to be
>>>>>>>> significantly better.
>>>>>>>>
>>>>>>>>
>>>>>>>> 4) if we could show that a pseudo AGI design works in sufficient
>>>>>>>> detail and with sufficient plausibility, it would likely change the minds
>>>>>>>> of:
>>>>>>>> -many people that don't think AGI is possible,
>>>>>>>> -those that think it isn't possible in their lifetimes, and
>>>>>>>> -those that think it isn't worth investing in.
>>>>>>>> In other words... we would get the money, help and interest needed
>>>>>>>> to make it happen. Demos are great at generating interest in things that are
>>>>>>>> very complicated. This would be a fantastic demonstration.
>>>>>>>>
>>>>>>>>
>>>>>>>> *Pros:*
>>>>>>>> 1) Fast design testing and rejection
>>>>>>>> 2) Rough to fine design... would arrive at a solution faster because
>>>>>>>> it uses the "*Most*-*Constrained*-Variable-First" heuristic (such
>>>>>>>> as has been used to solve the eternity puzzle... you solve the most
>>>>>>>> constrained portion first to avoid having to try out many possibilities that
>>>>>>>> will fail at the most constrained part).
>>>>>>>> 3) Less pressure for practical applications and more focus on
>>>>>>>> important AGI issues... this removes extra constraints that are not
>>>>>>>> compatible with AGI constraints.
>>>>>>>> 4) More man power because the design is less costly, less time
>>>>>>>> consuming and requires less detail-oriented expertise.
>>>>>>>> 5) Can you think of other pros?
>>>>>>>>
>>>>>>>> *Cons:*
>>>>>>>> 1) People will make assumptions that are false and will delude
>>>>>>>> themselves about these assumptions even if you point out flaws.
>>>>>>>>
>>>>>>>> I don't think there is anything we can do about this except for
>>>>>>>> people that have not accepted the mistake to create different designs in
>>>>>>>> parallel. If you disagree with someone, then you'll have to create another
>>>>>>>> branch of the design or start a new design. At such a point, new comers will
>>>>>>>> have to decide who is right and who is wrong and choose the project they
>>>>>>>> believe in the most.
>>>>>>>>
>>>>>>>> 2) Important and honest assumptions may be wrong.
>>>>>>>>
>>>>>>>> I claim that this is ok because those assumptions would have been
>>>>>>>> made anyway. At least many of these assumptions can be thrown out at the
>>>>>>>> hypothetical stage before spending tons of time and money on a bad design.
>>>>>>>> In addition, I think the work on the rest of the design will likely still be
>>>>>>>> of value and will allow an implementation project to fix the assumption
>>>>>>>> mistake and move on.
>>>>>>>>
>>>>>>>> 3) Often real world testing provides us with unexpected, new
>>>>>>>> insights.
>>>>>>>>
>>>>>>>> While this is true, I don't think it's worth the down side of
>>>>>>>> current approaches... which is that they take forever to fail and stay stuck
>>>>>>>> on flawed designs, while trying to convince others that they are right.
>>>>>>>>
>>>>>>>>
>>>>>>>> *Realistic Testing*
>>>>>>>> I would also suggest to pretend that the pseudo design is a real
>>>>>>>> design whenever it makes sense to do so. So, how do we decide when to go
>>>>>>>> into detail and when not to? It depends on the value of that detail. If we
>>>>>>>> can make reasonable assumptions and then keep moving forward with the
>>>>>>>> design, we should. If we can't, then we need to go into more detail.
>>>>>>>> Sometimes we might go into detail just because we can. But, what we
>>>>>>>> shouldn't do is get stuck in detail that may have to change later on. We
>>>>>>>> would be better served resolving the higher level portions of the design
>>>>>>>> first (remember the "*Most*-*Constrained*-Variable-First"
>>>>>>>> heuristic). It is extremely important to use this heuristic when working on
>>>>>>>> such complicated design projects
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Dave
>>>>>>>> *AGI* | Archives<https://www.listbox.com/member/archive/303/=now&gt;
>>>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>>>> <http://www.listbox.com/&gt;
>>>>>>
>>>>>
>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>>
>>>>
>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>> <http://www.listbox.com/&gt;
>>>>
>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com/&gt;
>

Jim,

I see... in that case, that sort of sounds beyond AGI, in the sense that not
even generally intelligent people would know how to do it :)

The reason I didn't see it before is because I don't read everything :) On
occasion, I'll skim some, sometimes I'll ignore them altogether if the topic
doesn't interest me. I decided to post back to Mike because he is constantly
lecturing and I wanted to say something with the hope that he might stop. I
mean, this mailing list is going to get pretty boring, annoying and
monotonous if we have to listen to Mike's preaching in every other email.

Dave

On Wed, Sep 1, 2010 at 5:07 PM, Jim Bromer <jimbromer@gmail.com> wrote:

> David,
> But you missed the point that I had made in a few previous comments. If
> you actually started wondering how you would write a program to generate all
> possible icons, just using twists and turns (and straight lines) would not
> be enough because there is the issue of putting it all together and taking
> advantage of other cool methods that were available. And then how do you
> iterate through every possible variation? As I have been trying to explain,
> that would crawl on for eons and be excruciatingly dull for anyone to
> watch. You want to randomize the process in some way but still be able to
> go off on some of the paths that are possible like learning from a previous
> effort.
>
> I don't understand why you didn't occasionally wonder what I was talking
> about in this thread. It's ok, its just a little odd because you have been
> reading some of the thread.
> Jim Bromer
>
> On Wed, Sep 1, 2010 at 4:52 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Jim,
>>
>> I was responding to mikes "Visual Object Recognition - recognize all
>> those fonts as "A"" challenge....
>>
>> As for the generate a new font problem... sure, that could be considered
>> an AGI problem if the AGI had experience. But the thing is, we don't program
>> AGI's with that sort of experience from the beginning. It doesn't make sense
>> as an AGI problem because that assume that the AGI should be able to perform
>> such feats without other general abilities and quite a bit of experience to
>> draw from. This assumption is required because I can't just say well the AI
>> has drawing experience and bla bla bla. Because mike will yell bullshit and
>> mysticism. But the truth is that drawing and such creativity DOES draw on a
>> lot of experience. So, to make it a fundamental problem doesn't make one wit
>> of sense.
>>
>> But, for arguments sake... let's assume that I had to suggest how an AI
>> might do this.... Well, I could say that the AI has the ability to perform
>> trial and error actions. It attempts something and then evaluates it. It is
>> able to recognize fonts in similar ways that humans do, so it will recognize
>> when a font has the right properties to be recognized by other people as an
>> A. It might know that nice twists and curves are kinda cool and creative
>> because it has seen them before. It might know that AI's typically have
>> certain major features such as the lowercase version has a large curve from
>> the top-right to the left-middle and then down to the bottom-right. It also
>> typically has a curving line from the top-right to the bottom-right. So,
>> given all these "creative" ideas, it could start trial and error generation
>> of new fonts using a search for ideas from past experience as well as just
>> acting out rough to fine motor commands. All the while the AI is evaluating
>> whether the evolving form is going to have the patterns that a person would
>> expect of an "A", which is could recognize. If it creates a pattern that it
>> feels should be rejected because it probably wouldn't be evaluated as an
>> "A", then it would erase and try again, etc.
>>
>> You see? There is an immense amount of trial and error, as well as very
>> complicated general reasoning going on. Why in the world would I start with
>> that problem when building AGI? I certainly wouldn't. It's a nice example to
>> keep in mind and analyze. But it is certainly not the most fundamental
>> problem I would want to think about. If I designed specifically for this, I
>> would likely over engineer a solution that doesn't make sense for most other
>> problems.
>>
>> Dave
>>
>> On Wed, Sep 1, 2010 at 4:38 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>
>>> David,
>>> You are missing something here. While it is impossible for a program or
>>> a person to "design" every possible font without any realistic contextual
>>> cues, inforation and experience, and it would therefore be a waste of
>>> time to try, it is not a waste of time to try to consider what kind of
>>> program would be needed to have the potential to design any kind of font.
>>> Such a process cannot be intelligently done just by copying fonts from other
>>> sources for example, so it becomes very relevant to at least start thinking
>>> about what kind of knowledge structures would be necessary to maximize the
>>> potential for it to learn.
>>>
>>> I am considering the problem from the point of view of whether or not I
>>> can write a closed program that can produce such a vast number of variations
>>> of an icon, because in solving the problem I have seen that I can get a
>>> better handle on the nature of the data structures and relations between
>>> data objects might be needed for a better designed AGI program.
>>>
>>> I realize that Mike has no idea about what I am talking about, but I
>>> am surprised that you don't get it.
>>>
>>> Jim Bromer
>>>
>>> On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com>wrote:
>>>
>>>> Mike,
>>>
>>> Have you ever considered that maybe it is impractical and irrational to
>>>> design an AGI system to recognize all possible fonts for "a" without any
>>>> realistic contextual cues, info and experience? Did you ever consider that
>>>> maybe that's the dumbest way to design an AGI ever?
>>>>
>>>> People can't take any possible random and unexpected pattern out of
>>>> context and figure out what it is. Intelligence doesn't work that way. We
>>>> use cues to twist what we see into what we expect. If you could see out of
>>>> your tunnel, you might realize this.
>>>>
>>>> So, recognizing any possible "a" font is not a realistic or pragmatic
>>>> AGI problem. And I would be an idiot to spend any time trying to solve it.
>>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>> <http://www.listbox.com/&gt;
>>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>

David,
But you missed the point that I had made in a few previous comments. If you
actually started wondering how you would write a program to generate all
possible icons, just using twists and turns (and straight lines) would not
be enough because there is the issue of putting it all together and taking
advantage of other cool methods that were available. And then how do you
iterate through every possible variation? As I have been trying to explain,
that would crawl on for eons and be excruciatingly dull for anyone to
watch. You want to randomize the process in some way but still be able to
go off on some of the paths that are possible like learning from a previous
effort.

I don't understand why you didn't occasionally wonder what I was talking
about in this thread. It's ok, its just a little odd because you have been
reading some of the thread.
Jim Bromer

On Wed, Sep 1, 2010 at 4:52 PM, David Jones <davidhere40@gmail.com> wrote:

> Jim,
>
> I was responding to mikes "Visual Object Recognition - recognize all those
> fonts as "A"" challenge....
>
> As for the generate a new font problem... sure, that could be considered an
> AGI problem if the AGI had experience. But the thing is, we don't program
> AGI's with that sort of experience from the beginning. It doesn't make sense
> as an AGI problem because that assume that the AGI should be able to perform
> such feats without other general abilities and quite a bit of experience to
> draw from. This assumption is required because I can't just say well the AI
> has drawing experience and bla bla bla. Because mike will yell bullshit and
> mysticism. But the truth is that drawing and such creativity DOES draw on a
> lot of experience. So, to make it a fundamental problem doesn't make one wit
> of sense.
>
> But, for arguments sake... let's assume that I had to suggest how an AI
> might do this.... Well, I could say that the AI has the ability to perform
> trial and error actions. It attempts something and then evaluates it. It is
> able to recognize fonts in similar ways that humans do, so it will recognize
> when a font has the right properties to be recognized by other people as an
> A. It might know that nice twists and curves are kinda cool and creative
> because it has seen them before. It might know that AI's typically have
> certain major features such as the lowercase version has a large curve from
> the top-right to the left-middle and then down to the bottom-right. It also
> typically has a curving line from the top-right to the bottom-right. So,
> given all these "creative" ideas, it could start trial and error generation
> of new fonts using a search for ideas from past experience as well as just
> acting out rough to fine motor commands. All the while the AI is evaluating
> whether the evolving form is going to have the patterns that a person would
> expect of an "A", which is could recognize. If it creates a pattern that it
> feels should be rejected because it probably wouldn't be evaluated as an
> "A", then it would erase and try again, etc.
>
> You see? There is an immense amount of trial and error, as well as very
> complicated general reasoning going on. Why in the world would I start with
> that problem when building AGI? I certainly wouldn't. It's a nice example to
> keep in mind and analyze. But it is certainly not the most fundamental
> problem I would want to think about. If I designed specifically for this, I
> would likely over engineer a solution that doesn't make sense for most other
> problems.
>
> Dave
>
> On Wed, Sep 1, 2010 at 4:38 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>
>> David,
>> You are missing something here. While it is impossible for a program or a
>> person to "design" every possible font without any realistic contextual
>> cues, inforation and experience, and it would therefore be a waste of
>> time to try, it is not a waste of time to try to consider what kind of
>> program would be needed to have the potential to design any kind of font.
>> Such a process cannot be intelligently done just by copying fonts from other
>> sources for example, so it becomes very relevant to at least start thinking
>> about what kind of knowledge structures would be necessary to maximize the
>> potential for it to learn.
>>
>> I am considering the problem from the point of view of whether or not I
>> can write a closed program that can produce such a vast number of variations
>> of an icon, because in solving the problem I have seen that I can get a
>> better handle on the nature of the data structures and relations between
>> data objects might be needed for a better designed AGI program.
>>
>> I realize that Mike has no idea about what I am talking about, but I
>> am surprised that you don't get it.
>>
>> Jim Bromer
>>
>> On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com>wrote:
>>
>>> Mike,
>>
>> Have you ever considered that maybe it is impractical and irrational to
>>> design an AGI system to recognize all possible fonts for "a" without any
>>> realistic contextual cues, info and experience? Did you ever consider that
>>> maybe that's the dumbest way to design an AGI ever?
>>>
>>> People can't take any possible random and unexpected pattern out of
>>> context and figure out what it is. Intelligence doesn't work that way. We
>>> use cues to twist what we see into what we expect. If you could see out of
>>> your tunnel, you might realize this.
>>>
>>> So, recognizing any possible "a" font is not a realistic or pragmatic AGI
>>> problem. And I would be an idiot to spend any time trying to solve it.
>>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com/&gt;
>

Jim,

What are your conceptual integration ideas? I think it will depend on the
assumptions you want to make about concepts. I might have different
assumptions than you do. In a full AGI pseudo design, each level of
assumptions would also have to be tested. But, just for arguments sake, we
could try out conceptual integration by making assumptions to isolate it.

Dave

On Wed, Sep 1, 2010 at 4:48 PM, Jim Bromer <jimbromer@gmail.com> wrote:

> David, Ok I understand what you are saying now. One of the mistakes made
> in simple simulations was in assuming (over and over again) that
> a successful simple test of a simple idea would be scalable.
>
> So how do I do a fast test of my conceptual integration ideas?
> Jim Bromer
>
> On Wed, Sep 1, 2010 at 4:39 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Jim,
>>
>> I mean pseudo simulation as if it were a real implementation. If this has
>> been done, where is the working pseudo simulation? If it is just in people's
>> heads and maybe they've tested problems on scratch paper, I don't think
>> that's enough. Even paper designs are not enough because that is likely
>> taking a frame out of a movie... it is hard to see what is really happening.
>> It would be much better to show a stick figure cartoon than to give a single
>> frame of that video. See the difference? The cartoon is the sort of thing
>> I'm talking about. It would not only allow visual demonstration, but it also
>> makes problems and inconsistencies pretty clear before a real implementation
>> is attempted. The problems are always more clear when you go from a paper
>> design to a simulation or implementation.
>>
>> These things could get so close to real implementations that you could
>> call it an actual simulation of some part of the system. But, such a
>> simulation seems better to me than trying to implement it because of the
>> massive amount of time required to even attempt an real implementation and
>> the likelihood that such an implementation may be wrong or not have enough
>> man power to be completed properly.
>>
>> The first problem I'm encountering is how to visualize and organize the
>> pseudo design intuitively and visually, but also allow for fake simulation
>> and other considerations. I can't think of a tool that would be just right.
>>
>> Dave
>>
>> On Wed, Sep 1, 2010 at 4:27 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>
>>> David,
>>> We are constantly planning, you have to test some of the theories against
>>> something. Many of us in this group have spent years pseudo-simulating our
>>> ideas for years. You have to keep moving and make it real. Conceptual
>>> integration, to the extent that I can explain it, can be tested on simple
>>> problems. If it scalable then it can be tested with more complicated
>>> problems. It can be pseudo simulated and veritably simulated as in an
>>> actual computer program. You have to do as much of both as possible if you
>>> want to be serious about this.
>>> Jim Bromer
>>>
>>>
>>> On Wed, Sep 1, 2010 at 3:15 PM, David Jones <davidhere40@gmail.com>wrote:
>>>
>>>> Jim,
>>>>
>>>> Right, we might be missing important algorithms that we might need to
>>>> move forward on a design. But, we can make assumptions at various levels and
>>>> probably even assume that the algorithm works. We can estimate the risk that
>>>> it will work or won't work. We can see how the algorithm integrates with the
>>>> rest of the system.
>>>>
>>>> You may find out that even if the algorithm works, it won't do what you
>>>> wanted because the system fails at a different point. So, my point is to
>>>> avoid spending years on such a mistake and find it much faster through
>>>> pseudo testing. I see this precise mistake repeated over and over and over
>>>> again in AI.
>>>>
>>>> Most algorithms do not have to be implemented to test an AGI design.
>>>> People go about implementing things because they are in a hurry and we feel
>>>> better if we are working on something tangible. But, I think this problem's
>>>> extreme difficulties are going to force us to solve AGI hypothetically
>>>> before actually implementing it. If we implement it before having
>>>> sufficiently tested our ideas on hypotheticals, I think we will waste an
>>>> immense amount of time... in fact, we've already spent decades on failed AI
>>>> projects. How about a little better planning now?
>>>>
>>>> Dave
>>>>
>>>> On Wed, Sep 1, 2010 at 3:00 PM, Jim Bromer <jimbromer@gmail.com> wrote:
>>>>
>>>>> Grammatical Correction:
>>>>> Now maybe my feeling that no one gets this is like Mike's presumption
>>>>> that no AGI'ers have ever used meta cognition to think about how they go
>>>>> about solving a problem as they worked on an actual problem, but I haven't
>>>>> seen anything beyond the most superficial assertion that people have
>>>>> considered conceptual integration in much detail.
>>>>>
>>>>> On Wed, Sep 1, 2010 at 2:57 PM, Jim Bromer <jimbromer@gmail.com>wrote:
>>>>>
>>>>>> There is something missing. There are some algorithms that you
>>>>>> absolutely need that you don't have. My example of the lack of
>>>>>> sophisticated conceptual integration represents an extraordinary gap in my
>>>>>> thinking. (Freudian error. I meant to say something like, to my mind it
>>>>>> represents an extraordinary gap, but it errantly came out as a gap in my
>>>>>> thinking. However, I am able to acknowledge that there are aspects of
>>>>>> conceptual integration that I haven't figured out yet. That's why I wish it
>>>>>> was a topic that people would think about.) I think one person actually
>>>>>> discussed this idea with me in a way that suggests that he had any idea
>>>>>> about what I was talking about. I presume that every advanced AGI
>>>>>> conjecture includes some aspects of conceptual integration, but no one
>>>>>> actually converses with me in a way that would suggest that he actually gets
>>>>>> what I am talking about. Now maybe my feeling that no one gets this is like
>>>>>> Mike's presumption that no AGI'ers have never used meta cognition to think
>>>>>> about how they go about solving a problem after they have solve it, but I
>>>>>> haven't seen anything beyond the most superficial assertion that people had
>>>>>> thought about this.
>>>>>> Jim Bromer
>>>>>>
>>>>>> On Wed, Sep 1, 2010 at 1:47 PM, David Jones <davidhere40@gmail.com>wrote:
>>>>>>
>>>>>>> I've been to think lately that the solution to creating a realistic
>>>>>>> AGI design is psuedo design. What do I mean? Not simulation... not practical
>>>>>>> applications... not extremely detailed implementations. The design would
>>>>>>> start at a high level and go deeper into detail as possible.
>>>>>>>
>>>>>>> So, why would this be a solution? Well, before I mention the cons to
>>>>>>> this approach, consider the following:
>>>>>>>
>>>>>>> *Problems it would solve:*
>>>>>>> 1) There is no money and little interest for AGI. Even if you could
>>>>>>> get money, I am 99.99% sure it would be spent wrong. I know, I know... I'm
>>>>>>> supposed to be trying to get us money, not dissuade it. But, I really think
>>>>>>> we are repeating the mistakes of earlier researchers that promised too much
>>>>>>> on unjustified ideas. Then when they failed, it created AI winters, over and
>>>>>>> over and over again. History repeats itself.
>>>>>>>
>>>>>>> So, getting us more money would likely do harm in addition to too
>>>>>>> little good, the way it would be spent, for me to care. Extremely few people
>>>>>>> are interested in AGI and among those that are, their ideas about it are
>>>>>>> very, very flawed. We tend to approach the problem using our typical
>>>>>>> heuristics and problem solving techniques, but the problem is no longer
>>>>>>> amenable to these techniques. For example, the idea that patterns finding is
>>>>>>> sufficient for intelligence. It has not been proven beyond my reasonable
>>>>>>> arguments against it. Yet, people are getting funding and pursuing entire
>>>>>>> architectures based on it. Does that really make sense? Nope. We must pseudo
>>>>>>> test and pseudo design our algorithms first. Why? Because after spending
>>>>>>> several years on these designs that I can reasonably predict will fail with
>>>>>>> a high likelihood, we'll be back as the same place we were. Wouldn't we be
>>>>>>> much better off figuring that out earlier rather than later through fast
>>>>>>> prototyping techniques, such as the one I mentioned (pseudo design and
>>>>>>> testing)?
>>>>>>>
>>>>>>>
>>>>>>> 2) Implementations tend to get overwhelmed by the desire to show
>>>>>>> immediate results or achieve practical short-term goals. This completely
>>>>>>> throws off AGI implementations, because these other constraints are not
>>>>>>> compatible with more important AGI constraints.
>>>>>>>
>>>>>>>
>>>>>>> 3) We could find a solution much faster... AGI is a massively
>>>>>>> constrained CSP (Constraint Satisfaction Problem). The eternity puzzle is a
>>>>>>> great example of such a problem. If you approach the eternity puzzle using
>>>>>>> heuristics alone to generate a likely solution, such as how pretty the
>>>>>>> pattern is, or how plausible it is that the designers created this design,
>>>>>>> it is guaranteed to fail. This is especially true if it takes you even a few
>>>>>>> minutes to reject the design. The puzzle has so many possibilities that if
>>>>>>> you were to try to look at each one to see if it was a solution, it would
>>>>>>> literally take an eternity.
>>>>>>>
>>>>>>> So, how do you solve such problems? You start with the most
>>>>>>> constrained parts of the puzzle first, and you use heuristics to guide your
>>>>>>> search for solutions paths that are likely to contain a solution and avoid
>>>>>>> solutions paths that are less likely to contain a solution. Most
>>>>>>> importantly, you have to try a lot of solutions and reject the bad ones
>>>>>>> quickly, so that you can get to the right one. How does this apply to AGI?
>>>>>>> It's almost exactly the same. Current researchers are spending a lot of time
>>>>>>> on solutions that were generated using bad heuristics (unjustifiable human
>>>>>>> reasoning heuristics). Then they take forever to test them out (years)
>>>>>>> before they inevitably fail. A better way is to test solutions with as
>>>>>>> minimal effort and time as possible, such as by using pseudo design and
>>>>>>> testing techniques. This way you can settle onto the right solution path
>>>>>>> much, much faster and not waste time on a solution that clearly wouldn't
>>>>>>> work if you simply spent a bit more time analyzing it. Yes, such an approach
>>>>>>> has problems also, such as dishonesty or delusion in how the algorithms
>>>>>>> would actually work. I'll mention these more below. But, we have those
>>>>>>> delusions and problems already :) So, overall, this approach seems to be
>>>>>>> significantly better.
>>>>>>>
>>>>>>>
>>>>>>> 4) if we could show that a pseudo AGI design works in sufficient
>>>>>>> detail and with sufficient plausibility, it would likely change the minds
>>>>>>> of:
>>>>>>> -many people that don't think AGI is possible,
>>>>>>> -those that think it isn't possible in their lifetimes, and
>>>>>>> -those that think it isn't worth investing in.
>>>>>>> In other words... we would get the money, help and interest needed to
>>>>>>> make it happen. Demos are great at generating interest in things that are
>>>>>>> very complicated. This would be a fantastic demonstration.
>>>>>>>
>>>>>>>
>>>>>>> *Pros:*
>>>>>>> 1) Fast design testing and rejection
>>>>>>> 2) Rough to fine design... would arrive at a solution faster because
>>>>>>> it uses the "*Most*-*Constrained*-Variable-First" heuristic (such as
>>>>>>> has been used to solve the eternity puzzle... you solve the most constrained
>>>>>>> portion first to avoid having to try out many possibilities that will fail
>>>>>>> at the most constrained part).
>>>>>>> 3) Less pressure for practical applications and more focus on
>>>>>>> important AGI issues... this removes extra constraints that are not
>>>>>>> compatible with AGI constraints.
>>>>>>> 4) More man power because the design is less costly, less time
>>>>>>> consuming and requires less detail-oriented expertise.
>>>>>>> 5) Can you think of other pros?
>>>>>>>
>>>>>>> *Cons:*
>>>>>>> 1) People will make assumptions that are false and will delude
>>>>>>> themselves about these assumptions even if you point out flaws.
>>>>>>>
>>>>>>> I don't think there is anything we can do about this except for
>>>>>>> people that have not accepted the mistake to create different designs in
>>>>>>> parallel. If you disagree with someone, then you'll have to create another
>>>>>>> branch of the design or start a new design. At such a point, new comers will
>>>>>>> have to decide who is right and who is wrong and choose the project they
>>>>>>> believe in the most.
>>>>>>>
>>>>>>> 2) Important and honest assumptions may be wrong.
>>>>>>>
>>>>>>> I claim that this is ok because those assumptions would have been
>>>>>>> made anyway. At least many of these assumptions can be thrown out at the
>>>>>>> hypothetical stage before spending tons of time and money on a bad design.
>>>>>>> In addition, I think the work on the rest of the design will likely still be
>>>>>>> of value and will allow an implementation project to fix the assumption
>>>>>>> mistake and move on.
>>>>>>>
>>>>>>> 3) Often real world testing provides us with unexpected, new
>>>>>>> insights.
>>>>>>>
>>>>>>> While this is true, I don't think it's worth the down side of current
>>>>>>> approaches... which is that they take forever to fail and stay stuck on
>>>>>>> flawed designs, while trying to convince others that they are right.
>>>>>>>
>>>>>>>
>>>>>>> *Realistic Testing*
>>>>>>> I would also suggest to pretend that the pseudo design is a real
>>>>>>> design whenever it makes sense to do so. So, how do we decide when to go
>>>>>>> into detail and when not to? It depends on the value of that detail. If we
>>>>>>> can make reasonable assumptions and then keep moving forward with the
>>>>>>> design, we should. If we can't, then we need to go into more detail.
>>>>>>> Sometimes we might go into detail just because we can. But, what we
>>>>>>> shouldn't do is get stuck in detail that may have to change later on. We
>>>>>>> would be better served resolving the higher level portions of the design
>>>>>>> first (remember the "*Most*-*Constrained*-Variable-First"
>>>>>>> heuristic). It is extremely important to use this heuristic when working on
>>>>>>> such complicated design projects
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Dave
>>>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>>>>
>>>>>>
>>>>>>
>>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>>>> <http://www.listbox.com/&gt;
>>>>>
>>>>
>>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription <http://www.listbox.com/&gt;
>>>>
>>>
>>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>>> <http://www.listbox.com/&gt;
>>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
>> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
>> <http://www.listbox.com/&gt;
>>
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>

Jim,

I was responding to mikes "Visual Object Recognition - recognize all those
fonts as "A"" challenge....

As for the generate a new font problem... sure, that could be considered an
AGI problem if the AGI had experience. But the thing is, we don't program
AGI's with that sort of experience from the beginning. It doesn't make sense
as an AGI problem because that assume that the AGI should be able to perform
such feats without other general abilities and quite a bit of experience to
draw from. This assumption is required because I can't just say well the AI
has drawing experience and bla bla bla. Because mike will yell bullshit and
mysticism. But the truth is that drawing and such creativity DOES draw on a
lot of experience. So, to make it a fundamental problem doesn't make one wit
of sense.

But, for arguments sake... let's assume that I had to suggest how an AI
might do this.... Well, I could say that the AI has the ability to perform
trial and error actions. It attempts something and then evaluates it. It is
able to recognize fonts in similar ways that humans do, so it will recognize
when a font has the right properties to be recognized by other people as an
A. It might know that nice twists and curves are kinda cool and creative
because it has seen them before. It might know that AI's typically have
certain major features such as the lowercase version has a large curve from
the top-right to the left-middle and then down to the bottom-right. It also
typically has a curving line from the top-right to the bottom-right. So,
given all these "creative" ideas, it could start trial and error generation
of new fonts using a search for ideas from past experience as well as just
acting out rough to fine motor commands. All the while the AI is evaluating
whether the evolving form is going to have the patterns that a person would
expect of an "A", which is could recognize. If it creates a pattern that it
feels should be rejected because it probably wouldn't be evaluated as an
"A", then it would erase and try again, etc.

You see? There is an immense amount of trial and error, as well as very
complicated general reasoning going on. Why in the world would I start with
that problem when building AGI? I certainly wouldn't. It's a nice example to
keep in mind and analyze. But it is certainly not the most fundamental
problem I would want to think about. If I designed specifically for this, I
would likely over engineer a solution that doesn't make sense for most other
problems.

Dave

On Wed, Sep 1, 2010 at 4:38 PM, Jim Bromer <jimbromer@gmail.com> wrote:

> David,
> You are missing something here. While it is impossible for a program or a
> person to "design" every possible font without any realistic contextual
> cues, inforation and experience, and it would therefore be a waste of
> time to try, it is not a waste of time to try to consider what kind of
> program would be needed to have the potential to design any kind of font.
> Such a process cannot be intelligently done just by copying fonts from other
> sources for example, so it becomes very relevant to at least start thinking
> about what kind of knowledge structures would be necessary to maximize the
> potential for it to learn.
>
> I am considering the problem from the point of view of whether or not I can
> write a closed program that can produce such a vast number of variations of
> an icon, because in solving the problem I have seen that I can get a better
> handle on the nature of the data structures and relations between data
> objects might be needed for a better designed AGI program.
>
> I realize that Mike has no idea about what I am talking about, but I
> am surprised that you don't get it.
>
> Jim Bromer
>
> On Wed, Sep 1, 2010 at 4:14 PM, David Jones <davidhere40@gmail.com> wrote:
>
>> Mike,
>
> Have you ever considered that maybe it is impractical and irrational to
>> design an AGI system to recognize all possible fonts for "a" without any
>> realistic contextual cues, info and experience? Did you ever consider that
>> maybe that's the dumbest way to design an AGI ever?
>>
>> People can't take any possible random and unexpected pattern out of
>> context and figure out what it is. Intelligence doesn't work that way. We
>> use cues to twist what we see into what we expect. If you could see out of
>> your tunnel, you might realize this.
>>
>> So, recognizing any possible "a" font is not a realistic or pragmatic AGI
>> problem. And I would be an idiot to spend any time trying to solve it.
>>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now&gt;
> <https://www.listbox.com/member/archive/rss/303/&gt; | Modify<https://www.listbox.com/member/?&>Your Subscription
> <http://www.listbox.com&gt;
>