dkrenn
commented
9 years ago Branch: u/dkrenn/asy/mutable_poset
Closed dkrenn closed 8 years ago
dkrenn
commented
9 years ago Branch: u/dkrenn/asy/mutable_poset
dkrenn
commented
9 years ago Last 10 new commits:
67522ab | add-method: allow cancellation of elements |
91c071b | moved hook from add to __init__ |
bdc3f16 | rename: value --> element --> shell |
434f4e1 | write method element |
98e20b0 | improve/extend docstrings |
5488f10 | conditional iterations for shells |
f00d323 | rename element_exists_hook to merge_hook |
1dc03d7 | introduce can_merge and rename merge_hook to merge |
960b18b | a couple of minor rewritings to make the code and doctests nicer |
e2f884f | write merge-methods |
dkrenn
commented
9 years ago Author: Daniel Krenn
6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
9 years ago A mutable poset class should be stored in sage.combinat.posets.
Nathann
dkrenn
commented
9 years ago This series of comments are the result of an email discussion. Its aim is to give a better understanding of the needs of the data structure used in an asymptotic expression.
An example of an asymptotic expression in say 2 variables (n->oo, t->oo) is
A = n^3*t^2 + 42*n^2*t^2 + 3*n*t^4 + O(t)This is stored in the mutable poset in the following way: the elements of the poset are exactly the summands of the expression above. This means
sage: A.data # or however this may be called
poset(n^3*t^2, 42*n^2*t^2, 3*n*t^4, O(t))The growth of these summands is partially ordered:
a) n<sup>3*t</sup>2 >= n<sup>2*t</sup>2
b) n<sup>3*t</sup>2 >= t
c) n<sup>2*t</sup>2 >= t
d) n*t^4 >= t
The mutable poset stores/caches the direct successors/predecessors, i.e., only the relations a), c), d), but not b), since this follows by transitivity out of a) and c). Thus, for the example above, we have the following information stored
poset
- term O(t)
successors: n^3*t^2, 42*n^2*t^2, 3*n*t^4
no predecessors
- term 3*n*t^4
no successors
predecessors: O(t)
- term 42*n^2*t^2
successors: n^3*t^2
predecessors: O(t)
- term n^3*t^2
no successors
predecessors: 42*n^2*t^2We want to perform arithmetic with asymptotic expressions, in particular we need to do efficiently: 1) addition (and multiplication) 2) merging/absorbing terms, e.g.
n^4 + 2*n^2 + 3*n + O(1) + O(n^2) = n^4 + O(n^2)or
O(n*t) + n + t = O(n*t)3) removing elements of the poset, because of 2)
To make them efficent, we store successors and predecessors of each element in the poset. These are updated when inserting/removing elements.
Note that an asymptotic expression can contain several O-terms, e.g.
O(n^3 t^2) + O(n^4 t^1) + O(n^2 t^3)is a valid expression. In the poset each O-term is a minimal element and they are all pairwise incomparable (thus, the O terms will be an antichain in the poset). Anyhow, non-O-terms be be compareable to other elements, e.g. in
3*n*t + O(n) + O(t)we have n*t >= n and n*t >= t.
We also need to deal with situations where we want to insert an
element of the same growth: E.g. 4n+3n = 7n, 4n+O(n) = O(n),
thus, the elements themselves can change during addition. When
merging/absorbing and working with O-Terms with explicit
O-constants, this also occurrs frequently (even with terms of
different growth).
dkrenn
commented
9 years ago Note that all the terms (individual summands) support one operation, namely these can be multiplied, maybe coercion is used, e.g.
4*n^2*t * O(n) --> O(n^2*t) * O(n) --> O(n^3*t)Thus we have monoids here. "Addition" of terms is more complicated since not always possible. E.g.
n + O(t) = n + O(t)But since this is an operation we want to have, the data structure has to take this into consideration.
Here an example of the addition of two asymptotic expressions, to see what the poset should do:
B = n^2*t + n + O(1)
C = n*t^2 + O(n)Steps in computing B + C:
1) calculate: B.poset union C.poset This gives
poset(n^2*t, n, O(1), n*t^2, O(n)).2) simplify: returns
poset(n^2*t, n*t^2, O(n))To achieve this, we have to search for what can be "absorbed" by the
O-term O(n). These are exactly all the predecessors of O(n) (not only
the direct, but also the predecessors of the predecessors...)
Thus some kind of caching of predecessors is necessary, but "cache"
has to be updated when modifying the poset.
Note that this data structure does a preprocessing of its relations, which is definitely good for nonsmall instances. At the moment this class should provide an interface for the needed routines. A fine tuning (w.r.t. speed optimization for various sizes) can be done later (if the performance is too bad).
To conclude, the data structure needed in an asymptotic expression needs to deal with dynamic changes (mutability) and do some caching to provide efficient methods. And it needs to do more than a poset which is made mutable. In particular, it has to provide the methods for the above mentioned merging and absorbing.
dkrenn
commented
9 years ago Replying to @nathanncohen:
A mutable poset class should be stored in
sage.combinat.posets.
This class has nothing to do with combinatorics, therefore I am against sage.combinat. And it implements a data structure and we have sage.data_structures, so it seems the right place.
6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
9 years ago This class has nothing to do with combinatorics, therefore I am against
sage.combinat. And it implements a data structure and we havesage.data_structures, so it seems the right place.
Graphs are a data structure, they are in graphs/. Incidence Structures are data structure, and they are in combinat/designs. Matrices are a data structure, and they are in matrix/. Posets and Hasse Diagrams are a data structure, and they are in combinat/posets/.
Also, you wrote in your branch a 'todo note' to implement in your MutablePoset data structure that 20+ methods from the current Posets should be implemented for your new class: the proper way to do that would be to inherit them from posets.
Could you also explain what "shells" are, and how they differ from the 'facade' boolean argument of Posets ?
Thanks,
Nathann
cheuberg
commented
9 years ago Replying to @nathanncohen:
Also, you wrote in your branch a 'todo note' to implement in your
MutablePosetdata structure that 20+ methods from the current Posets should be implemented for your new class: the proper way to do that would be to inherit them from posets.
A FinitePoset inherits from Parent and my understanding is that parents must be immutable.
Thus, IMHO, this mutable poset here should not inherit from FinitePoset.
6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
9 years ago A
FinitePosetinherits fromParentand my understanding is that parents must be immutable.
Indeed, but it may actually be time to change that. We are also having problem with this, because apparently the construction of Parent/UniqueRepresentation instances is known to be very slow, and you "should not build too many of them at once" or it will slow code down a lot.
That is what is already preventing us from implementing a proper iterator over all non-isomorphic posets of a given size: this operation creates too many parents and is the bottleneck in the computations.
If it seems that you are bothered by the same thing, it gives all the more reasons to make that change.
Nathann
dkrenn
commented
9 years ago Replying to @nathanncohen:
Could you also explain what "shells" are, and how they differ from the 'facade' boolean argument of Posets ?
There are similarities between shells and facades, but a facade is something in Sage that represent other things and again uses parents/elements (thus immutable). It has well-defined properties and there is even a category for facade sets. The shells in the mutable poset are more like a container for the elements. Ideally a user of the poset does not need them at all (and only a few MutablePoset-methods use them). They are only used inside the poset-algorithms. At one point I thought about making shells and the related methods private, but never did this...
jdemeyer
commented
9 years ago Replying to @nathanncohen:
Graphs are a data structure
No, graphs are mathematical objects. "a binary symmetric matrix implemented using bitsets" (which could be used for dense graphs) is a data structure.
6bdad4c1-1e26-4f2f-a442-a01a2292c181
commented
9 years ago Graphs are a data structure
No, graphs are mathematical objects.
I was not thinking of a graph as it is defined in a book, but of Sage's graphs. I should have said "the Graph class" probably.
Nathann
dkrenn
commented
8 years ago Changed branch from u/dkrenn/asy/mutable_poset to u/dkrenn/asy/mutable-poset
dkrenn
commented
8 years ago Last 10 new commits:
143dfea | write method element |
b348d14 | improve/extend docstrings |
520bb00 | conditional iterations for shells |
e443f7e | rename element_exists_hook to merge_hook |
b79f1bc | introduce can_merge and rename merge_hook to merge |
82ed0f3 | a couple of minor rewritings to make the code and doctests nicer |
13d4a36 | write merge-methods |
8584f57 | write __len__ |
a1678ed | remove TODO-list of methods (list is now in separat branch) |
1c6b196 | write methods for maximal/minimal elements |
f29946bc-ee7b-48cd-9abc-3445948c551d
commented
8 years ago If union() does same thing as disjoint_union() in posets and in graphs, please change name accordingly. It seems unnecessary to have INPUT-part at all, if the function has no arguments at all.
Just my two cents. I would give three, if I would have more time.
dkrenn
commented
8 years ago Replying to @jm58660:
If
union()does same thing asdisjoint_union()in posets and in graphs, please change name accordingly.
No, it does not do the same. Union takes only one instance of equal elements, whereas disjoint_union makes each one of the equal elements distinct.
It seems unnecessary to have
INPUT-part at all, if the function has no arguments at all.
The developer guide
http://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-stringssays
An INPUT and an OUTPUT block describing the input/output of the function. This is not optional.Therefore skipping one of these blocks seems to be against the rules (and hopefully helps avoiding the confusion of a missing input block).
Just my two cents. I would give three, if I would have more time.
Many thanks for all your cents.
Best, Daniel
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
8 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
8 years ago Branch pushed to git repo; I updated commit sha1. New commits:
19fd155 | allow merge to go over all elements |
f29946bc-ee7b-48cd-9abc-3445948c551d
commented
8 years ago Replying to @dkrenn:
Replying to @jm58660:
If
union()does same thing asdisjoint_union()in posets and in graphs - -No, it does not do the same.
OK.
It seems unnecessary to have
INPUT-part at all, if the function has no arguments at all.The developer guide says
An INPUT and an OUTPUT block describing the input/output of the function. This is not optional.
True. But I don't think if it has been thinked that "no input" must be documented. Is it in other places? Or should this part of developer guide be changed?
And should for example docstring of .cardinality() really contain OUTPUT-block saying that output type is sage's Integer?
dkrenn
commented
8 years ago Replying to @jm58660:
The developer guide says
An INPUT and an OUTPUT block describing the input/output of the function. This is not optional.True. But I don't think if it has been thinked that "no input" must be documented. Is it in other places? Or should this part of developer guide be changed?
I would keep it. (At the moment) the developer guide says to include it and I find it very nice to have constistent docstrings starting with one-liner, INPUT, OUTPUT, more details, EXAMPLES, ...
(And: there are other places.)
And should for example docstring of
.cardinality()really containOUTPUT-block saying that output type is sage'sInteger?
What do you suggest?
f29946bc-ee7b-48cd-9abc-3445948c551d
commented
8 years ago Replying to @dkrenn:
Replying to @jm58660:
The developer guide says
An INPUT and an OUTPUT block describing the input/output of the function. This is not optional.True. But I don't think if it has been thinked that "no input" must be documented. Is it in other places? Or should this part of developer guide be changed?
I would keep it. (At the moment) the developer guide says to include it and I find it very nice to have constistent docstrings starting with one-liner, INPUT, OUTPUT, more details, EXAMPLES, ...
This is discussed at #19041. But don't let this stop coding -- Sage will propably never get finished so that questions like this would have The Final Answer.
And should for example docstring of
.cardinality()really containOUTPUT-block saying that output type is sage'sInteger?What do you suggest?
Every cardinality() should return Integer. For other integer-valued functions there were discussion about int vs. Integer without consensus.
I don't know. For input it is explicitly said that the docstring can say "x in integer", not "x must be Integer or int". These are hard questions, as what is "clear" varies from one person to other.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
8 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
8 years ago Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
2863321 | allow merge to go over all elements |
9391c78 | derive MutablePoset from object (instead of SageObject) |
70859d7 | cleanup: delete toset since not yet implemented |
d647d95 | write map and mapped |
e64cbd8 | mapping argument for .copy() |
c28749c | bring map and mapped back to work and use new copy-construction |
ceb0b37 | fix bug in merge |
dkrenn
commented
8 years ago Last 10 new commits:
8584f57 | write __len__ |
a1678ed | remove TODO-list of methods (list is now in separat branch) |
1c6b196 | write methods for maximal/minimal elements |
2863321 | allow merge to go over all elements |
9391c78 | derive MutablePoset from object (instead of SageObject) |
70859d7 | cleanup: delete toset since not yet implemented |
d647d95 | write map and mapped |
e64cbd8 | mapping argument for .copy() |
c28749c | bring map and mapped back to work and use new copy-construction |
ceb0b37 | fix bug in merge |
behackl
commented
8 years ago Hello!
I reviewed this ticket, and here are my comments:
MutablePoset, MutablePosetShell: derived from object vs. SageObject?is_null, is_oo: is there some usecase for the reverse keyword? For predecessor and successor: this is clear, as it makes the code easier. However, I think that a reverse-keyword for is_null and is_oo is rather irritating.MutablePosetShell.le: shouldn't doctests like elem1 <= elem2 be marked as indirect?MutablePosetShell._copy_all_linked_: 1st sentence should be a short description. Likewise for MutablePosetShell._iter_depth_first_visit_ and MutablePosetShell._iter_topological_visit_.sorted_set_by_tuple can be easily replaced by[...].join(repr(e) for e in sortedshells if e in shell.successors(rev))and the occurrence of is_MutablePoset can be replaced by a simple isinstance-call.
MutablePoset.shells: I do not understand the usecase of the reverse keyword. Can it be removed?MutablePoset.add: I think that a comment (in the code) that roughly explains what the passage beginning with for reverse in (False, True): does would be nice. It took me quite some time to understand and verify the functionality of this block.MutablePoset.discard: why isn't this simply an alias of MutablePoset.remove? As remove has no return value, discard cannot have one either, if that was the intention.MutablePoset.union, MutablePoset.difference etc. left and right, instead of self and other? IMHO, this disguises that the function can be called as P.union(Q).sage: PR.<x> = ZZ[]
sage: P = MutablePoset(key=lambda k: len(k.list()))
sage: P.add(42*x)
sage: P.add(21*x^2)
sage: Q = MutablePoset(key=lambda k: len(k.list()))
sage: Q.add(1111*x)
sage: P, Q
(poset(42*x, 21*x^2), poset(1111*x))
sage: Q.is_subset(P)
True
sage: Q.union(P)
poset(1111*x, 21*x^2)and so on. In principle, I don't see this as a problem---however, I'd state this explicitly in each of these set operation functions.
MutablePoset.mapped: why is this function needed? Purely for semantical reasons? I'd move the doctests to MutablePoset.copy.MutablePosetShell._copy_all_linked_: is the memoization using the id of the object a standard procedure? I thought about it, but I'm not entirely sure that this isn't a potential error source.Side note: the MutablePoset is the central data structure in our AsymptoticExpansions framework (cf. #17601). In this context, the functionality has been tested extensively--and some peculiarities (like the map-function etc.) are motivated by this application.
Also, I've made a few reviewer commits concerning the documentation; the branch is attached.
As soon as the points I've raised in the comments above are discussed, this would be a positive_review from my side.
Benjamin
Last 10 new commits:
e64cbd8 | mapping argument for .copy() |
c28749c | bring map and mapped back to work and use new copy-construction |
ceb0b37 | fix bug in merge |
525bf3c | Merge branch 'u/dkrenn/asy/mutable-poset' of git://trac.sagemath.org/sage into 6.9.beta5 |
bf1928f | remove unused import |
98a7939 | print something --> print(something) |
2a7ab88 | several improvements to documentation (language, structure) |
a4c43b7 | fixed two examples-blocks |
a867d3a | indentation (PEP 8) |
c1f8877 | improved errors and added two doctests |
behackl
commented
8 years ago Changed branch from u/dkrenn/asy/mutable-poset to u/behackl/asy/mutable-poset
f29946bc-ee7b-48cd-9abc-3445948c551d
commented
8 years ago Benjamin, please put your name to reviewers-field. Otherwise Volker will reject this.
behackl
commented
8 years ago Thanks for the reminder, Jori!
Benjamin
behackl
commented
8 years ago Reviewer: Benjamin Hackl
dkrenn
commented
8 years ago Changed branch from u/behackl/asy/mutable-poset to u/dkrenn/asy/mutable-poset
dkrenn
commented
8 years ago Changed branch from u/dkrenn/asy/mutable-poset to u/behackl/asy/mutable-poset
dkrenn
commented
8 years ago Replying to @behackl:
MutablePoset,MutablePosetShell: derived fromobjectvs.SageObject?
object.
is_null,is_oo: is there some usecase for thereversekeyword? Forpredecessorandsuccessor: this is clear, as it makes the code easier. However, I think that areverse-keyword foris_nullandis_oois rather irritating.
Keyword deleted.
- doctests for
MutablePosetShell.le: shouldn't doctests likeelem1 <= elem2be marked as indirect?
Yes, I've marked them.
MutablePosetShell._copy_all_linked_: 1st sentence should be a short description. Likewise forMutablePosetShell._iter_depth_first_visit_andMutablePosetShell._iter_topological_visit_.
Rewritten.
- sorted_set_by_tuple, is_MutablePoset: are these functions really necessary? Both are only used once within the whole file. The occurrence of
sorted_set_by_tuplecan be easily replaced by[...].join(repr(e) for e in sortedshells if e in shell.successors(rev))and the occurrence of
is_MutablePosetcan be replaced by a simpleisinstance-call.
sorted_set_by_tuple: Deleted and replaced.
is_MutablePoset: seems to be a standard convention to use it in Sage; see a lot of other modules.
MutablePoset.shells: I do not understand the usecase of thereversekeyword. Can it be removed?
I agree; deleted.
MutablePoset.add: I think that a comment (in the code) that roughly explains what the passage beginning withfor reverse in (False, True):does would be nice. It took me quite some time to understand and verify the functionality of this block.
I've added a comment.
MutablePoset.discard: why isn't this simply an alias ofMutablePoset.remove? Asremovehas no return value,discardcannot have one either, if that was the intention.
See Python's set (the same behavior there).
- Is there a particular reason for naming the parameters for all the set operations like
MutablePoset.union,MutablePoset.differenceetc.leftandright, instead ofselfandother? IMHO, this disguises that the function can be called asP.union(Q).
Changed all to self/other.
- Regarding all set operations: currently, it is not clear from the documentation that all set operations are performed on the set of keys. This causes something like
sage: PR.<x> = ZZ[] sage: P = MutablePoset(key=lambda k: len(k.list())) sage: P.add(42*x) sage: P.add(21*x^2) sage: Q = MutablePoset(key=lambda k: len(k.list())) sage: Q.add(1111*x) sage: P, Q (poset(42*x, 21*x^2), poset(1111*x)) sage: Q.is_subset(P) True sage: Q.union(P) poset(1111*x, 21*x^2)and so on. In principle, I don't see this as a problem---however, I'd state this explicitly in each of these set operation functions.
I've added a note in all these functions.
MutablePoset.mapped: why is this function needed? Purely for semantical reasons? I'd move the doctests toMutablePoset.copy.
It is a shortcut for using copy with the mapping argument (since this is a non-standard argument for a copy method, including a separate method with an approriate name seems to be a good choice)
MutablePosetShell._copy_all_linked_: is the memoization using theidof the object a standard procedure? I thought about it, but I'm not entirely sure that this isn't a potential error source.
Yes it is standard; see (all) deepcopy routines.
Also, I've made a few reviewer commits concerning the documentation; the branch is attached.
Cross-reviewed. Thanks.
dkrenn
commented
8 years ago Changed branch from u/behackl/asy/mutable-poset to u/dkrenn/asy/mutable-poset
dkrenn
commented
8 years ago Last 10 new commits:
39ae466 | correct oo, null |
fd7c881 | Applies --> Apply in one-line of docstring |
dabad1f | remove reverse in is_{null|oo} since not needed |
33c4102 | mark doctests in .le as indirect |
b31fac8 | rewrite a couple of one-line descriptions |
17e921f | remove sorted_set_by_tuple |
7af4b6b | remove reverse keyword from shells |
a49a20d | add comment in code to make it clear what happens |
89b8209 | change left/right to self/other |
1d52f6c | add a note to the set operations methods |
behackl
commented
8 years ago Hello Daniel,
I cross-reviewed your changes and have one last open question:
object instead of SageObject? Because the documentation of SageObject states that "Every object that can end up being returned to the user should inherit from SageObject."Other than that, this is positive_review from my side; AFAIK cheuberg also wanted to cross-review this ticket, so I'll not set this to positive_review yet.
Benjamin
dkrenn
commented
8 years ago Replying to @behackl:
- Is there a particular reason for deriving this from
objectinstead ofSageObject? Because the documentation of SageObject states that "Every object that can end up being returned to the user should inherit from SageObject."
Ok, then SageObject it is :)
behackl
commented
8 years ago A short remark on this change of mind:
When deriving these classes from SageObject instead of object, and merging this ticket into #19083 (the cleanup-ticket of our AsymptoticRing), doctests were failing because we call A(poset) with an AsymptoticRing A there, which causes some peculiarities in _coerce_map_from_.
In any case, we fixed these problems there, so this can be properly derived from SageObject.
This concludes my review; cheuberg is in the process of reading the code. I'll leave setting this to positive_review to him.
Benjamin
Last 10 new commits:
fd7c881 | Applies --> Apply in one-line of docstring |
dabad1f | remove reverse in is_{null|oo} since not needed |
33c4102 | mark doctests in .le as indirect |
b31fac8 | rewrite a couple of one-line descriptions |
17e921f | remove sorted_set_by_tuple |
7af4b6b | remove reverse keyword from shells |
a49a20d | add comment in code to make it clear what happens |
89b8209 | change left/right to self/other |
1d52f6c | add a note to the set operations methods |
3b3b2fb | object --> SageObject |
behackl
commented
8 years ago Changed branch from u/dkrenn/asy/mutable-poset to u/behackl/asy/mutable-poset
cheuberg
commented
8 years ago Changed branch from u/behackl/asy/mutable-poset to u/cheuberg/asy/mutable-poset
cheuberg
commented
8 years ago Changed reviewer from Benjamin Hackl to Benjamin Hackl, Clemens Heuberger
cheuberg
commented
8 years ago Replying to @behackl:
This concludes my review; cheuberg is in the process of reading the code. I'll leave setting this to
positive_reviewto him.
I read the documentation and the code. I pushed a few reviewer commits. I have a number of rather minor issues with the documentation which I ask you to fix in order facilitate future maintainance of the code. In three instances, I propose alternative implementations, which might be more readable or slightly more efficient.
.. seealso:: blocks between corresponding methods of shell and poset as well as between the accessor methods (keys, elements, shells)MutablePoset.__init__ accepts a list of elements. This could be used in several doctests (in particular, in the set operations) as an abbreviation.MutablePosetShell.__init__: shall we check that element is not None? Otherwise, handling of special elements would probably be affected.MutablePosetShell.key: I do not understand the sentence "The element is converted by the poset to the key".MutablePosetShell.key: I am surprised that the key is not cached. I imagine that many comparisons will be needed in the lifetime of a MutablePoset, and in every case, the property key has to be resolved, which calls the property poset, which calls get_key of the poset.MutablePosetShell.__repr__: The note box in the docstring is surprising at this point: reading the source file from the top, this is the first point where the representation of the data is explained, after guessing it from is_special, is_oo, is_null above. I think that it would be better to document these conventions closer to the top, perhaps in the __init__ method or perhaps only as a comment in the source code.MutablePosetShell.__repr__: The code replicates the behaviour of is_null and is_oo. As the __repr__ method is hardly time critical, I'd prefer using is_null and is_oo, here and thus hiding the internal convention.MutablePosetShell.le: the note box could be simplified by suppressing implementation details and speaking about the special elements.MutablePosetShell.le: right <= left: neither right nor left are defined here.MutablePosetShell.le: the part if other.element is None could be simplified to return not other.successors() as self is already known not to be special here.MutablePosetShell.le: If this is time critical, self._predecessors_ could be used instead of self.predecessors().MutablePosetShell.eq: note box, see above.MutablePosetShell.eq: emphasize that elements with equal keys are considered equal? Currently, this information is somewhat hidden in the note box which at first glance only seems to explain handling of special elements.MutablePosetShell._copy_all_linked_: Short description: "Return a copy of all shells" does not correspond to the actual return value, which is only the copy of this shell.MutablePosetShell._copy_all_linked_: the interplay between this method and MutablePoset._copy_shells_ is not well documented: in particular, poset in _copy_all_linked_ is only used for setting the containing poset, but not for actual inserting into this poset.MutablePosetShell._copy_all_linked_: I do not understand why you test oo == P.oo: I think that oo is an element of the new poset Q. So oo is Q.oo would be more interesting? The current test demonstrates that the poset is not used in comparison, so that would rather belong to .eq?MutablePosetShell._search_covers_: what is the role of self in this method? It trivially influences the return value, but what else?MutablePosetShell._search_covers_: The explanation of the return value is unclear to me. Is the sentence "Note that..." meant to be a complete description? Does it change if reverse is set?MutablePosetShell._search_covers_: I think that the notions of "upper cover" and "lower cover" need a brief definition; I did not find them in Wikipedia and sage.combinat.posets.posets.FinitePoset.upper_covers defines the notion.MutablePosetShell._search_covers_: According to Wikipedia, a cover is what is called an upper cover here. This is in contrast to the default behaviour here.MutablePosetShell._search_covers_: what is the difference between this method and .predecessors? Is the shell necessarily an element of the poset? If not, then there should be a doctest covering this case.MutablePosetShell.covers: "originate" is somewhat foreign to the description of the poset.MutablePosetShell.covers: "which are at most the given shell": should that be "which are less than the given shell"?MutablePosetShell.covers see comments on MutablePosetShell._search_covers_.MutablePosetShell.covers: I think that the following would be an equivalent implementation of this method, which does not need a helper function with side effects. if self == shell:
return set()
covers = set().union(*(e.covers(shell, reverse)
for e in self.successors(reverse)
if e.le(shell, reverse)))
if covers:
return covers
else:
return set([self])(pushed as branch u/cheuberg/asy/mutable-poset-cover)
MutablePosetShell._iter_depth_first_visit_: document the role of self in this method (only shells >= this shell are visited).MutablePosetShell.iter_depth_first: document the role of self in this method (only shells >= this shell are visited).MutablePosetShell._iter_topological_visit_: document the role of self in this method (only shells <= this shell are visited, emphasize the contrast to depth first.).MutablePosetShell.iter_topological_first: document the role of self in this method (only shells <= this shell are visited, emphasize the contrast to depth first.).MutablePosetShell.iter_topological_sort, last example: function C is defined, but not used.MutablePosetShell.merge: explain what merge is, in particular, that this is defined when constructing the poset.MutablePosetShell.merge: I am surprised that check=True leads to a silent failure instead of an exception and that poset._merge_ is None does not raise an exception. Document and test this behaviour?MutablePosetShell.merge: what is the difference between poset.remove and poset.discard?MutablePosetShell.merge: document that the merge function resulting in None leads to deletion of the element.MutablePosetShell.merge: document that the merge function must not change the position of the element in the poset.MutablePoset.__init__: Clarify the role of key: in particular, key does not only influence sorting, but that no two elements are allowed to have the same key.MutablePoset.__len__: Clarify that null and oo are not counted.MutablePoset.shells_topological: The sentence "If this is None, no sorting according to the representation string occurs." is unclear to me, in particular the role of the representation string.MutablePoset.keys_topological: Due to the chosen key, some of the elements added to the poset are ignored. I do not know why this is demonstrated here.MutablePoset.repr: INPUT section is incomplete.MutablePoset.repr_full: INPUT section is incomplete.MutablePoset.add: the loop for reverse in (False, True) simplifies in the second iteration: as all pairs of elements (s, l) with new covering s and l covering new have already been broken up while reverse=False. Thus it might be more straightforward to do it only once, not using reverse at all and saving a few intersections: new._predecessors_ = self.null.covers(new, reverse=False)
new._successors_ = self.oo.covers(new, reverse=True)
for s in new.predecessors():
for l in s.successors().intersection(new.successors()):
l.predecessors().remove(s)
s.successors().remove(l)
s.successors().add(new)
for l in new.successors():
l.predecessors().add(new)(pushed as branch u/cheuberg/asy/mutable-poset-add)
MutablePoset.remove: the loop over all (not necessarily direct) successors via the depth first search iterator seems to be rather inefficient, especially if the poset is large. I propose an alternative based on the order relation and not based on the data structure: for upper in shell.successors():
upper.predecessors().remove(shell)
for lower in shell.predecessors():
lower.successors().remove(shell)
for upper in shell.successors():
if not any(s <= upper
for s in lower.successors()):
lower.successors().add(upper)
upper.predecessors().add(lower)(pushed as branch u/cheuberg/asy/mutable-poset-remove)
MutablePoset.remove, MutablePoset.discard: add "see also blocks", but also an explanation of the difference between discard and remove. I guess that both methods are available due to some compatibility concern (in that case, please add a remark in the code or the docstring). Otherwise, I'd suggest removing discard, removing the parameter raise_key_error and let the user catch the exception.MutablePoset.pop: remove key=lambda c: -c from this example as it is not pertinent to pop.MutablePoset.pop: mention that special elements cannot be popped.MutablePoset.pop: IMHO you can remove the first four line (the try: block deleting kwargs['include_special']) because setting kwargs['include_special'] = False should result in the same result.MutablePoset.union: The doctest P.union(P, Q, Q, P) neither fits the description "a poset" or "an iterable of future elements".MutablePoset.union: the word "union" sounds symmetric, however, due to keys and merge functions, it might not be commutative. The note box is not helpful for me.MutablePoset.union: the TODO box from union_update also applies here.MutablePoset.union_update: why is the semantics of other different w.r.t union, but has the same description? It would seem more logical to me if union would simply call copy and then pass its argument to update_union and let the latter function sort out the iterators?MutablePoset.difference and MutablePoset.difference_update: see comments on union and union_updateMutablePoset.intersection and MutablePoset.intersection_update: see comments on union and union_updateMutablePoset.intersection_update: how can the AttributeError occur? After all, self is a MutablePoset, so the method keys will be available unless something very strange happens ...MutablePoset.merge: documentation of reverse: what is the default direction?MutablePoset.merge: add doctest for RuntimeError.MutablePoset.merge: document that can_merge is applied in the sense of the condition of depth first iteration, i.e., once can_merge fails, the successors are no longer tested. This is some kind of monotonicity condition on can_merge.MutablePoset.merge: it should be mentioned somewhere that this (at first sight strange) merge magic is motivated by asymptotic expansions.MutablePoset.map: IMHO the example does alter the keys, because the key was the identity map here.MutablePoset.mapping: does the map have to be key preserving as in the method map? Is this method actually needed, see also the recent discussion on inplace vs. non-inplace operations on sage-devel?New commits:
8de4188 | Trac #17693: minor language adjustments |
740852e | Trac #17693: command instead of description for short descriptions |
347656c | Trac #17693: language adjustment: whether instead of if |
4774baa | Trac #17693: corrections in documentation |
fe5d2f1 | Trac #17693: additional doctest |
e4f1fea | Trac #17693: fix indentations and whitespace |
254951d | Trac #17693: add keyword in doctest for clarity |
f7bce7e | Trac #17693: remove superfluous doctest |
dkrenn
commented
8 years ago Changed branch from u/cheuberg/asy/mutable-poset to u/dkrenn/asy/mutable-poset
The aim of this ticket is to implement a data structure which is to be used within an asymptotic expression (see Meta-Ticket #17601). This mutable poset stores elements together with its successors and predecessors. Those data is updated when a new element is inserted or an element is removed. It offers a couple of efficient routines for manipulations (all of which will be needed for the asymptotic expression).
CC: @behackl @cheuberg @jm58660
Component: asymptotic expansions
Author: Daniel Krenn
Branch/Commit:
a0b3d7bReviewer: Benjamin Hackl, Clemens Heuberger
Issue created by migration from https://trac.sagemath.org/ticket/17693