[Top][All Lists]

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

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

From: Martin Rubey
Subject: [Axiom-developer] Re: parts, members and entries
Date: 17 Mar 2008 12:29:21 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

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

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!


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

Attachment: aggcat.spad.pamphlet.gz
Description: Binary data

reply via email to

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