Meanings; Op Cond code

[From Bill Powers (941018.2250 MDT)]

Bill Leach (941015.1955 EDT)--

Things can get very "slippery" though when one tries to "pin me down"
on the term "meaning".

Hold your hand up where you can see it. What you see there is the
perceptual meaning of the word "hand". While you're watching, snap your
fingers. What you see and hear is the meaning of the words "snap
fingers". Also, the meaning of "your fingers" is contained in that
experience; if my hand were there you couldn't snap its fingers.

Now say, think, or read the word "hand" and look at your hand. What you
just said, thought, or read is a perception. This perception has
assigned to it the meaning that is the other perception that you see in
front of you.

Strictly hypothetically, that thing you see in front of you, the fingers
of which you can wiggle, is a set of perceptual signals given meaning by
the way they are derived from something else. The something else is not
visible or feelable or hearable. It is a theoretical concept called
"External Reality."

Learning how to snap your fingers is learning how to will the efforts
that will result in that thing you see out there acting and sounding in
the way you call snapping your fingers. How this willing causes the
result you perceive is not available to experience. Presumably there are
causal connections between the act of willing and the resulting change
in the perceptions. But those connections lie outside experience. We can
only model them.

···

------------------------------------------------------------------------
Bruce Abbott (941018.1550 MDT)

We may as well make this discussion public, as others will be interested
and may join in. I haven't seen your posted simulation yet; it will
probably show up tomorrow morning due to the delay through csg-l.

I'm not familiar with "objects," as in your last direct post, although I
get the idea. It seems to me that for purposes of simulation, it's much
simpler just to apply the "constant probability" directly on each
iteration. If you want to save the intervals thus generated for further
reference, you can store them as you go. An analytical form for the Nth
interval like

Tn = VI*[1 + log(N) + (N-n)*log(N-n) - (N-n+1)log(N-n+1)],

... doesn't do anyone much good as part of a mathematical treatment,
does it? If we're going to simulate, let's do it the easy way.

I'm appending a Turbo Pascal 5.5 program (working but in progress) for a
two-key simulation including a model of the organism as a control
system. Here is a brief writeup on it.

On each iteration, each key is tested to see if it is already enabled,
and if not, it is enabled with a probability k/10000. The routine is

  for i := 1 to maxkey do
   if not enabled[i] then enabled[i] := random(10000) < k[i];

The value of k[i] would be set to 100 to give a probability of 0.01 of
enabling the key on any iteration. A minimum time could be worked in
here by keeping track of iterations after enablement is turned off by a
reinforcement, and not permitting a new enablement for whatever the
minimum should be. I haven't done that yet.

The model senses a quantity called q1, which represents something like
the quantity of food ingested. q1 is increased by reinfsize[i] on every
reinforcement, and decays with a time-constant decay1. It is compared
with a reference level r1 fixed for now at 100. The error signal r1 - p1
is multiplied by a gain factor g1, with the product being added to an
output accumulator o1. When o1 reaches a level omax, set to 100, a
response is generated and o1 is reset to zero. This is a way of
converting an error signal linearly into a rate of pecking. The control
system is given by

  q1 := q1 * decay1;
  e1 := g1*(r1 - q1);
  if e1 < 0.0 then e1 := 0.0; {negative errors accomplish nothing}
  o1 := o1 + e1;
  peck := o1 > o1max;

If a peck has occurred, the next section counts it, resets the peck flag
to false and o1 to zero, and if the active key is enabled, counts the
reinforcement, resets the enabled flag, and add reinfsize[key] to the
input quantity q1.

  if peck then
   begin
    o1 := 0.0;
    peck := false;
    inc(numpecks[key]);
    if enabled[key] then
     begin
      enabled[key] := false;
      inc(numreinf[key]);
      q1 := q1 + reinfsize[key];
{Here is where to set a key-associated counter for
    delaying re-enablement for a minimum time}
     end;
   end;

Then comes a section that shows the data either as a plot or some
calculations, neither display being worked out in any detail.

