|
Jack Park wrote: You (Judith) and others can take the time
to wax
thoughtful on the notion of a cookbook, or, you can get on with
tossing
ideas into the ring.
That's a tad unfair, it seems to me. Perhaps you missed this
part of my post:
> *So I keep throwing various insights out there, hoping something will
> prove useful and can be plugged into your much larger cache of
knowledge
> and help you along in your efforts.*
Judith
----- Original Message -----
Sent: Monday, January 31, 2005 10:41
PM
Subject: Re: [ROSEN] Jack's Rosennean
Cookbook idea...
As Richard Hamming famously said: "The purpose of computing is
insight,
not numbers."
Cast in that light, just about anything a
computer can do to illuminate,
if only in some small way, candidate
pathways to enlightnement in the
eyes of modelers, problem solvers, then,
let it be said that a benefit
is accrued. If such modelers, problem
solvers are looking for insight
into the nature and solution to the vast
array of complex and urgent
problems facing humanity, then, even
better.
We can sit here and wax poetic or even religious that computers
can or
cannot do this or that. In the end, who really gives a shit? Some
of us
are bucking for a dissertation defense, some of us are trying to
collect
or fulfill a payroll, and some of us really care about those
complex and
urgent problems. You (Judith) and others can take the
time to wax
thoughtful on the notion of a cookbook, or, you can get on
with tossing
ideas into the ring. I am happy to see a relational analysis
of the
problem space posed just by the notion of a cookbook, itself an
intended
relational model of a perceived discipline. The analysis sketched
below,
itself, is a useful start.
People, such as Jerry will argue,
and correctly so, that we cannot share
knowledge. Information is the
currency of human discourse. Gordon Pask,
who's entailment meshes are as
close to a relational space as any I've
seen, argued that we each hold, in
our minds, models of those with whom
we engage in social intercourse.
Without such models, the information we
encode in our conversations would
likely be just so much noise. My model
of my son, when he was 3, suggested
that an indepth dialog on technical
analysis of IBM's ticker just wouldn't
make much sense to him. These
days, he might surprise me. So, we can share
information, and given that
our internal models of our listeners allow us
to perform a kind of "pre
interpretation" such that we emit only those
ideas that we either think
to be meaningful--as in, capable of being
interpreted in a way that
meaning was made in the mind of our listener, or
that we think will
provoke a debate (or titilate, when the game is humor).
Indeed, Marvin
Minsky thinks that humor is all about expectation
failure.
And, expectation failure is what anticipatory systems are all
about, and
that is what my qualitative reasoner uses as a modeling trick
to provoke
thoughts in the human in the loop. Thus, I would argue that
even the
simplest, purely syntactic, symbolic model holds forth the
opportunity
to illuminate things, ideas, concepts, events which the user
may not
have seen. In my experience with my program,
crystalographers who were
asked to encode their domain knowledge into the
process rules of my
system all commented that just the process of
"teaching" my program
opened their eyes to things they hadn't thought
about before. You don't
have to solve a problem to discover something; you
just need a means by
which you can hold-forth a dialog within your own
mind as you formulate
some story for some other entity to hear (whatever
hearing entails).
Following a cookbook is just one way to learn something.
Writing the
cookbook is another.
We, as humans, are extremely fond
of telling each other what is or is
not possible. I submit that that
behavior is part of the problem. Go
model that.
Jack
Judith
Rosen wrote:
> *I continue to mull over these ideas...*
> **
> *What limits me the most is a clear understanding of what computer
> programming can realistically encode. I use computers a lot, and I
have
> amassed a large cache of mostly intuition-based understanding,
using
> what experts like Jack and others have said as a form of
"parameter
> checking".... but I have grave doubts that this is enough
to really help
> generate a "Rosennean information sorting protocol" or
something along
> those lines... *
> **
> *So I keep
throwing various insights out there, hoping something will
> prove
useful and can be plugged into your much larger cache of knowledge
>
and help you along in your efforts.*
> **
> *The problems Jack is
facing, as I perceive them, are:*
> *1.) Humans are complex
systems.*
> *2.) Human conscious minds are a complex system/component of
the average
> human being.*
> *3.) Language is a complex system
in its own right, and is also
> a component of the human conscious
mind.*
> *4.) There is a relation between the human mind and language
which is
> also complex.*
> *5.) /Semantics/ are indispensable
_within_ the complex system that is
> "language"-- as is /Context
/(there is a crucial relation there, between
> those two
aspects).*
> *6.) Semantics and context are also indispensable in the
complex
> relation between human minds and language.*
> *7.)
Computers are finite and are, therefore, incapable of fully
> modeling
any complex system.*
> **
> *The good news, on the other hand,
is:*
> *1.) This is intended to be an interactive tool and therefore its
finite
> incompleteness is not a fatal limitation: The human mind and
human
> relational ability will come along "for free" in any actual use
of this
> interactive tool. (In other words; it's meant to be part of a
larger
> chimerical system of
human-and-computer-and-interactive-tool.)*
> *2.) Reductional models of
complex systems can be incredibly useful and,
> in fact, organisms
naturally incorporate the formation and functional
> use of such
reductions within themselves in the natural world (i.e.;
> Anticipatory
Systems) to great effect, all the time.*
> *3.) It should be possible to
figure out which aspects of the complex
> systems being modeled can
"safely" (safety being a relative term!) be
> dispensed with and which
cannot, such that the use of the models doesn't
> generate intolerable
"side effects".*
> *4.) It should also be possible to list which
potential side effects
> would be intolerable (a term which I would
tentatively define as
> meaning: limited/limiting to a negative degree
/and/ unable to be
> compensated for via the interactive human mind
using the program) and
> which potential side effects are clearly
tolerable (easily compensated
> for).*
> **
> *What I
can't answer, however, is whether the resulting information will
>
provide answers which can be translated into an information-sorting
>
protocol via computer programming language rules.*
> **
>
*Judith*
> **
|