axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] organization


From: root
Subject: [Axiom-developer] organization
Date: Sun, 4 Jan 2004 19:19:20 -0500

Thanks for the pointers on matriods.

My current thinking runs as follows:

For each domain contruct an "index card" that contains various fields
(the index card is the structural equivalent of a "concept"). Given a
set of these index cards each field has at least one default ordering
and a default search mechanism. 

The data for the fields in the index card can be constructed by 
automated programs, for example, the compiler.

An example of an index card might contain the fields of "the general
domain structure". A general domain structure looks something like:

Foo(Join(args with sigs)): Cat with sigs == Join(dom(args with sigs))
  with sigs
  add functions

and the compiler can create an "index card" with the following fields:

 domainName: Foo
 arglist   : Join(args with sigs)
 category  : Cat with sigs
 extends   : Join(dom(args with sigs))
 with      : sigs
 add       : functions

Of course each of the parts contains subparts (the individual list of
functions) and references to other index cards (Cat with sigs), etc.
So in general there is a lot of implied structure given on each index
card.

Having created this pile of index cards we can look at the implied
structures and other interesting organizations.

Now if we look at a given FIELD in the set of index cards we can create
a program which connects the cards together. So we could classify
the cards into many networks, at least one per field. For instance, 
we could create the inheritance lattice based on the way that one 
domain uses another. 

There can be many kinds of index cards created by many kinds of parsers
(e.g. an index card that parses a pamphlet file into component parts
like title, list of chunk names, list of section names, etc). 

The general picture emerges of a very rich set of objects (the various
index cards) that are classified into dozens of different relationships. 
You can construct predicates that walk many different paths to answer a
question. For example, find the function that will be called to
multiply a matrix of complex numbers by a vector of polynomials over
the integers and tell me what file contains it. We could compute the
coercion from one domain to another per Nicolas's thesis.

This approach breaks the problem into three parts, 
writing parsers to automatically construct the index cards, 
constructing the relations, 
constructing the queries.

(The generalization which I'm exploring but not explaining is that the
index card itself is just another network. The whole thing eventually
dissolves into a very large, structured network but it's too complex
to explain that way).

I'm essentially constructing the index cards for the algebra (by hand
at the moment) to experiement with this idea. I'll post the reduced
form of these once I've completed the first pass.

Tim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]