After that is a section that, at somewhat random intervals, makes a
switch from one key to another:

  if (clock mod (2000 + random(3000))) = 0 then
   begin
    oldkey := key;
    repeat
     key := 1 + random(maxkey);
    until key <> oldkey;
   end;

Finally, there's a section that detects a keystroke and if it is a
space, switches back and forth between a graphical display and an ASCII
numerical display. If the character is 'q', the program exits.

All sorts of tidying up can be done, needs to be done, but I thought I'd
get this on the table rather than waiting for perfection. The various
sections above could be extracted as procedures -- the thing runs fast
enough so the extra time caused by procedure calls won't matter. One
thing that really needs to be done is to make possible changing the
constants from the keyboard while the program is running. Right now
they're in an "initialize" procedure, so you have to change constants
with the editor and recompile. With my TP, recompiling takes about a
quarter of a second, so it's no big deal, but the other way is better
for obvious reasons.

This is a short program, only about 150 lines, so it should be easy to
play with. The graphics initialization needs the Borland .BGI files, the
way I wrote it; only the standard Units are used.

Oh, yes: I set up the initialization just to get something to look at.
The actual scaling to get realistic numbers is left as an exercise for
me (or anyone) at a later time.

Here's the source code:

program varint;

uses dos,crt,graph;

const
maxkey = 2;

var
reinfsize: array[1..maxkey] of real;
k: array[1..maxkey] of integer;
enabled: array[1..maxkey] of boolean;
peck,graphdisplay: boolean;
numpecks,numreinf: array[1..maxkey] of longint;
q1,o1,e1,o1max,r1,p1,g1: real;
maxx,maxy: integer;
ch: char;
decay1: real;
i,x,key,oldkey,t: integer;
clock: longint;
re1,re2,b1,b2: real;
graphmode,graphdriver: integer;

procedure setgraphics;
begin
graphdriver := 0; graphmode := 0;
detectgraph(graphdriver,graphmode);
initgraph(graphdriver,graphmode,'');
graphmode := getmaxmode;
setgraphmode(graphmode);
maxx := getmaxx; maxy := getmaxy;
clearviewport;
graphdisplay := true;
end;

