Sage: Ticket #13566: Simplicial complex examples as singletons
https://trac.sagemath.org/ticket/13566
<p>
Since each of the examples are unique, there should only be one (immutable) instance of each. In other words, we do not recreate the example each time it is called. For example
</p>
<pre class="wiki">sage: S1 = simplicial_complexes.KleinBottle()
sage: S2 = simplicial_complexes.KleinBottle()
sage: S1 == S2
True
sage: S1 is S2
False
</pre><p>
where the last should return <code>true</code>. Possibly do this by something like
</p>
<pre class="wiki">def KlienBottle(self):
if not hasattr(self, "_klien_bottle_output"):
self._klien_bottle_output = SimplicialComplex(facets)
return self._klien_bottle_output
</pre><p>
This is an expansion on the concept in <a class="closed ticket" href="https://trac.sagemath.org/ticket/13244" title="enhancement: make some simplicial complexes faster (closed: fixed)">#13244</a> and the dependency on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a> is in making simplicial complexes immutable.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/13566
Trac 1.1.6tscrimThu, 04 Oct 2012 16:41:14 GMTdescription changed
https://trac.sagemath.org/ticket/13566#comment:1
https://trac.sagemath.org/ticket/13566#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/13566?action=diff&version=1">diff</a>)
</li>
</ul>
TicketjhpalmieriThu, 04 Oct 2012 16:52:50 GMTcc set
https://trac.sagemath.org/ticket/13566#comment:2
https://trac.sagemath.org/ticket/13566#comment:2
<ul>
<li><strong>cc</strong>
<em>jhpalmieri</em> added
</li>
</ul>
TicketcnassauSat, 08 Dec 2012 13:18:23 GMT
https://trac.sagemath.org/ticket/13566#comment:3
https://trac.sagemath.org/ticket/13566#comment:3
<p>
A simpler solution would be to turn the constructors in the <code>SimplicialComplexExamples</code> class into <code>@cached_methods</code>. I'm attaching this as a patch.
</p>
TicketcnassauSat, 08 Dec 2012 13:21:05 GMTattachment set
https://trac.sagemath.org/ticket/13566
https://trac.sagemath.org/ticket/13566
<ul>
<li><strong>attachment</strong>
set to <em>13566cna.patch</em>
</li>
</ul>
<p>
make examples unique using <code>@cached_method</code>
</p>
TicketcnassauSat, 08 Dec 2012 14:12:42 GMTstatus changed
https://trac.sagemath.org/ticket/13566#comment:4
https://trac.sagemath.org/ticket/13566#comment:4
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TickettscrimMon, 10 Dec 2012 23:17:28 GMTstatus changed
https://trac.sagemath.org/ticket/13566#comment:5
https://trac.sagemath.org/ticket/13566#comment:5
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Please add doctests such as
</p>
<pre class="wiki">sage: T1 = simplicial_complexes.Torus()
sage: T2 = simplicial_complexes.Torus()
sage: T1 is T2
True
</pre><p>
and make sure this is based on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a> (the ticket cannot apply with any fuzz). I'd also like to see you put your name in the <code>AUTHORS:</code> block and a general statement of the changes. Also you will need to fill in your real name on the ticket and have a proper commit message in the patch.
</p>
<p>
Thank you,<br />
Travis
</p>
TicketcnassauTue, 11 Dec 2012 07:47:58 GMT
https://trac.sagemath.org/ticket/13566#comment:6
https://trac.sagemath.org/ticket/13566#comment:6
<p>
Hmm, I've tried for about an hour to apply the patches from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a> on my (essentially clean) 3.5.1, but without success. I think I'll just "withdraw" this patch for now and come back to it after the next release...
</p>
TicketjhpalmieriTue, 11 Dec 2012 21:33:22 GMT
https://trac.sagemath.org/ticket/13566#comment:7
https://trac.sagemath.org/ticket/13566#comment:7
<p>
Sorry about that. I think I've recorded the correct dependencies on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a> now.
</p>
TicketcnassauFri, 14 Dec 2012 18:44:31 GMT
https://trac.sagemath.org/ticket/13566#comment:8
https://trac.sagemath.org/ticket/13566#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:7" title="Comment 7">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Sorry about that. I think I've recorded the correct dependencies on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a> now.
</p>
</blockquote>
<p>
Thanks, that might help. On the other hand, I don't think this issue is urgent so I've pushed it to the back of my queue for now. If someone else wants to implement a fix I wouldn't mind at all ;-)
</p>
TicketjhpalmieriTue, 18 Dec 2012 19:27:48 GMTstatus changed
https://trac.sagemath.org/ticket/13566#comment:9
https://trac.sagemath.org/ticket/13566#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Here is a rebased version of Christian's patch. I added a bunch of tests, also.
</p>
TicketjhpalmieriTue, 18 Dec 2012 19:29:13 GMTattachment set
https://trac.sagemath.org/ticket/13566
https://trac.sagemath.org/ticket/13566
<ul>
<li><strong>attachment</strong>
set to <em>trac_13566cna.patch</em>
</li>
</ul>
TicketjhpalmieriTue, 18 Dec 2012 19:29:37 GMTdescription changed
https://trac.sagemath.org/ticket/13566#comment:10
https://trac.sagemath.org/ticket/13566#comment:10
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/13566?action=diff&version=10">diff</a>)
</li>
</ul>
TicketjhpalmieriTue, 18 Dec 2012 19:30:55 GMT
https://trac.sagemath.org/ticket/13566#comment:11
https://trac.sagemath.org/ticket/13566#comment:11
<p>
By the way, this applies independently of the patches at <a class="closed ticket" href="https://trac.sagemath.org/ticket/13725" title="enhancement: sum complexes: another example of simplicial complexes (closed: fixed)">#13725</a> for sum complexes. Those can't be cached like this because they can accept a list (which is unhashable) as an argument.
</p>
TickettscrimWed, 19 Dec 2012 04:09:32 GMTstatus changed; reviewer, author set
https://trac.sagemath.org/ticket/13566#comment:12
https://trac.sagemath.org/ticket/13566#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Travis Scrimshaw</em>
</li>
<li><strong>author</strong>
set to <em>Christian Nassau, John Palmieri</em>
</li>
</ul>
<p>
From what I've heard, custom caches are something we should avoid. So since we can't make sum complexes work with <code>@cached_method</code>, and everything looks good to me, I'm setting this to positive review. Thanks.
</p>
TicketcnassauWed, 19 Dec 2012 06:50:39 GMT
https://trac.sagemath.org/ticket/13566#comment:13
https://trac.sagemath.org/ticket/13566#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:12" title="Comment 12">tscrim</a>:
</p>
<blockquote class="citation">
<p>
From what I've heard, custom caches are something we should avoid. So since we can't make sum complexes work with <code>@cached_method</code>, and everything looks good to me, I'm setting this to positive review. Thanks.
</p>
</blockquote>
<p>
The author credits are very generous, many thanks. From my part this was a somewhat reckless case of drive-by patching of which I am rather ashamed now. I hope to do a better job next time... ;-)
</p>
<p>
Cheers, <br />
Christian
</p>
TicketjdemeyerWed, 19 Dec 2012 07:50:14 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:14
https://trac.sagemath.org/ticket/13566#comment:14
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.5</em> to <em>sage-5.6</em>
</li>
</ul>
TicketjdemeyerThu, 27 Dec 2012 22:50:41 GMT
https://trac.sagemath.org/ticket/13566#comment:15
https://trac.sagemath.org/ticket/13566#comment:15
<p>
On sage.math, this patch causes
</p>
<pre class="wiki">sage -t -force_lib devel/sage/sage/categories/algebra_modules.py
/release/merger/sage-5.6.beta2/local/lib/libcsage.so(print_backtrace+0x2b)[0x2b1002e4866e]
/release/merger/sage-5.6.beta2/local/lib/libcsage.so(sigdie+0x14)[0x2b1002e4869b]
/release/merger/sage-5.6.beta2/local/lib/libcsage.so(sage_signal_handler+0x20b)[0x2b1002e48189]
/lib/libpthread.so.0[0x2b1000eb27d0]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_GC_Del+0x22)[0x2b1000be54c2]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b62e01]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b31703]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b31978]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b31978]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000bd949b]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b44643]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyDict_SetItem+0x73)[0x2b1000b45583]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyDict_SetItemString+0x4b)[0x2b1000b4676b]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x47fd)[0x2b1000bab07d]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b329b9]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_Call+0x68)[0x2b1000b05308]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b158bf]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_Call+0x68)[0x2b1000b05308]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x1299)[0x2b1000ba7b19]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5ae4)[0x2b1000bac364]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b329b9]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_Call+0x68)[0x2b1000b05308]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0[0x2b1000b158bf]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_Call+0x68)[0x2b1000b05308]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x1299)[0x2b1000ba7b19]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5ae4)[0x2b1000bac364]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5ae4)[0x2b1000bac364]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5ae4)[0x2b1000bac364]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x852)[0x2b1000bae352]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x2b1000bae472]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0xc1)[0x2b1000bd21f1]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0x1f9)[0x2b1000bd24c9]
/release/merger/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(Py_Main+0xb15)[0x2b1000be5115]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2b10017671f4]
python[0x400679]
------------------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component of Sage has a bug
in it and is not properly wrapped with sig_on(), sig_off(). You might
want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate.
------------------------------------------------------------------------
Segmentation fault
</pre>
TicketjdemeyerThu, 27 Dec 2012 23:07:12 GMT
https://trac.sagemath.org/ticket/13566#comment:16
https://trac.sagemath.org/ticket/13566#comment:16
<p>
Note that this segfault is actually "caused" by <a class="closed ticket" href="https://trac.sagemath.org/ticket/715" title="defect: Parents probably not reclaimed due to too much caching (closed: fixed)">#715</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/11521" title="defect: Use weak references to cache homsets (closed: fixed)">#11521</a>.
</p>
TicketnbruinSun, 30 Dec 2012 01:33:05 GMTstatus changed
https://trac.sagemath.org/ticket/13566#comment:17
https://trac.sagemath.org/ticket/13566#comment:17
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Why is this caching desirable? As far as I can see, this creates a memory leak:
</p>
<pre class="wiki">i=1
while true:
simplicial_complexes.Sphere(i)
i=i+1
</pre><p>
fails much sooner than it should because all the now useless previous examples are still nailed in memory.
</p>
<p>
You aren't proposing the cache to save computation time, I suppose? It's probably because you find it desirable to guarantee uniqueness when these things exist (are they parents?) In that case, you can get what you want by inheriting from UniqueRepresentation or UniqueFactory. That keeps a weak cache, so that
examples that aren't otherwise referenced anymore can be collected.
</p>
TicketcnassauSun, 30 Dec 2012 09:53:48 GMT
https://trac.sagemath.org/ticket/13566#comment:18
https://trac.sagemath.org/ticket/13566#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:17" title="Comment 17">nbruin</a>:
</p>
<blockquote class="citation">
<p>
You aren't proposing the cache to save computation time, I suppose? It's probably because you find it desirable to guarantee uniqueness when these things exist (are they parents?) In that case, you can get what you want by inheriting from UniqueRepresentation or UniqueFactory. That keeps a weak cache, so that
examples that aren't otherwise referenced anymore can be collected.
</p>
</blockquote>
<p>
I wonder if we could create a new modifier <code>@weakly_chached_method</code> (or maybe <code>@cached_method(weakref=True)</code>) for this purpose. Using a UniqueRepresentation or UniqueFactory probably requires some code re-arrangements (for example, <code>Sphere</code> is a currently a method, not a class whose inheritance we could change).
</p>
TicketnbruinTue, 01 Jan 2013 02:23:46 GMT
https://trac.sagemath.org/ticket/13566#comment:19
https://trac.sagemath.org/ticket/13566#comment:19
<p>
Well ... you could write a decorator that turns a function into a <a class="missing wiki">UniqueFactory?</a>. However, I think you have a more serious problem: The routines you are now defining have no business being a method (note that you don't use the <code>self</code> argument!). Python is not Java. You don't have to stuff everything into a class. Much more appropriate is a module (just a file with functions). In fact, since your functions are just interfaces to <a class="missing wiki">SimplicialComplex?</a>, any uniqueness of the output value is already ensured by that thing. And if it isn't, then either <a class="missing wiki">SimplicialComplex?</a> should be ensuring uniqueness or there's a good reason why it shouldn't and then your routines shouldn't ensure uniqueness either. In other words: the caching you're proposing should either happen on a deeper level or not at all.
</p>
<p>
For more information about using modules to gather examples or as convenient namespace groupings, see <a class="closed ticket" href="https://trac.sagemath.org/ticket/13115" title="enhancement: "groups" object for organizing examples of groups (closed: fixed)">#13115</a> and this <a class="ext-link" href="https://groups.google.com/group/sage-devel/browse_thread/thread/76f32baf025a370/4aa1b2f40eadd48c?hl=en&lnk=gst&q=examples+in+module#4aa1b2f40eadd48c"><span class="icon"></span>sage-devel thread</a>.
</p>
TickettscrimTue, 01 Jan 2013 05:33:04 GMT
https://trac.sagemath.org/ticket/13566#comment:20
https://trac.sagemath.org/ticket/13566#comment:20
<p>
If I understand <a class="closed ticket" href="https://trac.sagemath.org/ticket/13115" title="enhancement: "groups" object for organizing examples of groups (closed: fixed)">#13115</a>/the thread correctly, a way to do this would be:
</p>
<ul><li>have an <code>import homology/examples as simplical_complexes</code> in the <code>all.py</code>
</li><li>Make each of these methods into a subclass of <code>SimplicialComplex</code> and <code>UniqueRepresentation</code> and have these be at the module level
</li></ul><p>
since right now <code>SimplicialComplex</code> is mutable until specified otherwise. (I guess with this we can also do some optimization with certain methods, such as homology for <code>Sphere</code>... and that should be a different ticket.)
</p>
TicketnbruinTue, 01 Jan 2013 18:24:50 GMT
https://trac.sagemath.org/ticket/13566#comment:21
https://trac.sagemath.org/ticket/13566#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:20" title="Comment 20">tscrim</a>:
</p>
<blockquote class="citation">
<p>
If I understand <a class="closed ticket" href="https://trac.sagemath.org/ticket/13115" title="enhancement: "groups" object for organizing examples of groups (closed: fixed)">#13115</a>/the thread correctly, a way to do this would be:
</p>
<ul><li>have an <code>import homology/examples as simplical_complexes</code> in the <code>all.py</code>
</li><li>Make each of these methods into a subclass of <code>SimplicialComplex</code> and <code>UniqueRepresentation</code> and have these be at the module level
</li></ul><p>
since right now <code>SimplicialComplex</code> is mutable until specified otherwise. (I guess with this we can also do some optimization with certain methods, such as homology for <code>Sphere</code>... and that should be a different ticket.)
</p>
</blockquote>
<p>
Yes, that sounds looks like a sensible approach. Additionally, if that seems like a heavy-weight solution (it does to me), one should probably see if uniqueness is so important that it warrants a subclass and/or if there are other pressing reasons to make these subclasses. Reasons against uniqueness:
</p>
<ul><li><code>SimplicialComplex</code> is not a parent so there's no sage-technical reason to enforce uniqueness (that's just a reason <em>not for</em> uniqueness)
</li></ul><ul><li>While any two <code>Sphere(3)</code> complexes are isomorphic, they are not canonically so, so mathematically there can be good reasons to have multiple non-identical spheres in memory.
</li></ul><ul><li>It makes things like <code>Sphere</code> behave different from <code>SimplicialComplex</code> (and more generally not simply <em>be</em> a <code>SimplicialComplex</code>. That makes code harder to maintain because now you have similar-but-subtly-different acting objects. You should only do that if there's a benefit elsewhere.
</li></ul><p>
Should uniqueness of <code>SimplicialComplexes</code> be desirable in general (why? are they meant to become parents?) then it should perhaps be fixed on that level. Mutable obviously can't be forced to be unique, so then you should probably make two: <code>SimplicialComplex</code> and <code>MutableSimplicialComplex</code> (one a subclass of the other if at all possible), where you can make the immutable one unique by also inheriting from <a class="missing wiki">UniqueRepresentation?</a>. Going to the immutable one then of course should return an immutable <em>copy</em>, not just change a flag.
</p>
<p>
Alternatively, (I don't know if that would be too hackish) you could add another flag, <code>canonical_instance=true/false</code> (only to be used with <code>is_mutable=False</code>), or make (a renamed version of) <code>is_mutable</code> tristate, to determines whether a cache is involved. That would have the severe drawback you'd have to break open the caching mechanism used in <code>UniqueRepresentation</code>.
</p>
<p>
If you find there's no need for <code>Sphere</code> etc. to be anything more than just a <code>SimplicialComplex</code> the implementation becomes <em>really</em> easy: <code>sage.homology.examples.Sphere</code> can simple be a function, returning the relevant <code>SimplicialComplex</code>.
</p>
TickettscrimWed, 02 Jan 2013 15:30:11 GMT
https://trac.sagemath.org/ticket/13566#comment:22
https://trac.sagemath.org/ticket/13566#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:21" title="Comment 21">nbruin</a>:
</p>
<blockquote class="citation">
<p>
Reasons against uniqueness:
</p>
<ul><li><code>SimplicialComplex</code> is not a parent so there's no sage-technical reason to enforce uniqueness (that's just a reason <em>not for</em> uniqueness)
</li></ul><ul><li>While any two <code>Sphere(3)</code> complexes are isomorphic, they are not canonically so, so mathematically there can be good reasons to have multiple non-identical spheres in memory.
</li></ul></blockquote>
<p>
That is a good point since I believe not all triangulations of a (high enough dimensional) sphere can be obtained by bistellar flips.
</p>
<blockquote class="citation">
<ul><li>It makes things like <code>Sphere</code> behave different from <code>SimplicialComplex</code> (and more generally not simply <em>be</em> a <code>SimplicialComplex</code>. That makes code harder to maintain because now you have similar-but-subtly-different acting objects. You should only do that if there's a benefit elsewhere.
</li></ul></blockquote>
<p>
Also a good point.
</p>
<blockquote class="citation">
<p>
Should uniqueness of <code>SimplicialComplexes</code> be desirable in general (why? are they meant to become parents?) then it should perhaps be fixed on that level. Mutable obviously can't be forced to be unique, so then you should probably make two: <code>SimplicialComplex</code> and <code>MutableSimplicialComplex</code> (one a subclass of the other if at all possible), where you can make the immutable one unique by also inheriting from <a class="missing wiki">UniqueRepresentation?</a>. Going to the immutable one then of course should return an immutable <em>copy</em>, not just change a flag.
</p>
</blockquote>
<p>
What I was thinking when I created this ticket was that since these are particular examples of simplicial complexes, they should be unique and immutable. However, perhaps it would be better to have them be mutable copies for computations rather than having the user create a copy (I don't really know offhand if these are used computationally in Sage)...I will leave this decision to someone who uses these more than me.
</p>
<blockquote class="citation">
<p>
If you find there's no need for <code>Sphere</code> etc. to be anything more than just a <code>SimplicialComplex</code> the implementation becomes <em>really</em> easy: <code>sage.homology.examples.Sphere</code> can simple be a function, returning the relevant <code>SimplicialComplex</code>.
</p>
</blockquote>
<p>
If it is decided to essentially do nothing, perhaps we should use this ticket to move everything down to a function.
</p>
<p>
Also it seems like this needs to be rebased to 5.6.beta1.
</p>
<p>
Thanks,<br />
Travis
</p>
<p>
PS - I may not be able to respond for 2 weeks
</p>
TicketSimonKingThu, 03 Jan 2013 16:23:41 GMT
https://trac.sagemath.org/ticket/13566#comment:23
https://trac.sagemath.org/ticket/13566#comment:23
<p>
Sorry, I did not read the whole discussion, but I see in the patch that cached_method is used. Hence, the constructed simplicial complexes will be kept in memory indefinitely. Wouldn't it be a better idea to turn simplicial_complexes into a <code>UniqueFactory</code>?
</p>
<p>
Of course, in a <code>UniqueFactory</code> one would usually ask for a Klein bottle by <code>simplicial_complexes("KleinBottle")</code>. But of course one could still define methods <code>KleinBottle</code> and so on, so that <code>simplicial_complexes.KleinBottle()</code> is equivalent to <code>simplicial_complexes("KleinBottle")</code>.
</p>
<p>
The latter could be automatised by a <code>__getattr__</code> method:
</p>
<pre class="wiki"> def __getattr__(self, s):
return lambda : self(s)
</pre><p>
Why would that solve the problem with permanent caching? Well, <code>UniqueFactory</code> will soon be using weak dictionaries for caching (in fact it already uses weak references, but improperly, and that's supposed to be fixed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/12215" title="defect: Memleak in UniqueRepresentation, @cached_method (closed: fixed)">#12215</a>).
</p>
TickettscrimMon, 11 Feb 2013 00:50:04 GMT
https://trac.sagemath.org/ticket/13566#comment:24
https://trac.sagemath.org/ticket/13566#comment:24
<p>
Sorry for falling behind on this ticket. What we should do strongly depends on the answer the question "Should these examples be immutable to begin with (right now one would need to make a mutable copy to manipulate it)?" My belief is still yes and so I'd support going to a <code>UniqueFactory</code>, however this is at odds with what the graph code does:
</p>
<pre class="wiki">sage: g = graphs.StarGraph(5)
sage: g
Star graph: Graph on 6 vertices
sage: g.add_vertex(10)
sage: g
Star graph: Graph on 7 vertices
</pre><p>
Since the graph is given a special name, I'd rather that be immutable. (If we do keep them immutable, we probably should give each of our simplicial complex examples special names too...)
</p>
<p>
Anyways, what are everyone else's thoughts?
</p>
<p>
Thanks,<br />
Travis
</p>
TicketjhpalmieriMon, 11 Feb 2013 22:50:50 GMT
https://trac.sagemath.org/ticket/13566#comment:25
https://trac.sagemath.org/ticket/13566#comment:25
<p>
How do you make an immutable simplicial complex mutable? We seem to have missed adding a <code>set_mutable</code> method in <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a>, and so now I don't know how to get a mutable copy of the various examples, short of explicitly setting the <code>_is_mutable</code> attribute.
</p>
<p>
I think this should be fixed very soon, maybe before the other issues in this ticket.
</p>
<p>
As far as whether the examples should be immutable, I don't feel strongly either way. I can see a certain elegance in immutability, but other examples in Sage don't seem to work like this. I suppose we could use <code>UniqueFactory</code> to create an immutable unique instance, but the functions (or methods, or whatever) could return a mutable copy each time. For example:
</p>
<pre class="wiki">sage: MatrixSpace(QQ, 3, 3).identity_matrix().is_mutable()
False
sage: matrix.identity(QQ, 3).is_mutable()
True
</pre><p>
This seems rather odd to me, but I suppose it's an option.
</p>
TickettscrimTue, 12 Feb 2013 01:06:45 GMT
https://trac.sagemath.org/ticket/13566#comment:26
https://trac.sagemath.org/ticket/13566#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:25" title="Comment 25">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
How do you make an immutable simplicial complex mutable? We seem to have missed adding a <code>set_mutable</code> method in <a class="closed ticket" href="https://trac.sagemath.org/ticket/12587" title="defect: simplicial complexes lack hash function (closed: fixed)">#12587</a>, and so now I don't know how to get a mutable copy of the various examples, short of explicitly setting the <code>_is_mutable</code> attribute.
</p>
</blockquote>
<p>
For example
</p>
<pre class="wiki">sage: S = simplicial_complexes.Sphere(4)
sage: S.is_mutable()
False
sage: T = SimplicialComplex(S, is_mutable=True) # This should work and is a bug I didn't catch
sage: T.is_mutable()
False
sage: T = SimplicialComplex(S) # This one I'm happy with leaving immutable
sage: T.is_mutable()
False
</pre><p>
However I do think we should also have a method to make a mutable copy, my suggestions are either <code>copy()</code> and/or <code>make_mutable()</code>.
</p>
<blockquote class="citation">
<p>
I think this should be fixed very soon, maybe before the other issues in this ticket.
</p>
</blockquote>
<p>
Agreed. This was something I introduced, so I'll be happy to fix it.
</p>
<blockquote class="citation">
<p>
As far as whether the examples should be immutable, I don't feel strongly either way. I can see a certain elegance in immutability, but other examples in Sage don't seem to work like this. I suppose we could use <code>UniqueFactory</code> to create an immutable unique instance, but the functions (or methods, or whatever) could return a mutable copy each time. For example:
</p>
<pre class="wiki">sage: MatrixSpace(QQ, 3, 3).identity_matrix().is_mutable()
False
sage: matrix.identity(QQ, 3).is_mutable()
True
</pre><p>
This seems rather odd to me, but I suppose it's an option.
</p>
</blockquote>
<p>
This is very strange to me as well. Part of the thing is the identity matrix function is cached, so it must return an immutable object.
</p>
<p>
Best,<br />
Travis
</p>
TicketjhpalmieriTue, 12 Feb 2013 04:04:19 GMT
https://trac.sagemath.org/ticket/13566#comment:27
https://trac.sagemath.org/ticket/13566#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:26" title="Comment 26">tscrim</a>:
</p>
<blockquote class="citation">
<p>
However I do think we should also have a method to make a mutable copy, my suggestions are either <code>copy()</code> and/or <code>make_mutable()</code>.
</p>
</blockquote>
<p>
Another option is to use <code>__copy__()</code>; then calling <code>copy(X)</code> would return a mutable copy of <code>X</code>. We could make <code>copy()</code> an alias for <code>__copy__()</code>, so it's visible via tab completion.
</p>
TickettscrimSat, 16 Feb 2013 16:58:54 GMTdependencies changed
https://trac.sagemath.org/ticket/13566#comment:28
https://trac.sagemath.org/ticket/13566#comment:28
<ul>
<li><strong>dependencies</strong>
changed from <em>#13244, #12587</em> to <em>#13244, #12587, #14142</em>
</li>
</ul>
<p>
I've started <a class="closed ticket" href="https://trac.sagemath.org/ticket/14142" title="defect: Making mutable copies of simplicial complexes (closed: fixed)">#14142</a> which will allow mutable copies.
</p>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:29
https://trac.sagemath.org/ticket/13566#comment:29
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:30
https://trac.sagemath.org/ticket/13566#comment:30
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:31
https://trac.sagemath.org/ticket/13566#comment:31
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:32
https://trac.sagemath.org/ticket/13566#comment:32
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketjhpalmieriThu, 22 Oct 2015 22:35:51 GMTbranch set
https://trac.sagemath.org/ticket/13566#comment:33
https://trac.sagemath.org/ticket/13566#comment:33
<ul>
<li><strong>branch</strong>
set to <em>u/jhpalmieri/simplicial-examples</em>
</li>
</ul>
TicketjhpalmieriThu, 22 Oct 2015 22:53:23 GMTstatus, description, author changed; commit set
https://trac.sagemath.org/ticket/13566#comment:34
https://trac.sagemath.org/ticket/13566#comment:34
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
set to <em>5bf74b6d7f517c534b668dc602b6c7138729156b</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/13566?action=diff&version=34">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Christian Nassau, John Palmieri</em> to <em>John Palmieri</em>
</li>
</ul>
<p>
Here is a branch which makes two more examples of simplicial complexes immutable, and then converts all of the examples from methods to functions. They are not cached (and I think that was the consensus).
</p>
<p>
As Travis said above:
</p>
<blockquote class="citation">
<p>
If it is decided to essentially do nothing, perhaps we should use this ticket to move everything down to a function.
</p>
</blockquote>
<p>
I guess that's what I've done.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=fa33dbea0887418a59a51fa6330aa79fb6967e23"><span class="icon"></span>fa33dbe</a></td><td><code>trac 13566: make two more examples of simplicial complexes immutable</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=5bf74b6d7f517c534b668dc602b6c7138729156b"><span class="icon"></span>5bf74b6</a></td><td><code>trac 13566: remove the class in sage/homology/examples.py:</code>
</td></tr></table>
TicketgitThu, 22 Oct 2015 22:53:58 GMTcommit changed
https://trac.sagemath.org/ticket/13566#comment:35
https://trac.sagemath.org/ticket/13566#comment:35
<ul>
<li><strong>commit</strong>
changed from <em>5bf74b6d7f517c534b668dc602b6c7138729156b</em> to <em>1578bdbb15434ff33707b90efb723373260b0056</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=1578bdbb15434ff33707b90efb723373260b0056"><span class="icon"></span>1578bdb</a></td><td><code>trac 13566: add a file simplicial_complexes_catalog.py</code>
</td></tr></table>
TickettscrimThu, 22 Oct 2015 23:30:23 GMTmilestone changed
https://trac.sagemath.org/ticket/13566#comment:36
https://trac.sagemath.org/ticket/13566#comment:36
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-6.10</em>
</li>
</ul>
<p>
What about having a class which inherits from <code>SimplicialComplex</code> and <code>UniqueRepresentation</code> which takes the cells and a name, and then each of these functions pass the requisite data to that class? That way we get the singleton behavior and naming without really much effort (and wouldn't conflict with anything else we are doing with <code>SimplicialComplex</code>).
</p>
TicketjhpalmieriSat, 24 Oct 2015 22:09:58 GMTdependencies changed
https://trac.sagemath.org/ticket/13566#comment:37
https://trac.sagemath.org/ticket/13566#comment:37
<ul>
<li><strong>dependencies</strong>
changed from <em>#13244, #12587, #14142</em> to <em>#13244, #12587, #14142, #6101</em>
</li>
</ul>
<p>
Okay. To do this, I've had to change <code>__cmp__</code> for <code>SimplicialComplexes</code> to <code>__eq__</code> and <code>__ne__</code> so that we could correctly compare a simplicial complex and a <code>UniqueSimplicialComplex</code>. I'm not sure what you meant by naming, but I took a guess. Since the names of these complexes arise frequently in doctests, and since many of those doctests are changed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/6101" title="enhancement: computation of induced morphism on homology and cohomology of ... (closed: fixed)">#6101</a>, I decided to make <a class="closed ticket" href="https://trac.sagemath.org/ticket/6101" title="enhancement: computation of induced morphism on homology and cohomology of ... (closed: fixed)">#6101</a> a dependency for this, to avoid later rebasing.
</p>
TicketgitSat, 24 Oct 2015 22:10:11 GMTcommit changed
https://trac.sagemath.org/ticket/13566#comment:38
https://trac.sagemath.org/ticket/13566#comment:38
<ul>
<li><strong>commit</strong>
changed from <em>1578bdbb15434ff33707b90efb723373260b0056</em> to <em>9251bde140ab58d9acfa28864bb5c27142f09055</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=470ca9b742e1efc2159b004f1b4edd9fd038eea9"><span class="icon"></span>470ca9b</a></td><td><code>trac 6102: Merge branch 'AT-model' into t/6101/induced-maps</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=6e3e801ccb73a6dca8c5e4bd05da0e87a511d437"><span class="icon"></span>6e3e801</a></td><td><code>trac 6101: Merge branch 'AT-model' into t/6101/induced-maps</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8e761de8be7e2f2e22fe942f2a0e4f782a79e198"><span class="icon"></span>8e761de</a></td><td><code>Merge branch 't/6102/AT-model' into t/6101/induced-maps</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=ec81de20addced6a723f51413c3ffb31eaf4bc13"><span class="icon"></span>ec81de2</a></td><td><code>trac 6101: make morphisms inherit from 'Morphism'</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=9d38c716dd14882f8c2c07bf430840c7f45e5649"><span class="icon"></span>9d38c71</a></td><td><code>trac 6101: Merge branch 't/18175/public/categories/topological_metric_spaces-18175' into t/6101/induced-maps</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=953e0a6489a3eca48b13b1e91ece798c51a6fe5c"><span class="icon"></span>953e0a6</a></td><td><code>trac 6101: add _an_element_, etc., to SimplicialComplex</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=b6c565763a2df99471bb6b574f60d15450b44c2e"><span class="icon"></span>b6c5657</a></td><td><code>Add a warning about the abuse of Parent in simplicial complex.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e9150caff3d157cadd739042461d972c9d5952f1"><span class="icon"></span>e9150ca</a></td><td><code>Merge branch 'develop' into public/algtop/induced_maps-6101</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=a4bc8a34599c130db811572d795ca593647cc5f4"><span class="icon"></span>a4bc8a3</a></td><td><code>Merge branch 't/6101/induced-maps' into t/13566/simplicial-examples</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=9251bde140ab58d9acfa28864bb5c27142f09055"><span class="icon"></span>9251bde</a></td><td><code>trac 13566: new class UniqueSimplicialComplex, for use with examples</code>
</td></tr></table>
TicketgitSat, 24 Oct 2015 22:16:01 GMTcommit changed
https://trac.sagemath.org/ticket/13566#comment:39
https://trac.sagemath.org/ticket/13566#comment:39
<ul>
<li><strong>commit</strong>
changed from <em>9251bde140ab58d9acfa28864bb5c27142f09055</em> to <em>090e5f90b40ca09c569e6227b78fdb1fb38e981b</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f8ed7e412652dd1f1e8b583de6aba6160c4d149e"><span class="icon"></span>f8ed7e4</a></td><td><code>trac 13566: new class UniqueSimplicialComplex, for use with examples</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=090e5f90b40ca09c569e6227b78fdb1fb38e981b"><span class="icon"></span>090e5f9</a></td><td><code>trac 13566: fix result of stupid emacs 'fill-paragraph'</code>
</td></tr></table>
TickettscrimSat, 24 Oct 2015 22:45:08 GMT
https://trac.sagemath.org/ticket/13566#comment:40
https://trac.sagemath.org/ticket/13566#comment:40
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/13566#comment:37" title="Comment 37">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Okay. To do this, I've had to change <code>__cmp__</code> for <code>SimplicialComplexes</code> to <code>__eq__</code> and <code>__ne__</code> so that we could correctly compare a simplicial complex and a <code>UniqueSimplicialComplex</code>. I'm not sure what you meant by naming, but I took a guess.
</p>
</blockquote>
<p>
Yes, that was what I was looking for. Note to self: Make sure the hash functions match as well.
</p>
TickettscrimSun, 25 Oct 2015 16:32:57 GMT
https://trac.sagemath.org/ticket/13566#comment:41
https://trac.sagemath.org/ticket/13566#comment:41
<p>
It looks like we're going to also have to handle some old pickles... :/
</p>
TicketjhpalmieriSun, 25 Oct 2015 21:07:58 GMT
https://trac.sagemath.org/ticket/13566#comment:42
https://trac.sagemath.org/ticket/13566#comment:42
<p>
I think this is easy to fix: just add the line
</p>
<pre class="wiki">SimplicialSurface = SimplicialComplex
</pre><p>
to <code>examples.py</code>. That line doesn't make any sense, though. Can we get rid of the old pickle?
</p>
TickettscrimMon, 26 Oct 2015 14:10:40 GMTcommit, branch changed
https://trac.sagemath.org/ticket/13566#comment:43
https://trac.sagemath.org/ticket/13566#comment:43
<ul>
<li><strong>commit</strong>
changed from <em>090e5f90b40ca09c569e6227b78fdb1fb38e981b</em> to <em>ebd4e8094b4d87baa22d5678820523992ad3312d</em>
</li>
<li><strong>branch</strong>
changed from <em>u/jhpalmieri/simplicial-examples</em> to <em>u/tscrim/simplicial-examples</em>
</li>
</ul>
<p>
Here's my proposal, use <code>register_unpickle_override</code>.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=ebd4e8094b4d87baa22d5678820523992ad3312d"><span class="icon"></span>ebd4e80</a></td><td><code>Taking care of an old pickle.</code>
</td></tr></table>
TickettscrimMon, 26 Oct 2015 14:11:39 GMT
https://trac.sagemath.org/ticket/13566#comment:44
https://trac.sagemath.org/ticket/13566#comment:44
<p>
Nom nom nom
</p>
<pre class="wiki">Using --optional=coxeter3,database_gap,dot2tex,gap_packages,lie,mpir,python2,sage
Doctesting 1 file using 8 threads.
sage -t --long ../structure/sage_object.pyx
[204 tests, 6.00 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 11.2 seconds
cpu time: 3.3 seconds
cumulative wall time: 6.0 seconds
</pre><p>
If you're happy with this change, then you can set a positive review.
</p>
TicketjhpalmieriMon, 26 Oct 2015 16:25:33 GMTstatus changed
https://trac.sagemath.org/ticket/13566#comment:45
https://trac.sagemath.org/ticket/13566#comment:45
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketjhpalmieriMon, 26 Oct 2015 16:25:44 GMT
https://trac.sagemath.org/ticket/13566#comment:46
https://trac.sagemath.org/ticket/13566#comment:46
<p>
All tests pass.
</p>
TicketgitSun, 08 Nov 2015 16:38:32 GMTstatus, commit changed
https://trac.sagemath.org/ticket/13566#comment:47
https://trac.sagemath.org/ticket/13566#comment:47
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>ebd4e8094b4d87baa22d5678820523992ad3312d</em> to <em>14e418490a1691df00c84ad93a02190445301c47</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=a6ce58cd59b021698f5232c2cf77a0eb16724dc1"><span class="icon"></span>a6ce58c</a></td><td><code>Implementation of Yokonuma-Hecke algebras.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=efadb136f0c54b5469bebd0c4c0f37f680d372ad"><span class="icon"></span>efadb13</a></td><td><code>Adding top-level doctests and checking d=1 case.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=20fd4ce076a61babcd7e1b23592f68ab16940e50"><span class="icon"></span>20fd4ce</a></td><td><code>Merge branch 'u/tscrim/simplicial-examples' of trac.sagemath.org:sage into u/tscrim/simplicial-examples</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=14e418490a1691df00c84ad93a02190445301c47"><span class="icon"></span>14e4184</a></td><td><code>Fixing some doctest continuations that were there before.</code>
</td></tr></table>
TicketgitSun, 08 Nov 2015 16:42:17 GMTcommit changed
https://trac.sagemath.org/ticket/13566#comment:48
https://trac.sagemath.org/ticket/13566#comment:48
<ul>
<li><strong>commit</strong>
changed from <em>14e418490a1691df00c84ad93a02190445301c47</em> to <em>bab305f1de1e2867b8b5f6a646e0444111515451</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=9004cdd49135c924f9f45f570f9ba7c549655182"><span class="icon"></span>9004cdd</a></td><td><code>Merge commit 'ebd4e8094b4d87baa22d5678820523992ad3312' into u/tscrim/simplicial-examples</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=bab305f1de1e2867b8b5f6a646e0444111515451"><span class="icon"></span>bab305f</a></td><td><code>Fixing some doctest continuations that were there before.</code>
</td></tr></table>
TickettscrimSun, 08 Nov 2015 16:43:28 GMTcc, status changed
https://trac.sagemath.org/ticket/13566#comment:49
https://trac.sagemath.org/ticket/13566#comment:49
<ul>
<li><strong>cc</strong>
<em>vbraun</em> added
</li>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Ignore the first commits, I forgot to checkout <code>develop</code>.
</p>
<p>
Hopefully now this can be merged.
</p>
TickettscrimWed, 25 Nov 2015 05:57:39 GMT
https://trac.sagemath.org/ticket/13566#comment:50
https://trac.sagemath.org/ticket/13566#comment:50
<p>
Volker, will this get merged for the next beta?
</p>
TicketvbraunWed, 25 Nov 2015 09:02:29 GMT
https://trac.sagemath.org/ticket/13566#comment:51
https://trac.sagemath.org/ticket/13566#comment:51
<p>
Once you take out the dependencies that don't correspond to merged tickets it'll be merged.
</p>
TickettscrimWed, 25 Nov 2015 14:12:05 GMTdependencies deleted
https://trac.sagemath.org/ticket/13566#comment:52
https://trac.sagemath.org/ticket/13566#comment:52
<ul>
<li><strong>dependencies</strong>
<em>#13244, #12587, #14142, #6101</em> deleted
</li>
</ul>
<p>
All of the dependencies had been merged...
</p>
TicketvbraunWed, 25 Nov 2015 23:29:37 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/13566#comment:53
https://trac.sagemath.org/ticket/13566#comment:53
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/tscrim/simplicial-examples</em> to <em>bab305f1de1e2867b8b5f6a646e0444111515451</em>
</li>
</ul>
Ticket