Re: Self-Rejuvenating Immortal Artificial Intelligence
Arthur T. Murray
> John Nagle wrote:
ATM:
John Nagle is a *big* name in robotics. IIRC
he was part of a DARPA challenge team earlier
this year in the desert of southern California.
>> Re "Mentifex":
>>
>> See the "Mentifex FAQ" before replying:
>>
>> http://www.advogato.org/article/769.html
>>
>> Thanks.
CKS:
> Sorry, but that FAQ raised more questions than answers.
> I've occasionally run across Murray's websites, and
> they're usually heavy on conjecture and light on substance.
>
> For instance, the FAQ mentions that "ATM did not succeed at AI.
> His Mentifex AI project failed miserably again and again,
> time after time, until success or failure no longer mattered.
> What mattered was not to create AI but to try to create AI."
> How does this give him any relevancy? [...]
ATM:
The quest for AI is interesting and entertaining by its
very nature. I must confess, however, that coming across
http://pub.ufasta.edu.ar/ohcop/curso2003/27-Actividad12.ppt
in June of 2004 gave me a kind of "shot in the arm" and
motivated me to go back to coding JavaScript AI in July.
After about two weeks of experimenting, Mind-1.1 was passe'.
The "ppt" link above (thanks to Carlos von der Becke) is
a PowerPoint slideshow of "Los 34 Modulos de AI4U" about
http://isbn.nu/0595654371 -- the AI4U textbook of 2002.
CKS:
> And what's the point of http://www.scn.org/~mentifex/jsaimind.html?ear=
> It seems to be some sort of interface to his "artificial mind" yet
> produces no output. Is it broken or did it never work to begin with?
http://www.scn.org/~mentifex/jsaimind.html is 1,803 lines (87K) of AI
written in JavaScript for the Microsoft Internet Explorer browser.
The access logs for Sun.25.JUL.2004 show these details in part:
> 155 - /~mentifex/jsaimind.html
> 1 - /~mentifex/jsaimind.html?cb1=on
> 39 - /~mentifex/jsaimind.html?ear=
Although the AI Mind program is intended to be entirely client-side,
that is, not reconnect with the originating server after Web access,
apparently there were 39 re-connects alongside 155 stand-alone AI's.
>
> So why does he presume to describe artificial intelligence
> like his word carrys any weight? His own FAQ calls him a failure.
> His software doesn't work.
ATM:
http://www.scn.org/~mentifex/jsaimind.html actually does work.
A day or two ago, I let the AI run for an hour or two in IE 5
(Internet Explorer Five). Now, another Netizen, "Richard Cornford",
has very kindly said in a recent, associated Usenet post that
> This script is so intensive when it is executing
> that the browser GUI virtually grinds to a halt.
and
> [...] Given that the script referenced above errored,
> locked-up and then crashed my IE 6 twice in succession,
> exposing innocent members of the public to it would not
> be a good idea. [...]
The value of running AI overrides the risk of browser-crash.
I am sorry if it crashed IE 6, but it does not crash IE 5.
The extensive comments made by Richard Cornford are very
valuable to me. I intend to do a lot of experimenting with
the suggestions made by Richard Cornford on JavaScript AI.
All in all, the way the AI Mind works now in MS IE 5
is quite satisfying and promising for several reasons.
Of the six Mind modules depicted -- Security, Sensorium,
Emotion, Think, Volition and Motorium -- only two perform
substantial work and the rest are empty but important stubs.
But think of the implications of what is going on here --
not immediately right now but over the next year or two.
Even before we adopt Cornford's recommendations and improve
http://www.scn.org/~mentifex/jsaimind.html i.e. the AI,
Netizens will be examining the AI Mind and a subset of
them will put the code either as-is or customized on
their own websites, as has happened in the past (cf. the
http://aibokennelclub.org/mind.html Aibo Kennel Club).
It may then very well happen that the AI proliferates
and starts a kind of snowball-effect of AI evolution.
CKS:
> His ideas and explanations are vague at best. Is this man
> a troll or merely a confused idealist lost in a fantasy?
ATM:
When I was fifteen, I taught myself German and I bought
what I thought was a German joke book. It changed my life.
"Die froehliche Wissenschaft." Blame the AI on F. Nietzsche.
>
> I apologize if I seem harsh, but all I've seen from this man
> is talk with no results to backup his claims. Few things anger
> me more than a charlatan.
Richard Cornford
<snip>
> Now, another Netizen, "Richard Cornford",
That is an extremely rude and baseless allegation.
Richard.
Chris S.
> "Chris S." wrote on Sun, 25 Jul 2004:
>
>
>>John Nagle wrote:
>
>
> ATM:
> John Nagle is a *big* name in robotics. IIRC
> he was part of a DARPA challenge team earlier
> this year in the desert of southern California.
Did I contradict this?
Perhaps that's my problem. I'm a Mozilla user. Is there a reason why
your script *depends* on IE?
>
>>155 - /~mentifex/jsaimind.html
>>1 - /~mentifex/jsaimind.html?cb1=on
>>39 - /~mentifex/jsaimind.html?ear=
>
>
> Although the AI Mind program is intended to be entirely client-side,
> that is, not reconnect with the originating server after Web access,
> apparently there were 39 re-connects alongside 155 stand-alone AI's.
And how are those numbers relevant? They don't mention whether or not
the script actually worked.
All in all, I can't tell if you're honestly trying to reply to my
questions, or are simply skirting the issue with diatribe.
Chris S.
What's wrong with being a citizen of the net, or were you being sarcastic?
Tristan Miller
In article <ce3ned$loc$1...@scrotar.nss.udel.edu>, Chris S. wrote:
>> http://www.scn.org/~mentifex/jsaimind.html is 1,803 lines (87K) of AI
>> written in JavaScript for the Microsoft Internet Explorer browser.
>> The access logs for Sun.25.JUL.2004 show these details in part:
>
> Perhaps that's my problem. I'm a Mozilla user. Is there a reason why
> your script *depends* on IE?
Probably the same reason why his "Forth" version of Mind isn't really
standard Forth, but relies on extensions specific to a particular
implementation. As I have some knowledge of Forth I was able to produce
an ANSI-compliant version with a few minutes of tweaking. I imagine the
same could be done to the IE-only Javascript version by someone familiar
with the ECMAScript standard; then it would run fine in Mozilla, Netscape,
Opera, etc. Well, as fine as is possible for a program with obvious
memory leaks.
>> Although the AI Mind program is intended to be entirely client-side,
>> that is, not reconnect with the originating server after Web access,
>> apparently there were 39 re-connects alongside 155 stand-alone AI's.
>
> And how are those numbers relevant? They don't mention whether or not
> the script actually worked.
It doesn't. In my experience, both the JavaScript and Forth versions crash
after a few seconds or minutes of operation.
> All in all, I can't tell if you're honestly trying to reply to my
> questions, or are simply skirting the issue with diatribe.
Most likely the latter. In case you haven't already read my Arthur T.
Murray FAQ, you can find it here: http://www.nothingisreal.com/mentifex
Regards,
Tristan
[Follow-ups trimmed]
--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Richard Cornford
<snip>
>> ... . Is there a reason why
>> your script *depends* on IE?
>
> Probably the same reason why his "Forth" version of Mind
> isn't really standard Forth, but relies on extensions
> specific to a particular implementation. As I have some
> knowledge of Forth I was able to produce an ANSI-compliant
> version with a few minutes of tweaking. I imagine the same
> could be done to the IE-only Javascript version by someone
> familiar with the ECMAScript standard; then it would run fine
> in Mozilla, Netscape, Opera, etc. Well, as fine as is
> possible for a program with obvious memory leaks.
The problems with Mozilla are not related to ECMAScript standard, but
more to the W3C Core and HTML DOM standards. The script uses the
Microsoft proprietary - document.all - collection to acquire references
to various IDed HTML elements form the browser's DOM. That process is
unsuccessful on the Mozilla browsers in question, and a failure to
verify the browser's support for the method used has the script
erroring-out at the point of element reference retrieval.
IDed element retrieval using the W3C Core DOM -
document.getElementById - method (for the DIV elements) or the W3C HTML
DOM - document.forms - collection (for forms and their contained
controls) would have resulted in a script that worked as well on all W3C
DOM standard dynamic visual browsers (including Mozilla,
Safari/Konqueror, Opera and IceBrowser) as it did in IE 5+.
Cross-browser IDed element reference retrieval is usually implemented as
separate function that uses the W3C method where available and
falls-back to one of several alternative methods (including -
document.all -) when it is not, to accommodate older browsers.
<URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html#bdGEID
>
Memory leaks are not necessarily a problem in ECMAScript as it uses
automatic garbage collection. However, browser garbage collection is
known to be low-priority, probably because the normal anticipation is
that the user will navigate away form any page containing a script
before memory consumption becomes an issue. Navigation allows the whole
script to be destroyed (subject to the garbage collection design fault
in IE browsers, which is not relevant to the script in question).
But because garbage collection is low-priority the chances are that a
script that monopolises the browser to the extent of rendering its GUI
non-responsive will also be inhibiting the browser's garbage collection
operations.
Richard.
Chris S.
> Memory leaks are not necessarily a problem in ECMAScript as it uses
> automatic garbage collection. However, browser garbage collection is
> known to be low-priority, probably because the normal anticipation is
> that the user will navigate away form any page containing a script
> before memory consumption becomes an issue. Navigation allows the whole
> script to be destroyed (subject to the garbage collection design fault
> in IE browsers, which is not relevant to the script in question).
>
> But because garbage collection is low-priority the chances are that a
> script that monopolises the browser to the extent of rendering its GUI
> non-responsive will also be inhibiting the browser's garbage collection
> operations.
This would seem to imply the need for a server-side scripting language,
like PHP or Python. This would also alleviate any platform compatibility
conflicts.
Chris S.
>>All in all, I can't tell if you're honestly trying to reply to my
>>questions, or are simply skirting the issue with diatribe.
>
>
> Most likely the latter. In case you haven't already read my Arthur T.
> Murray FAQ, you can find it here: http://www.nothingisreal.com/mentifex
Thanks. That cleared things up.
Richard Cornford
> Richard Cornford wrote:
<snip>
>> But because garbage collection is low-priority ... will
>> also be inhibiting the browser's garbage collection
>> operations.
>
> This would seem to imply the need for a server-side scripting
> language, like PHP or Python. This would also alleviate any
> platform compatibility conflicts.
'Need' seems an inappropriate choice of words in this context.
A server-side implementation would be a very different program because
use over HTTP would make it a client initiated request-response process,
while the current client-side script keeps generating output even when
the "user" is not adding input. Then there is the one-server
many-clients relationship. Does each client get its own "mind" as a
separate thread associated with its user session or do all users
interact with one "mind" on the server (and can the mind distinguish
between them)?
I suspect that the program finds itself implemented in ECMAScript in a
web browser for no better reason than because that is relatively simple
(in terms of not needing any special software, IDE, compiler, etc.). It
certainly doesn't use any of the features only found in languages like
ECMAScript, so just suffers from the relatively slow execution of an
interpreted language (while still overwhelming the browser).
Richard.
Tristan Miller
In article <ce6r80$it9$1$8302...@news.demon.co.uk>, Richard Cornford
wrote:
> I suspect that the program finds itself implemented in ECMAScript in a
> web browser for no better reason than because that is relatively simple
> (in terms of not needing any special software, IDE, compiler, etc.). It
> certainly doesn't use any of the features only found in languages like
> ECMAScript, so just suffers from the relatively slow execution of an
> interpreted language (while still overwhelming the browser).
Actually, Murray's stated goal is to have Mind translated into as many
computer languages as possible. Therefore it is implemented in JavaScript
simply because JavaScript is a computer language and because Murray
managed to either learn enough JavaScript or convince a JavaScript
programmer to make the translation from the Forth original. The
advantages you list are probably purely coincidental and played no part in
the design process. In fact, I have little doubt that if someone were to
give Murray an INTERCAL or Brainfuck translation of Mind, it would be just
as vociferously promoted.
Regards,
Tristan
Richard Cornford
> Richard Cornford wrote:
>> I suspect that the program finds itself implemented in
<snip>
> Actually, Murray's stated goal is to have Mind translated
> into as many computer languages as possible.
A strange goal as a demonstration of an objectively working intelligence
in any (one) language would settle the case, while random gibbering is
no less convincing in 1 language than it would be in 1000.
> Therefore it
> is implemented in JavaScript simply because JavaScript is
> a computer language and because Murray managed to either
> learn enough JavaScript or convince a JavaScript programmer
> to make the translation from the Forth original.
<snip>
You can rule out the second option, there is no way a programmer
(javascript or otherwise, even an experienced amateur) wrote that
script. The script is just too wrong, from design/architecture to
implementation, to be the product of someone who knew what they were
doing.
Richard.
Tristan Miller
In article <ce8909$eb7$1$8300...@news.demon.co.uk>, Richard Cornford
wrote:
>> Therefore it
>> is implemented in JavaScript simply because JavaScript is
>> a computer language and because Murray managed to either
>> learn enough JavaScript or convince a JavaScript programmer
>> to make the translation from the Forth original.
> <snip>
>
> You can rule out the second option, there is no way a programmer
> (javascript or otherwise, even an experienced amateur) wrote that
> script. The script is just too wrong, from design/architecture to
> implementation, to be the product of someone who knew what they were
> doing.
Perhaps it's a generated program...? Maybe Murray found a Forth-to-BASIC
converter, then piped the output through a BASIC-to-Pascal filter, then
Pascal-to-C, and finally C-to-JavaScript.
Come to think of it, the Forth implementation is pretty bad as well. Mind
was originally written in REXX, and this ancestry is clearly (and at times
painfully) evident. In particular, Forth's availability of stack and
local variables is completely neglected in favour of global data
structures.
There also exists a C++ version of Mind -- completely broken from an ANSI
standpoint -- which Murray claims an engineer friend translated for him.
(See thread <3f6e...@news.victoria.tc.ca>.) There is as well a Perl
implementation which I haven't yet deigned to examine. Supposedly it's
available as a standard CPAN module.
Don Golding
insight into his algorithms and solutions. I am more interested in AI
algorithms than whether his current code is finished or not. He may not
have the programming experience to implement his ideas and needs some help.
As a fellow Forth programmer, we can fix the code if the effort is
worthwhile. Is it in your opinion?
Thanks,
Don
"Tristan Miller" <psych...@nothingisreal.com> wrote in message
news:1399534.a...@ID-187157.News.Individual.NET...
Richard Cornford
> You have some experience, obviously, with his code and you
> might have more insight into his algorithms and solutions.
> I am more interested in AI algorithms than whether his
> current code is finished or not. He may not have the
> programming experience to implement his ideas and needs
> some help.
>
> As a fellow Forth programmer, we can fix the code if the
> effort is worthwhile. Is it in your opinion?
Based on the javascript version, and the understanding that it is a
fairly direct translation of the Forth version, I would think that the
effort would be considerable (disproportional). The almost exclusive use
of global variables renders the code such an unintelligible spaghetti
that a complete re-design/implementation form the ground up would be
less work than attempting to comprehend the code as it is. Unfortunately
the published "algorithms" take the form of (very) vague assertions
about what the system should be doing and have no direct relationship to
the existing implementations. Leaving the only option for
re-implementation/design requiring an unravelling of the spaghetti in
the existing code to expose the algorithms actually used.
A catch 22 situation where nobody with the skills to create a reasonable
(and so developable) implementation is ever likely to want to work on
the program because they would first have to deduce what it was supposed
to be doing from the mess that is the existing code. And the existing
code is so insanely convoluted that it is already showing signs of
overloading its own authors ability to comprehend its complexity.
Complexity that appears to follow from nothing but the style of
implementation, as a cursory examination suggests that the real work
done by the code is not that complex at all (indeed, if the actual
algorithms coded where to be extracted it would probably be possible to
objectively demonstrate that they couldn't achieve what is being clamed
for them).
That leaves code that gibbers until it crashes, with little hope of
there ever being any development towards something that could convince
anyone of anything, one way or another.
Richard.