[Fwd: Arrow system]
Thomas M. Farrelly
s720@eik.ii.uib.no
Wed, 28 Apr 1999 22:10:54 +0200
This is a multi-part message in MIME format.
--------------40CDB8943D762B9A189E5CB9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
And I keep pressing the 'Reply' buttom.
--
===============================================================================
Thomas M. Farrelly s720@ii.uib.no www.lstud.ii.uib.no/~s720
===============================================================================
--------------40CDB8943D762B9A189E5CB9
X-Mozilla-Status2: 00000000
Message-ID: <37276AC8.8BF14BA6@ii.uib.no>
Date: Wed, 28 Apr 1999 22:08:40 +0200
From: "Thomas M. Farrelly" <s720@ii.uib.no>
Organization: Universitetet i Bergen
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "RE01 Rice Brian T. EM2" <BRice@vinson.navy.mil>
Subject: Re: Arrow system
References: <AAC4EFB9EB6DD211AA5B004005A2D8D061E852@INTRUDER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"RE01 Rice Brian T. EM2" wrote:
[ snip ]
> > And in the case of the relation '=', you'll need, eighter to use
> > "shifting" or some node/atomic
> > lowlevel entity to actually compute or verify it given 'n', 'm' or both
> > ( for oldtimes sake, say '1' is given by default :). Now, "shifting" if
> > I understand it correctly, is the general case way of finding something
> > among somethings that satisfy some relation - in practice a seach, and
> > in the general case a brute force straigh forward, test _everything_,
> > search.
> >
> ok. the "shifting" of contexts was supposed to relate to the papers by John
> McCarthy called "Formalizing Context (Expanded Notes)" (i lost the URL, but
> i'm sure that the tunes site has it somewhere). so that related to
> interpreting information gained by one computation for the use of another,
> unrelated computation.
>
> the searching problem, as you state it, is another issue. i think that the
> solution could be found by a simple idea: suppose we take some data-format
> (a state-machine algebra) and define its information in terms of arrows. it
> should be easy, then, to store most of the arrow system's information in
> terms of that data structure, based on the efficiency of the encoding
> (information density, search-and-retrieval times, etc). we could then, for
> instance, store information in syntax trees (like LISP) and retrieve it in
> the same way, constructing arrows for the information iteratively. this
> could even allow us to gain new information from, say, Lisp or Scheme source
> code.
I'm not sure I get it. You want to create a state-machine that, the same
way one can check the presence of e.g. a string, check the "presence" of
a valid system state? It sounds too simple, but it's an interesting
idea! Are you sure you wouldn't need to build a new machine for every
request?
> another thing is that not all graphs should be implemented _extensionally_
> (that is, allocating every arrow in a graph some memory). if we write a
> statement that decides whether or not an arrow belongs to a graph, then that
> statement often should be enough. (see draft sections 3.6? "intensionality"
> and 4.4? "graphs")
Yes, this is how you do infinite structures.
>
> > Now, where I'm getting at is: What kind of computational model do you
> > propose? ( that is: how will the system in practice process requests
> > like "what is n?" ?) It would be interesting, in the context of arrows
> > beeing a very general form of data organisation, to see what complexity
> > it would have, and what compromizes ( if any ) and restrictions ( if any
> > ) it would have.
> >
> in this case, i would generally propose lambda-calculus, which is acheived
> quite readily by the arrow system when you make category diagrams. category
> diagrams are just arrow graphs where all arrows compose sequentially. the
> arrows represent lambdas, and the nodes represent expression types.
> otherwise, i believe that ontologies and algebras could help to define any
> execution scheme that a person could imagine, even complicated ones.
>
If I understand correctly, then arrows in their raw form must be
interpreted in some context. E.g. when you say above that
lambda-calculus can be achieved by regarding the arrows as those in a
category diagram. Other examples are object diagrams to model the state
of a system ( how the actual instances of things are connected together
), and state diagrams to model the transitions between different states
in the system.
I think this is where coloring of arrows, as June Kerby talks about,
comes in. In that scheme, you would say that a category diagram style
arrow is one color and a state transition style arrow is another. In the
general case, you would need one mother of a pallette. I guess you
wouldn't want coloring in your model, but still the problem of "what
does the arrow connecting these two enteties mean?" must be addressed in
some way.
There is however an alternative to coloring, that better fits the style
of your model, and that is contexts, saying that the color of the arrow
is dependent on the situation.
But there are some problems with this that you might not want. First of
all the "situation" is dependent on the evaluation of something and then
you need context switches - but these context switches, beeing all
arrows, need some meta context switch in order to apply the proper
interpretation. And there will be _alot_ of context switching.
The second problem ( I personally see this as a property and not a
problem, but I know Brian is against hierchies ) is that contexts,
always working on homoiconic arrows ( no coloring ), eventually end up
forming a hierchy. I.e. one context, formed by the area of switch-on to
switch-off, _must_ be contained fully inside or fully outside any other
context.
Imagine contexts 'S', for "legal state transition", and 'C', for "is in
the same category as". I'll denote a context with labled parenteses,
i.e. '(C' and 'C)'. Small letters are things to be interpreted. Now, if
I say:
(C a (S b C) c S)
Then, given that the system is homoiconic, there is no-way to give any
meaning to 'b'. Choosing to view 'b' as talking about state transition,
gives you a 50% chance of failure - it's ambiguous.
If, on the other hand the system was not homoiconic, i.e. two different
types of arrows, then one can imagine that 'C' effected another type of
arrow then 'S'. That could work, but there would be inpureness or
sideeffects, and code would need to be veryfied at a level prior to
reflection - and you don't want that.
Conclusion ( please flame me if I'm wrong ) : In a homoiconic system,
the need for interpreting information dependent on context, enforces
some hierchical property on the system.
But this is not a data structuring kind of hierchy like Pre Cambrium (
I'm wearing the T-shirt :) file system. In the worst case it's a runtime
thing - like the reason we use stacks so much.
===============================================================================
Thomas M. Farrelly s720@ii.uib.no www.lstud.ii.uib.no/~s720
===============================================================================
--------------40CDB8943D762B9A189E5CB9
X-Mozilla-Status2: 00000000
Message-ID: <372612EC.44541A7D@ii.uib.no>
Date: Tue, 27 Apr 1999 21:41:32 +0200
From: "Thomas M. Farrelly" <s720@ii.uib.no>
Organization: Universitetet i Bergen
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "RE01 Rice Brian T. EM2" <BRice@vinson.navy.mil>
Subject: Arrow system ( was: Re: Interesting quote from AI book )
References: <AAC4EFB9EB6DD211AA5B004005A2D8D061E84C@INTRUDER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"RE01 Rice Brian T. EM2" wrote:
>
> > lets' assume that it takes N graphs of arrows to describe all of the
> > aspects of an equation embodied by a written statement. these N graphs
> > wouldn't apply to just that equation, though.
> >
> > example:
> > n=m+1
> >
> > there would be an arrow between the atoms for 'n' and 'm+1' that would be
> > part of the graph linked to '=' (think of '=' as a relation, and as a set
> > of arrows).
> > there would be an atom for 'm+1' would be an arrow in the '+' graph
> > linking the atoms for 'm' and '1'.
> > 'n', 'm', and '1' would be arrows (selectors) from sets of atoms: 'n' and
> > 'm' would be part of a particular user context vocabulary (called an
> > ontology), and '1' would be an arrow from the set of natural or integer or
> > whatever kinds of numbers (again, in a graph).
> >
> (parenthetic: i'm really happy that my ideas are coming across well, now,
> and i intend to continue my efforts in that direction. this discussion i'm
> intending to use to provide examples for the paper, along with diagrams;
> this process is already underway, but difficult.)
( Is there a shang-hi button on your browser ?) :D
>
> to continue,
> there's more to this example than '=' and '+', as is obvious: this is where
> the concept of an ontology (and the resulting relativism) comes into play.
> we'd like to specify the set of vocabulary that is defined within a given
> context, and use this to shift contexts computably and preserve the meaning
> of the vocabulary.
Ok. I'll try to clarify how I interpret that:
An ontology, or part of one, specifially the natruall numbers, define
some degree of freedom.
As in 'n=m+1', '=' restricts this freedom to the corelation of 'n' and
'm+1' in the ontology
of the natrual numbers ( so that 'n' and 'm+1' would reference the same
actual number ).
If you say, 'n=m+1', the system ( beeing always consistent, I suppose ),
that must be the fact.
If I ask for the natrual number interpretation of 'n', then all the
relations concerning 'n'
must be taken into account, and the answere would be all the possible
natrual number interpretations of 'n' which does not break consistency.
You very much want this to be a single pass iterative process, but I'm
suprised if it is.
And in the case of the relation '=', you'll need, eighter to use
"shifting" or some node/atomic
lowlevel entity to actually compute or verify it given 'n', 'm' or both
( for oldtimes sake, say '1' is given by default :). Now, "shifting" if
I understand it correctly, is the general case way of finding something
among somethings that satisfy some relation - in practice a seach, and
in the general case a brute force straigh forward, test _everything_,
search.
Now, where I'm getting at is: What kind of computational model do you
propose? ( that is: how will the system in practice process requests
like "what is n?" ?) It would be interesting, in the context of arrows
beeing a very general form of data organisation, to see what complexity
it would have, and what compromizes ( if any ) and restrictions ( if any
) it would have.
My imediate guess would be that since it is uttermost flexible, then
evaluating would be uttermost complex. But these are just guesses,
wouldn't help you if they could.
===============================================================================
Thomas M. Farrelly s720@ii.uib.no www.lstud.ii.uib.no/~s720
===============================================================================
--------------40CDB8943D762B9A189E5CB9--