[Axiom-developer] Re: Embedding Axiom (Hickey and fold/unfold) Folding and generalization

[Tim Daly]

Martin Baker wrote:
> I think it helps to get a wider perspective.
>
> Part of what prompted my question is when I was thinking about how to 
> implement the exterior product I thought about possible options, for instance 
> rules:
>
> <e1, e2…en | ei/\ei=0, ei/\ej= -ej/\ei>
>
> or an algorithm:
>
> And(b1::SINT,b2::SINT) ~= 0 => z
> c := c1 * c2
> bz := Or(b1::SINT,b2::SINT)
> for i in 0..n-1 | bit?(b1,i) repeat
>   k := 0
>   for j in i+1..n-1 | bit?(b1, j) repeat k := k+1
>   for j in 0..i-1   | bit?(bz, j) repeat k := k+1
>   if odd? k then c := -c
>   z.bz := z.bz + c
> z
>
> or a multiplication table:
>
> 0      e1^e2
> -e1^e2 0
>
> Out of these options, the rules just seems to be operating at a higher level? 
> In that it would seem relatively easy to translate from the rules to the 
> algorithm but a lot more difficult to go from the algorithm to the rules 
> (could Concordia do it?).  Also, unlike the algorithm, there is no need to 
> introduce the concept of time. I wonder which type would be the best for 
> making a test for equivalence?
>
> I take your point that the rules are not necessarily better for parallel 
> processing and they don't scale up very well, I wonder if there would be some 
> way to get the best of all these approaches? lots of small rule bases or 
> something like that?
>
> Another point is that there are no 'side effects' to this function but we are 
> trying to add one in by caching the multiplication table!
>
> I don't have any answers but its interesting to speculate,
>   

I like the declarative form a lot, which would fit rules rather well. I 
think you understand
my feelings on rules being non-algebraic, though, and I'd advise against it.

The table form could get very large (unless you only cache computed 
entries).
The table form would also require some matching since "e1" could be 
something
more complex than a symbol.

I think that the procedural form gives you the most flexible version since
(a) it fits into the spad coding scheme and (b) allows you to manipulate the
internal representations in efficient ways that can "violate causality" 
within
the function without being visible to the user. It also gives you the 
opportunity
to coerce to more specific forms (like linear algebra forms) in special 
cases.

In addition, the coding form will force you to be explicit about the 
categories
that need to be defined. I think one of the key strengths of Axiom is 
the organization
of the system into categories. If you started with Operads (per William 
Sit's comments)
as categories and derived your Grassmann/Clifford/Octonion forms in a 
disciplined
way then everyone wins. I will admit that this is VERY hard. I tried to 
do this for
the Infinite Group Theory area and failed. (Hardly a surprise since I'm 
not an
Infinite Group Theorist by any stretch of the imagination.)

William may have some useful insights here as he is a mathematician and an
Axiom algebra author.

Tim