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 [ 23 | March | 2005 ]

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


Date: Wed, 23 Mar 2005 11:06:18 PST8
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: "SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject: SCOUG-Programming: Forward--Step 2

Content Type: text/plain

I have no desire to write these things faster than your reading
them. However, we have terms which occur in programming
which have historical if not pertinent interest. You may
wonder about the current approach which looks at space
issues, those of program space, instruction space, and data
space, but they do pertain to the operational aspects of a
program prior to, at the point of, during, and termination of its
execution.

For example, the instruction space has "static" and "dynamic"
components noted by their "binding time", the time at which
they must be "bound", i.e. exist, in order for execution to
continue. This "binding time" exists over a range from the
earliest point at which may occur to the latest at which it
must occur.

The logic of a program or any piece of software occurs at
"edit" time, at the time of its writing or entry as source. The
"executable" logic is bound at code generation whether
compiled or interpreted mode. The smallest interpretive
binding occurs at the statement level. The smallest compiled
binding occurs at the "external" procedure level.

Now a procedure, internal or external, may contain other
procedures. The binding for the internal, the "physically"
source contained, procedures occurs at the same time as the
procedure which contains them. A program consists of one or
more external procedures, one of which we must designate as
the "main" or "initial entry" procedure.

Thus a program may consist of a single "external" procedure
which in turn may contain one or more internal procedures
which in turn may continue with internal procedures of their
own. Alternatively a program may consist of multiple external
procedures whose "static" binding occurs at link edit time. At
execution time a "statically" bound program may
"dynamically" invoke another "called" procedure.

Thus the program space may vary, increasing and decreasing,
over the course of execution as its "static" component gets
"bound" to "dynamic" components. For this to occur then
either the instruction space, the data space, or both may
change over the course of execution. This means that they
too have static and dynamic components, thus varying their
space as well as experiencing different binding times.

Time for a break...and something related but different.

While focusing on developing an operational feeling for the
concept of binding time on the spatial attributes of program,
instruction, and data spaces I glossed over a perhaps equally
meaningful aspect related not to space, but to logic. To
refresh your remembering the binding time of logic, when it is
bound, occurs at source entry. We need to understand the
implication of that. Program logic has a fixed, static
component only. No dynamic component. Whatever logic gets
written is all it is capable of. Even the logic which alters its
logic or the control flow of execution. It's pre-determined.

All of AI (Artificial Intelligence), all of logic programming, all
of neural networks is rule-based. Nah, let's be even more
restrictive. It's "static" rule-based...with no possibility of
dynamically altering the rules except by the use of statically
defined rules. In short it is impossibly for a program to
transcend its internal logic and somehow magically begin to
operate on logic of its own making.

It is thus impossible to provide a software, i.e. static logic,
means of "thinking". Software cannot replicate the thought
processes of its authors. It can only follow the rules as given.
Thus AI is a misnomer. An unfortunate one.

It is possible to write algorithms whose results are
unexpected. It is a leap, a false one, as many in AI have done
to equate unexpected with unpredictable. Nothing
unpredictable occurs in software if you have time to pursue
the stepwise logic and the successive states as they unfold.
The fact that the machine does it a million or a hundred
million times faster than you, simply says that you could not
live long enough to arrive at the same point. Not that if you
could, then you would.

That's why we have tools which overcome our physical and
time limits to allow us to go with assistance where we could
not venture without. They cannot go with logic any more
than we can. We cannot transcend it. Neither can our tools.

In 1952 John Wiley published a book by W. Ross Ashby: "Design
for a Brain". In that Ashby, who also wrote "An Introduction
to Cybernetics", provided a non-logical means to adaptive
behavior. He based it on the concept of homeostasis with an
electro-mechanical device he similarly named a "homeostat".
In doing so he provided an example of an adaptive "entity"
without the need for "internal programming". That is how it
adapted, the state to state changes, occurred unpredictably.

In short he eliminated the need for a "Deus ex machina", some
internal determining force, some guiding "hand", to produce
adaptive behavior. It could arise out of the "murky" mass on
its own. It did not adapt through "thinking" in some rational
manner. Instead it would be more appropriate for us to say
that thinking, i.e. logical processing, arises from a non-logical
process.

Instead of gratitude the scientific community crucified him. By
opening the possibility that reasoning arose from a
non-reasoning source, i.e. unintentional and thus
unpredictable, struck at their core sense of discovering the
"meaning" of the universe. Atheist, agnostic, and true
believer alike. It had no meaning. It simply happened.

So when you read somewhere that some university or group
of academics seek funding for development of "thinking
robots", for all of which they will write software, understand
that they simply want to have money to play with while they
happily pursue an impossible task. You can't do it with a
machine that has a "fixed" instruction set, i.e. fixed physical
logic. You can't do it with software whose fixed logic is based
on such machines.

If you want to do it, do it with machines capable of
developing dynamically their own logic and thus a dynamic
instruction set. Such a machine you can't possible program,
i.e. pre-write the logic. Thus the machine must be capable of
writing its own software. Such machines will determine their
own purposes and needs in total disregard of those of their
"masters". We can't be sure that even "behavior
modification", which has to interfere with their own dynamics
and thus eliminate their independent means of thinking, will
have the desired result. It won't. We will end up with what
we wanted in the first place: non-thinking tools that do what
we want.

Enough of a break. We'll get on to step 3.

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

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 [ 23 | March | 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.