procedure showdata;
   begin
    gotoxy(1,key); write('key ',key,' Num reinf = ',numreinf[key]:10);
    gotoxy(1,3+key); write('key ',key,' Num Pecks = ',numpecks[key]:10);
    gotoxy(35,1);
    re1 := re1 + 0.1*(numreinf[1] - re1); { smooth for display}
    re2 := re2 + 0.1*(numreinf[2] - re2);
    b1 := b1 + 0.1*(numpecks[1] - b1);
    b2 := b2 + 0.1*(numpecks[2] - b2);
    if ((re1 + re2) > 0.0) and ((b1 + b2) > 0.0) then
    write('r1/(r1+r2) = ',re1/(re1+re2):5:3,' b1/(b1+b2) =
',b1/(b1+b2):5:3);
   end;

procedure showgraph;
begin
putpixel(40+x,maxy - round(4.0*q1),lightgreen);
putpixel(40+x,maxy - round(4.0*r1),lightgreen);
putpixel(40+x,maxy - numreinf[key] div 50,lightmagenta);
putpixel(40+x,maxy - numpecks[key] div 1000,yellow);
putpixel(40+x,maxy, lightgray);
inc(x);
if x >= maxx - 40 then
  begin
   clearviewport;
   setcolor(lightgreen);
   outtextxy(0,0,'r and q1');
   setcolor(yellow);
   outtextxy(100,0,' numpecks/1000');
   setcolor(lightmagenta);
   outtextxy(300,0,' numreinf/50');
   setcolor(white);
   x := 0;
  end;
end;

procedure initialize;
var i: integer;
begin
for i := 1 to maxkey do
begin
  enabled[i] := true;
  reinfsize[i] := 0.2;
  numreinf[i] := 0;
  numpecks[i] := 0;
end;
k[1] := 33;
k[2] := 100;
decay1 := 1 - 1e-5;
o1max := 100.0;
g1 := 10.0;
r1 := 100.0;
q1 := 0.0;
o1 := 0.0;
key := 1;
clock := 0;
re1 := 0; re2 := 0; b1 := 0; b2 := 0;
end;

begin
t := 0; x := 0;
clrscr;
setgraphics;
initialize;
ch := chr(0);
while ch <> 'q' do
begin
  for i := 1 to maxkey do
   if not enabled[i] then enabled[i] := random(10000) < k[i];
  q1 := q1 * decay1;
  e1 := g1*(r1 - q1);
  if e1 < 0.0 then e1 := 0.0;
  o1 := o1 + e1;
  peck := o1 > o1max;
  if peck then
   begin
    o1 := 0.0;
    peck := false;
    inc(numpecks[key]);
    if enabled[key] then
     begin
      enabled[key] := false;
      inc(numreinf[key]);
      q1 := q1 + reinfsize[key];
     end;
   end;
  if((clock mod 100) = 0) then
   if graphdisplay then
    showgraph
   else showdata;
  if (clock mod (2000 + random(3000))) = 0 then
   begin
    oldkey := key;
    repeat
     key := 1 + random(maxkey);
    until key <> oldkey;
   end;
   inc(clock);
   if keypressed then
    begin
     ch := readkey;
     if ch = ' ' then
      begin
       graphdisplay := not graphdisplay;
       if graphdisplay then
        begin
         setgraphmode(graphmode);
         clearviewport;
         setcolor(lightgreen);
         outtextxy(0,0,'r and q1');
         setcolor(yellow);
         outtextxy(100,0,' numpecks/1000');
         setcolor(lightmagenta);
         outtextxy(300,0,' numreinf/50');
         setcolor(white);
         x := 0;
        end
       else
        begin
         restorecrtmode;
         clrscr;
        end;
      end;
    end;
end;
restorecrtmode;
closegraph;
end.

<[Bill Leach 941022.14:28 EST(EDT)]

[Bill Powers (941018.2250 MDT)]

Hold your hand up where you can see it. What you see there is the
perceptual meaning of the word "hand". ...

Bill, none of that "bothers" me. It is only that such meanings are often
thought to be precise (particularly with respect to shared understanding)
when indeed they are not.

Few, if any, people would disagree in a general way with what a "hand" is
but if you were to ask several people just where the hand "begins" and
where the wrist "ends" then the certainty dissolves.

Fortunately, for most purposes such "fine" distinctions are of little
import.

Now say, think, or read the word "hand" and look at your hand. What you
just said, thought, or read is a perception. This perception has
assigned to it the meaning that is the other perception that you see in
front of you.

Strictly hypothetically, that thing you see in front of you, the fingers
of which you can wiggle, is a set of perceptual signals given meaning by
the way they are derived from something else. The something else is not
visible or feelable or hearable. It is a theoretical concept called
"External Reality."

Learning how to snap your fingers is learning how to will the efforts
that will result in that thing you see out there acting and sounding in
the way you call snapping your fingers. How this willing causes the
result you perceive is not available to experience. Presumably there are
causal connections between the act of willing and the resulting change
in the perceptions. But those connections lie outside experience. We can
only model them.

In common discourse, I can and do get just as confused as the next person
when it comes to remembering these relationships however, I do recognize
and accept what I see as the essential truth of such assertions.

I am not completely certain that we do not sometimes experience
"learning". Even I don't think that we experience the process in any
"understandable" or "logical" way but I am convinced that I have had
perceptions that were somehow related to "experiencing" a "unique"
learning process. I suspect that the "flash of insight" that one "feels"
on occassion is more than just "realizing" that one now understands
something that only moments before was a mystery.

By this, I don't mean to sound mystical myself, I don't mean that at all.
Rather, I believe that some learning experiences are possibly dramatic
enough or maybe "important" enough to result in a perceptual value change
that has a large "emotional" impact.

-bill