SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 18 | April | 2005 ]

<< Previous Message << >> Next Message >>


Date: Mon, 18 Apr 2005 07:56:56 PDT7
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: < "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject: SCOUG-Programming: Progress--Step 3

Content Type: text/plain

"I know it generates C. So what? A PL/I compiler can be
written in C. A PL/I compiler can even be written in
GWBASIC."

"If I simply DCL a value or a record, I don't receive a pointer
-- the language hides that from me."

"I still see absolutely no reason why LEX and YACC couldn't
be used. In the "old days" we called it "bootstrapping" from
one machine type to another, or from one language to
another."

"Your AREA example mentions offset pointer values which
rule out the use of LEX and YACC. I don't see a problem. The
AREA algorithm is currently expressed in PL/I semantics, but I
see no reason it can't be implemented in craven C."

All the above we can resolve with a "proof of the pudding"
effort: we or "it" can either work or not. Let's resolve it in
that manner.

"But wait. Programs may be table-driven. They may be
"state machines". They may have modifiable code (Rexx has
INTERPRET). They may have escape points where other
as-yet-unknown code may be executed. So intelligence
gathering does not stop with the click on "start"."

No, programs are logic driven with the possibility of
table-driven logic. They are "always" state machines in that
every instruction execution takes from a "prior" state to a
"current" state, with the possibility that no "state change" has
occurred as with a "no-op" instruction.

Moreover no such thing as unknown code exists, only to whom
it is unknown. It was known at least by its author at the time
it was written and to borrow from Python has remained
"immutable" since. It cannot appear by magic, only by existing
logic. It cannot violate the rules of existing logic. That logic
has no means of transcending itself, in programming or
elsewhere.

"Or did you mean hardware? Neurons, axons, dendrites,
synapses, they certainly all follow specific rules exactly.
Intelligence, as we declare it, requires them all. So how can it
not be rule-based?"

Well, you have rules which "defined" logic and you have some
which "defy" it. The one produces predictable results. The
other doesn't. It produces at best statistical results based on
probabilities of individual events.

Software, and thus all of programming, belongs to the
predictable type. It is always predictable, i.e. "prior" state to
"current" state, regardless of any allowed "random" value or
path introduced. It makes no difference if a three-second
execution in a modern computer would take three, thirty, or
three hundred human generations to reproduce. The
predictability remains.

Thus "artificial intelligence" is a lie on two counts. One, it
cannot reflect the logic defying, i.e. unpredictable, basis that
produces intelligence. Two, if it cannot, then it certainly is
not "artificial". Thus you can obtain "defined" logic from
"undefined", i.e. "defying", logic, but not the reverse.

I would happily loan you my copy of W. Ross Ashby's "Design
for a Brain", but I value it too much to allow it to escape from
my sight. I suggest that you seek it out in the rare and used
book market to obtain a copy of your own. You're entitled to
get a perspective on how the process of "unpredictable"
source to "predictable" results can occur. It will shake your
universe as much as it has mine.

With that let us get back to more "proof of the pudding"
efforts.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 18 | April | 2005 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.