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
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
