[Axiom-developer] Re: parts, members and entries

[Martin Rubey]

Dear all, especially dear friCAS users,

I have now completed the first step in what I believe to be a cleanup of the
aggregate world.  I would greatly appreciate comments.

There are two major changes:

1) members returns now a Set, namely the set of distinct elements of the
   homogeneous aggregate.

2) for collections, construct is the left inverse of parts.  This was mostly
   handled this way anyway.

So far, this doesn't produce any regression in FriCAS.

I would like to discuss some other major changes:

a) I cannot see any reason why a BagAggregate is not a Collection, i.e.,
   reconstructible from the list of its parts.  However, it seems that it is
   intentional, since we have

  DictionaryOperations(S:SetCategory): Category ==
    Join(BagAggregate S, Collection(S)) with [...]

   Unless somebody can present a good reason, I'd like to make BagAggregate
   inherit from Collection.

b) currently, entries is completely redundant, although only defined for
   IndexedAggregate. I'm thinking of making renaming parts$HOAGG to
   entries$HOAGG.  Then, parts would be reserved to yield a list from which we
   can reconstruct the aggregate.  I would also like to make ARRAY2 (and
   therefore Matrix) a Collection of its rows.  Then

   "entries m" would return all entries, since Matrix R is a HOAGG R
   "parts m"   would return the rows, since Matrix R is CLAGG Row

   "entries(m)@List(Row)" would also return the rows, of course, since any
                          CLAGG X is also a HOAGG X.  But the interpreter
                          "prefers R over List Row, which proves convenient
                          here.

c) Maybe we could make CLAGG R have KOERCE List R.  After all, the list and the
   aggregate can be transformed into each other without loss of information.

   In fact, I do not understand KOERCE very well currently.  I only found
   exports KOERCE OUTFORM and KOERCE Boolean, the latterfrom Equation.
   Wouldn't it make sense to make all these individual coerce's "categorial"?

d) Currently, List is often used even when we know we are dealing with
   Sets. This can even incur a speed penalty: member? in a List is necessarily
   slower than member? in a Set, as long as the elements can be ordered.
   However, we need some more functionality in Set: for example a non-checking
   variant of "set" that takes a sorted list with no duplicates and returns a
   set.  But this has to be done very carefully.

I can't wait to hear some comments!

Martin

I attach only aggcat.spad.pamphlet, the other changes are not very interesting,
I believe.

aggcat.spad.pamphlet.gz
Description: Binary data