Sage: Ticket #15673: major improvements to lazy power series
https://trac.sagemath.org/ticket/15673
<p>
Some re-structuring of the streams / series code fixes many issues and makes the code quite a bit simpler.
</p>
<p>
Fixes <a class="new ticket" href="https://trac.sagemath.org/ticket/15249" title="defect: In lazy power series rings, 0 + a and 0 - a return 0 (new)">#15249</a>, <a class="new ticket" href="https://trac.sagemath.org/ticket/15248" title="defect: Calling a lazy power series ring twice summons demons from hell (new)">#15248</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/10084" title="defect: Lazy power series are created with incorrect order (needs_work)">#10084</a>, <a class="new ticket" href="https://trac.sagemath.org/ticket/10085" title="defect: The gen() method for power series over power series works incorrectly (new)">#10085</a>, <a class="new ticket" href="https://trac.sagemath.org/ticket/10086" title="defect: Coercion works incorrectly for power series over power series (new)">#10086</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/13433" title="defect: Lazy power series: fix bad handling of base ring and categorification (needs_work)">#13433</a>, <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/14685" title="defect: error in the computing of the approximate order in LazyPowerSeries (needs_work)">#14685</a>, <a class="new ticket" href="https://trac.sagemath.org/ticket/12648" title="defect: Species do not support renaming (new)">#12648</a>, <a class="new ticket" href="https://trac.sagemath.org/ticket/12649" title="defect: Bug in initialisation of species (new)">#12649</a>.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/15673
Trac 1.1.6mhansenTue, 14 Jan 2014 17:14:25 GMTbranch set
https://trac.sagemath.org/ticket/15673#comment:1
https://trac.sagemath.org/ticket/15673#comment:1
<ul>
<li><strong>branch</strong>
set to <em>u/mhansen/species_stream</em>
</li>
</ul>
TicketmhansenTue, 14 Jan 2014 17:15:02 GMTcommit set
https://trac.sagemath.org/ticket/15673#comment:2
https://trac.sagemath.org/ticket/15673#comment:2
<ul>
<li><strong>commit</strong>
set to <em>a696708e181c85bdfa355eaa3a253d4d2679c00b</em>
</li>
</ul>
<p>
One thing that should be done (maybe not on this ticket) is to deprecate the code in <code></code><code>sage.combinat.species.stream</code><code></code>.
</p>
<hr />
<p>
Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=b7afcd7f72725d998b71fe658f2168a223d4f0b2"><span class="icon"></span>b7afcd7</a></td><td><code>Simplifications to new_stream.py</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=69b55ab93de0361803ae92a4c05c931be6ffef48"><span class="icon"></span>69b55ab</a></td><td><code>Add documentation / doctests</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=13c5a49a23b60433c00633befe099d9a60c5db12"><span class="icon"></span>13c5a49</a></td><td><code>Remove TODO in cycle_species.py</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=bdad7a32ccd19a0505f3470e81cb844960ebec5e"><span class="icon"></span>bdad7a3</a></td><td><code>#12648: Species do not support renaming</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d2d753ec93465aef041ce2e5b779769acc361ba7"><span class="icon"></span>d2d753e</a></td><td><code>Fix bug in SeriesStream.is_constant()</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=fea9eb0e8a57196b269c96d39c52bfacd6838a00"><span class="icon"></span>fea9eb0</a></td><td><code>#15248: Convert LazyPowerSeriesRing (and friends) to new coercion model</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=652520034250fb22edfb96ce02f8adc943de36a7"><span class="icon"></span>6525200</a></td><td><code>Remove dependence on sage.combinat.species.stream</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=ed19baa2e208d71a90dc9d10348fa9dc325ccc3c"><span class="icon"></span>ed19baa</a></td><td><code>Add doctests to new_stream.py</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=654a89d5c25bd8c8cab03d2517a448ac799dc71f"><span class="icon"></span>654a89d</a></td><td><code>Add doctests to generating_series.py</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=bd7527ccaf2e7dd57b38f7a32165783c5a97545b"><span class="icon"></span>bd7527c</a></td><td><code>More work on doctests for series_stream.py</code>
</td></tr></table>
TicketgitTue, 14 Jan 2014 17:35:16 GMTcommit changed
https://trac.sagemath.org/ticket/15673#comment:3
https://trac.sagemath.org/ticket/15673#comment:3
<ul>
<li><strong>commit</strong>
changed from <em>a696708e181c85bdfa355eaa3a253d4d2679c00b</em> to <em>f4157f7f221f244b1faa2a0d07ddd8cd85bb7007</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=f4157f7f221f244b1faa2a0d07ddd8cd85bb7007"><span class="icon"></span>f4157f7</a></td><td><code>Remove dead code in GenericCombinatorialSpecies._series_helper</code>
</td></tr></table>
TicketmantepseTue, 14 Jan 2014 19:53:26 GMT
https://trac.sagemath.org/ticket/15673#comment:4
https://trac.sagemath.org/ticket/15673#comment:4
<p>
Hi Mike! Thank you for uploading the new code!
</p>
<p>
I have one immediate question: if I understand correctly, you chose to introduce a new class for every operation on streams, eg. <a class="missing wiki">SumStream?</a>, <a class="missing wiki">ProductStream?</a>, <a class="missing wiki">TailStream?</a>, <a class="missing wiki">DerivativeStream?</a>, etc.
</p>
<p>
Could you explain why...? I would have thought that these things fit more natural into various generating series classes, but I'm sure you have thought quite a lot about this...
</p>
<p>
Thanks again,
</p>
<p>
Martin
</p>
TicketmhansenTue, 14 Jan 2014 20:17:15 GMT
https://trac.sagemath.org/ticket/15673#comment:5
https://trac.sagemath.org/ticket/15673#comment:5
<p>
The main idea is to have the streams know about their (approximate) order. That way we don't have to worry about initializing generators with the correct approximate order. We can also do some improvements w.r.t. caching if the streams are a bit more structured.
</p>
TicketmantepseWed, 15 Jan 2014 07:49:36 GMT
https://trac.sagemath.org/ticket/15673#comment:6
https://trac.sagemath.org/ticket/15673#comment:6
<p>
Thanks for the explanation!
</p>
<p>
I am currently compiling sage to try your code. In case you have enough time: I recently reviewed ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/14846" title="enhancement: CycleIndexSeries derivative, integral, exponential methods are not ... (closed: fixed)">#14846</a>, which is based on the old code... Unfortunately, it is still not in the develop branch, so maybe it's better to wait until it is.
</p>
TicketmhansenWed, 15 Jan 2014 12:57:48 GMTdescription changed
https://trac.sagemath.org/ticket/15673#comment:7
https://trac.sagemath.org/ticket/15673#comment:7
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15673?action=diff&version=7">diff</a>)
</li>
</ul>
TicketmantepseWed, 15 Jan 2014 13:24:03 GMT
https://trac.sagemath.org/ticket/15673#comment:8
https://trac.sagemath.org/ticket/15673#comment:8
<p>
Mike, Are you sure that <a class="closed ticket" href="https://trac.sagemath.org/ticket/12659" title="enhancement: build the sage library in place (closed: invalid)">#12659</a> is related?
</p>
TicketmhansenWed, 15 Jan 2014 14:01:52 GMTdescription changed
https://trac.sagemath.org/ticket/15673#comment:9
https://trac.sagemath.org/ticket/15673#comment:9
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15673?action=diff&version=9">diff</a>)
</li>
</ul>
<p>
Oops, I meant <a class="new ticket" href="https://trac.sagemath.org/ticket/12649" title="defect: Bug in initialisation of species (new)">#12649</a>.
</p>
TicketmantepseThu, 16 Jan 2014 22:25:59 GMT
https://trac.sagemath.org/ticket/15673#comment:10
https://trac.sagemath.org/ticket/15673#comment:10
<p>
I'm slowly digging through the new code. I cannot yet decide whether I like it or not, because I really care about it, so I'd like to understand it first :-)
</p>
<p>
Questions so far:
</p>
<p>
1) would it be feasible (and not too much work) to put the new code for streams and formal power series into a new directory (or perhaps even into two, a separate one for streams)? After all, it's an accident that it's in the species directory. Species can do without formal power series (in principle), and streams have other uses.
</p>
<p>
2) I think I mostly like new_stream. However, from a user's perspective I would rather expect to create streams with
</p>
<pre class="wiki">sage: s=Stream([1,2,3,4]); t=Stream(lambda l: len(l))
</pre><p>
and moreover, I'd expect <code>s[4]</code> to give an error. That is, possibly we should have also finite streams. To create a stream which is constant, we could have something like <code>Stream(constantly="bla")</code>, and streams would have to support concatenation.
</p>
<p>
If we don't, then this behaviour has to be documented very LOUDLY. (I do see that <code>s=Stream([1,2,3,4,0])</code> is very convenient.)
</p>
<blockquote>
<p>
Minor details:
</p>
</blockquote>
<ul><li><code>StreamFromFunc</code> should be <code>StreamFromFunction</code> and it might be nice if it wouldn't inherit from <code>ListCachedStream</code>, i.e., support for streams where only some coefficients are computed.
</li></ul><ul><li><code>number_computed</code> maybe should be <code>length_of_cache</code>.
</li></ul><p>
3) I don't understand the difference between <code>SeriesStream</code> and a formal power series yet.
</p>
<p>
Would it be possible to use the category framework to export operations depending on what the <code>base_ring</code> is? In particular, as pointed out in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14846" title="enhancement: CycleIndexSeries derivative, integral, exponential methods are not ... (closed: fixed)">#14846</a>, one should be careful with providing certain default implementations. Perhaps related: ideally I would like to be able to say,
</p>
<pre class="wiki">sage: h = SymmetricFunctions(QQ).h()
sage: t = SetSpecies().cycle_index_series(); h(t)
</pre><p>
to do change of basis.
</p>
<blockquote>
<p>
Minor details:
</p>
</blockquote>
<ul><li>I would replace aorder everywhere with order_approximation
</li></ul><ul><li>I somehow dislike the idea of <code>children</code>, but cannot really say why.
</li></ul><ul><li>the doc for <code>IntegralStream</code> mentions derivative instead of integral.
</li></ul>
TicketmhansenFri, 17 Jan 2014 11:29:19 GMT
https://trac.sagemath.org/ticket/15673#comment:11
https://trac.sagemath.org/ticket/15673#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:10" title="Comment 10">mantepse</a>:
</p>
<blockquote class="citation">
<p>
I'm slowly digging through the new code. I cannot yet decide whether I like it or not, because I really care about it, so I'd like to understand it first :-)
</p>
<p>
Questions so far:
</p>
<p>
1) would it be feasible (and not too much work) to put the new code for streams and formal power series into a new directory (or perhaps even into two, a separate one for streams)? After all, it's an accident that it's in the species directory. Species can do without formal power series (in principle), and streams have other uses.
</p>
</blockquote>
<p>
Sure -- I'm not sure the best place for streams to go at the moment.
</p>
<blockquote class="citation">
<p>
2) I think I mostly like new_stream. However, from a user's perspective I would rather expect to create streams with
</p>
<pre class="wiki">sage: s=Stream([1,2,3,4]); t=Stream(lambda l: len(l))
</pre><p>
and moreover, I'd expect <code>s[4]</code> to give an error. That is, possibly we should have also finite streams. To create a stream which is constant, we could have something like <code>Stream(constantly="bla")</code>, and streams would have to support concatenation.
</p>
</blockquote>
<p>
You can basically do that with the "<a class="missing wiki">OldStreamBehavior?</a>" class.
</p>
<blockquote class="citation">
<p>
If we don't, then this behaviour has to be documented very LOUDLY. (I do see that <code>s=Stream([1,2,3,4,0])</code> is very convenient.)
</p>
</blockquote>
<p>
Agreed.
</p>
<blockquote class="citation">
<blockquote>
<p>
Minor details:
</p>
</blockquote>
<ul><li><code>StreamFromFunc</code> should be <code>StreamFromFunction</code> and it might be nice if it wouldn't inherit from <code>ListCachedStream</code>, i.e., support for streams where only some coefficients are computed.
</li></ul></blockquote>
<p>
The current semantics of <code>StreamFromFunc</code> basically require that it be a "<a class="missing wiki">ListCachedStream?</a>". We can add a <code>MappedStream</code> which applies a function which takes in a coefficient and produces a new one.
</p>
<blockquote class="citation">
<ul><li><code>number_computed</code> maybe should be <code>length_of_cache</code>.
</li></ul><p>
3) I don't understand the difference between <code>SeriesStream</code> and a formal power series yet.
</p>
</blockquote>
<p>
The distinction is pretty fine and in fact they could probably be merged. The main thing would be just be dealing with the class situation as if you had <code>class ProductSeries(LazyPowerSeries)</code> which implemented the things in <code>ProductStream</code>, then you'd also have to deal with "<code>OrdinaryProductSeries</code>", <code>IsotypeProductSeries</code>", and "<code>CycleIndexProductSeries</code>". They could be created on the fly say in <code>._new()</code>, but I wasn't sure if that added complexity was worth it.
</p>
<p>
For now, the best way to think of a difference between a <code>SeriesStream</code> and a <code>LazyPowerSeries</code> (and friends) is that the latter adds some sort of semantics / meaning to the list of coefficients (for example, <code>.count()</code>.
</p>
<blockquote class="citation">
<p>
Would it be possible to use the category framework to export operations depending on what the <code>base_ring</code> is? In particular, as pointed out in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14846" title="enhancement: CycleIndexSeries derivative, integral, exponential methods are not ... (closed: fixed)">#14846</a>, one should be careful with providing certain default implementations. Perhaps related: ideally I would like to be able to say,
</p>
<pre class="wiki">sage: h = SymmetricFunctions(QQ).h()
sage: t = SetSpecies().cycle_index_series(); h(t)
</pre><p>
to do change of basis.
</p>
</blockquote>
<p>
Since many of the (internal) operations need to work with the power-sum basis, you'd mainly just wanting to be converting the coefficients "at the edges". Or would you want them to always convert to the powersum basis when they needed to?
</p>
<blockquote class="citation">
<blockquote>
<p>
Minor details:
</p>
</blockquote>
<ul><li>I would replace aorder everywhere with order_approximation
</li></ul></blockquote>
<p>
That's fine -- I mainly kept aorder for backwards compatibility, but we don't need that on the new streams.
</p>
<blockquote class="citation">
<ul><li>I somehow dislike the idea of <code>children</code>, but cannot really say why.
</li></ul></blockquote>
<p>
In terms of the name? Or in terms of being able to access "sub-streams"?
</p>
<blockquote class="citation">
<ul><li>the doc for <code>IntegralStream</code> mentions derivative instead of integral.
</li></ul></blockquote>
<p>
Will fix.
</p>
TicketgitFri, 17 Jan 2014 12:11:45 GMTcommit changed
https://trac.sagemath.org/ticket/15673#comment:12
https://trac.sagemath.org/ticket/15673#comment:12
<ul>
<li><strong>commit</strong>
changed from <em>f4157f7f221f244b1faa2a0d07ddd8cd85bb7007</em> to <em>927ff83b9f363f2d15db4b638a9439b041dd6479</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=927ff83b9f363f2d15db4b638a9439b041dd6479"><span class="icon"></span>927ff83</a></td><td><code>#15673: Minor changes from Martin Rubey's coments</code>
</td></tr></table>
TicketmantepseFri, 17 Jan 2014 12:45:48 GMT
https://trac.sagemath.org/ticket/15673#comment:13
https://trac.sagemath.org/ticket/15673#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:11" title="Comment 11">mhansen</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
2) I think I mostly like new_stream. However, from a user's perspective I would rather expect to create streams with
</p>
<pre class="wiki">sage: s=Stream([1,2,3,4]); t=Stream(lambda l: len(l))
</pre><p>
and moreover, I'd expect <code>s[4]</code> to give an error. That is, possibly we should have also finite streams. To create a stream which is constant, we could have something like <code>Stream(constantly="bla")</code>, and streams would have to support concatenation.
</p>
</blockquote>
<p>
You can basically do that with the "<a class="missing wiki">OldStreamBehavior?</a>" class.
</p>
</blockquote>
<p>
Well, we certainly do not want to keep two implementations for the same thing, do we? To put it bluntly, I'm not sure whether this design decision is a good one. Let's make the decisions clear:
</p>
<p>
A) do we want to create streams using <code>Stream(thing_to_concert_into_a_stream</code> or <code>StreamFromList</code>, <code>StreamFromIterator</code>, etc.
</p>
<blockquote>
<p>
I am sure I want the first behaviour. Is there any sage object that you create using the second model at all?
</p>
</blockquote>
<p>
B) do we want finite streams?
</p>
<blockquote>
<p>
I'm not so sure here. However, if we don't we agree on LOUD documentation.
</p>
</blockquote>
<blockquote class="citation">
<p>
The current semantics of <code>StreamFromFunc</code> basically require that it be a "<a class="missing wiki">ListCachedStream?</a>". We can add a <code>MappedStream</code> which applies a function which takes in a coefficient and produces a new one.
</p>
</blockquote>
<p>
Yes, it may be good to have both. But then the semantics should be precisely the other way round.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
3) I don't understand the difference between <code>SeriesStream</code> and a formal power series yet.
</p>
</blockquote>
</blockquote>
<blockquote class="citation">
<p>
[...]
For now, the best way to think of a difference between a <code>SeriesStream</code> and a <code>LazyPowerSeries</code> (and friends) is that the latter adds some sort of semantics / meaning to the list of coefficients (for example, <code>.count()</code>.
</p>
</blockquote>
<p>
I dislike at least the choice for the names here. <code>LazyPowerSeries</code> should be an element of the algebra of formal power series over a ring, I'd say. I think we should eliminate <code>.count</code> entirely. If we don't, then this should go into <code>ExponentialGeneratingSeries</code>, <code>OrdinaryGeneratingSeries</code>, <code>DirichletGeneratingSeries</code>, etc. <code>CycleIndexSeries</code> is special and I need to think before having an opinion :-)
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Would it be possible to use the category framework to export operations depending on what the <code>base_ring</code> is? In particular, as pointed out in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14846" title="enhancement: CycleIndexSeries derivative, integral, exponential methods are not ... (closed: fixed)">#14846</a>, one should be careful with providing certain default implementations.
</p>
</blockquote>
</blockquote>
<p>
It would be great if you could give your opinion on that, I don't know the category framework well enough. In Axiom/FriCAS/Aldor it was extremely useful especially for formal power series. NB, Ralf implemented the lazy series in aldor from scratch only because he wanted to be independent from Axiom/FriCAS.
</p>
<p>
Need to run. All the best,
</p>
<p>
Martin
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=927ff83b9f363f2d15db4b638a9439b041dd6479"><span class="icon"></span>927ff83</a></td><td><code>#15673: Minor changes from Martin Rubey's coments</code>
</td></tr></table>
TicketmantepseMon, 20 Jan 2014 10:02:04 GMT
https://trac.sagemath.org/ticket/15673#comment:14
https://trac.sagemath.org/ticket/15673#comment:14
<p>
Hi Mike,
</p>
<p>
one minor further issue: we still have
</p>
<pre class="wiki">sage: from sage.combinat.species.series_order import unk
sage: min(1,unk)
Unknown series order
sage: min(unk,1)
1
</pre><p>
While I was unable to produce an actual bug using this, it might be possible. I think we should have a simple linear order <code> unk < 1 < 2 < ... < inf </code>. Do you know how to do this?
</p>
TicketmhansenMon, 20 Jan 2014 12:03:47 GMT
https://trac.sagemath.org/ticket/15673#comment:15
https://trac.sagemath.org/ticket/15673#comment:15
<p>
Yes, that's still an issue when using Integers as series orders due to the way Python works. One way to do it would be to make sure that ".aorder" is an element of a special ordered set so that we can make sure the current comparison is being used.
</p>
TicketmantepseMon, 20 Jan 2014 14:07:41 GMT
https://trac.sagemath.org/ticket/15673#comment:16
https://trac.sagemath.org/ticket/15673#comment:16
<p>
(Off topic) Mike, there's something I do not understand about trac: in the change history here on the ticket I see two identical commits:
</p>
<p>
<code>927ff83 #15673: Minor changes from Martin Rubey's coments</code>
</p>
<p>
should I expect this?
</p>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/15673#comment:17
https://trac.sagemath.org/ticket/15673#comment:17
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketrwsTue, 25 Feb 2014 09:12:13 GMTreviewer set
https://trac.sagemath.org/ticket/15673#comment:18
https://trac.sagemath.org/ticket/15673#comment:18
<ul>
<li><strong>reviewer</strong>
set to <em>Ralf Stephan</em>
</li>
</ul>
<p>
The branch does not merge cleanly into 6.2.beta2 but it's a one line change. Tests within species are good. Docs build fine.
</p>
<p>
I also think that stream is another word for infinite sequence, and so a finite stream implementation already exists in structure.sequence, which is also fast (there are however problems in that Sequence doesn't have a parent, see <a class="closed ticket" href="https://trac.sagemath.org/ticket/15852" title="enhancement: uncouple Sequence from categories (closed: fixed)">#15852</a>).
</p>
TicketvdelecroixMon, 07 Apr 2014 14:09:32 GMT
https://trac.sagemath.org/ticket/15673#comment:19
https://trac.sagemath.org/ticket/15673#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:18" title="Comment 18">rws</a>:
</p>
<blockquote class="citation">
<p>
The branch does not merge cleanly into 6.2.beta2 but it's a one line change. Tests within species are good. Docs build fine.
</p>
<p>
I also think that stream is another word for infinite sequence, and so a finite stream implementation already exists in structure.sequence, which is also fast (there are however problems in that Sequence doesn't have a parent, see <a class="closed ticket" href="https://trac.sagemath.org/ticket/15852" title="enhancement: uncouple Sequence from categories (closed: fixed)">#15852</a>).
</p>
</blockquote>
<p>
Note that there is also <code>sage.misc.lazy_list</code> which is a cython implementation of a lazy list and there are several interesting implementations of lazy words in <code>sage.combinat.words</code>...
</p>
TicketchapotonTue, 08 Apr 2014 12:52:40 GMTcommit, branch changed
https://trac.sagemath.org/ticket/15673#comment:20
https://trac.sagemath.org/ticket/15673#comment:20
<ul>
<li><strong>commit</strong>
changed from <em>927ff83b9f363f2d15db4b638a9439b041dd6479</em> to <em>8ff4acc7625dd8d374a12e0170b3b7436b6bca92</em>
</li>
<li><strong>branch</strong>
changed from <em>u/mhansen/species_stream</em> to <em>public/ticket/15673</em>
</li>
</ul>
<p>
I have rebased on 6.2.beta6 : here is a git branch
</p>
<p>
Is this considered to be "needs review" ?
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8ff4acc7625dd8d374a12e0170b3b7436b6bca92"><span class="icon"></span>8ff4acc</a></td><td><code>Merge branch 'u/mhansen/species_stream' of trac.sagemath.org:sage into 15673</code>
</td></tr></table>
TicketMatthieuDienTue, 08 Apr 2014 13:51:50 GMTkeywords, reviewer changed
https://trac.sagemath.org/ticket/15673#comment:21
https://trac.sagemath.org/ticket/15673#comment:21
<ul>
<li><strong>keywords</strong>
<em>days57</em> added
</li>
<li><strong>reviewer</strong>
changed from <em>Ralf Stephan</em> to <em>Ralf Stephan, Matthieu Dien</em>
</li>
</ul>
TicketMatthieuDienTue, 08 Apr 2014 13:54:54 GMT
https://trac.sagemath.org/ticket/15673#comment:22
https://trac.sagemath.org/ticket/15673#comment:22
<p>
Hello,
</p>
<p>
I can help to improve and review this ticket.
I also explore the way to use it to deal with multivariate lazy series
</p>
TicketmantepseTue, 08 Apr 2014 14:58:05 GMT
https://trac.sagemath.org/ticket/15673#comment:23
https://trac.sagemath.org/ticket/15673#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:20" title="Comment 20">chapoton</a>:
</p>
<blockquote class="citation">
<p>
I have rebased on 6.2.beta6 : here is a git branch
</p>
<p>
Is this considered to be "needs review" ?
</p>
</blockquote>
<p>
No, I'd say it needs work. At least the proposed way to create streams doesn't look right from a user's perspective. However, it's a huge improvement over the old code!
</p>
TicketMatthieuDienTue, 08 Apr 2014 17:57:08 GMT
https://trac.sagemath.org/ticket/15673#comment:24
https://trac.sagemath.org/ticket/15673#comment:24
<p>
I updated tests and documentation
</p>
TicketgitTue, 08 Apr 2014 18:19:02 GMTcommit changed
https://trac.sagemath.org/ticket/15673#comment:25
https://trac.sagemath.org/ticket/15673#comment:25
<ul>
<li><strong>commit</strong>
changed from <em>8ff4acc7625dd8d374a12e0170b3b7436b6bca92</em> to <em>5d3dfc2605797b4d4b70f5e5b7c5b9ceb8e27b58</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=5d3dfc2605797b4d4b70f5e5b7c5b9ceb8e27b58"><span class="icon"></span>5d3dfc2</a></td><td><code>add tests and improve documentation</code>
</td></tr></table>
TicketrwsWed, 09 Apr 2014 07:08:31 GMT
https://trac.sagemath.org/ticket/15673#comment:26
https://trac.sagemath.org/ticket/15673#comment:26
<p>
<a class="new ticket" href="https://trac.sagemath.org/ticket/16107" title="enhancement: Meta ticket: unified sequence/lazy list objects (new)">#16107</a> depends on this.
</p>
TicketnthieryWed, 09 Apr 2014 22:15:37 GMT
https://trac.sagemath.org/ticket/15673#comment:27
https://trac.sagemath.org/ticket/15673#comment:27
<blockquote>
<p>
Hi Mike!
</p>
</blockquote>
<p>
The is_constant protocol seems somewhat convoluted; from profiling, Matthieu is telling me that it's taking a non trivial portion of the time. Could it be possibly simplified? In particular, could we just get rid of is_constant, and handle everything with a cached method "get_constant_position" which would return infinity when appropriate?
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketmantepseThu, 10 Apr 2014 09:44:09 GMT
https://trac.sagemath.org/ticket/15673#comment:28
https://trac.sagemath.org/ticket/15673#comment:28
<p>
I just had a very brief look at lazy lists. Is there any reason not to use them? There may be some work involved to allow for recursively defined lists, I'm not sure.
</p>
TicketMatthieuDienThu, 10 Apr 2014 10:14:44 GMT
https://trac.sagemath.org/ticket/15673#comment:29
https://trac.sagemath.org/ticket/15673#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:28" title="Comment 28">mantepse</a>:
</p>
<blockquote class="citation">
<p>
I just had a very brief look at lazy lists. Is there any reason not to use them? There may be some work involved to allow for recursively defined lists, I'm not sure.
</p>
</blockquote>
<p>
I'm working on it, I should propose an implementation soon
</p>
TicketMatthieuDienFri, 11 Apr 2014 18:05:08 GMT
https://trac.sagemath.org/ticket/15673#comment:30
https://trac.sagemath.org/ticket/15673#comment:30
<p>
We opened a new ticket about <code>lazy_list</code> (<a class="closed ticket" href="https://trac.sagemath.org/ticket/16137" title="enhancement: lazy_list from various input data (closed: fixed)">#16137</a>) with the idea to replace the <code>sage.combinat.species.new_stream</code> backend (slower than <code>lazy_list</code>).
</p>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/15673#comment:31
https://trac.sagemath.org/ticket/15673#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/15673#comment:32
https://trac.sagemath.org/ticket/15673#comment:32
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketgitThu, 16 Oct 2014 11:05:44 GMTcommit changed
https://trac.sagemath.org/ticket/15673#comment:33
https://trac.sagemath.org/ticket/15673#comment:33
<ul>
<li><strong>commit</strong>
changed from <em>5d3dfc2605797b4d4b70f5e5b7c5b9ceb8e27b58</em> to <em>8e004ea424678354b242afd43f7bdbe17501e1f0</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=34ceae0b1078194bb8766d5706f2c7a4ab45e08a"><span class="icon"></span>34ceae0</a></td><td><code>Merge branch 'public/ticket/15673' of trac.sagemath.org:sage into 6.4.beta6</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8e004ea424678354b242afd43f7bdbe17501e1f0"><span class="icon"></span>8e004ea</a></td><td><code>trac #15673 correct doctests</code>
</td></tr></table>
TicketchapotonTue, 21 Oct 2014 16:06:23 GMTstatus changed
https://trac.sagemath.org/ticket/15673#comment:34
https://trac.sagemath.org/ticket/15673#comment:34
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketmantepseTue, 21 Oct 2014 19:28:35 GMT
https://trac.sagemath.org/ticket/15673#comment:35
https://trac.sagemath.org/ticket/15673#comment:35
<p>
Is there any intention to pursue <a class="closed ticket" href="https://trac.sagemath.org/ticket/16137" title="enhancement: lazy_list from various input data (closed: fixed)">#16137</a>? I'm not sure, but it seems to me that my comments 11 and 13 above were not taken into account so far (in fact, 13 was not answered at all), and the design decisions taken here seem to contradict the ideas of <a class="closed ticket" href="https://trac.sagemath.org/ticket/16137" title="enhancement: lazy_list from various input data (closed: fixed)">#16137</a>. This is partially about terminology: from a user's perspective, I wouldn't expect a stream to carry any semantics except that it is a possibly infinite sequence of things. In particular, it should work also for things other than numbers and polynomials. However, then things like <code>IntegralStream</code> doesn't make sense, this is confusing formal power series with streams.
</p>
<p>
That said, I tried to read the code, and found that I'm completely lost. I have no way to adapt it as to provide an alternative implementation. Thus, in case you think my concerns are of minor importance, please go ahead!
</p>
TicketgitSun, 08 Feb 2015 19:04:41 GMTcommit changed
https://trac.sagemath.org/ticket/15673#comment:36
https://trac.sagemath.org/ticket/15673#comment:36
<ul>
<li><strong>commit</strong>
changed from <em>8e004ea424678354b242afd43f7bdbe17501e1f0</em> to <em>5478a2de727c686fd1d892ea8186d54b8d839daa</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=f8815da4c6d0a2a613c22009e5189d5b49c784ac"><span class="icon"></span>f8815da</a></td><td><code>Merge branch 'public/ticket/15673' into 6.5.rc0</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=5478a2de727c686fd1d892ea8186d54b8d839daa"><span class="icon"></span>5478a2d</a></td><td><code>trac #15673 put raise statements into py3 standard</code>
</td></tr></table>
TicketchapotonTue, 17 Feb 2015 16:00:12 GMTstatus changed
https://trac.sagemath.org/ticket/15673#comment:37
https://trac.sagemath.org/ticket/15673#comment:37
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This has rotten. Too bad. Needs rebase, and not an easy one.
</p>
TicketvdelecroixSun, 10 Jan 2016 17:22:08 GMT
https://trac.sagemath.org/ticket/15673#comment:38
https://trac.sagemath.org/ticket/15673#comment:38
<p>
Hello,
</p>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/16137" title="enhancement: lazy_list from various input data (closed: fixed)">#16137</a> is in the process of being reviewed. Note that it will just be a fast and flexible data structures for (finite or infinite) list like objects. Features:
</p>
<ul><li>it is very lazy (zero computation at instanciation)
</li><li>it is a tiny Cython wrapper above list and is hence very fast to access the cached values
</li><li>definition can be recursive and involve other lazy lists
</li><li>there is no such thing as "ultimately constant lazy list" or "compute with no cache lazy list"
</li><li>they are currently immutable (which allows to share memory for slices)
</li></ul><p>
Vincent
</p>
TicketmantepseMon, 11 Jan 2016 14:20:22 GMTcc changed
https://trac.sagemath.org/ticket/15673#comment:39
https://trac.sagemath.org/ticket/15673#comment:39
<ul>
<li><strong>cc</strong>
<em>vdelecroix</em> added
</li>
</ul>
TicketmantepseMon, 11 Jan 2016 17:03:36 GMT
https://trac.sagemath.org/ticket/15673#comment:40
https://trac.sagemath.org/ticket/15673#comment:40
<p>
I looked again at the code by Mike Hansen, I believe I understand it a little bit better than 2 years ago. I try to give a summary, and hope to get some feedback.
</p>
<p>
The code in this ticket consists of three parts: streams (with similar intentions to <code>lazy_list</code>), power series, and the adaptation of the species code.
</p>
<p>
The code for streams (only roughly 500 lines) is in <code>new_stream.py</code>. It introduces different classes depending on how the stream is to be produced: <code>StreamFromIterator</code>, <code>StreamFromList</code>, <code>StreamFromFunction</code> (unused), and an "abstract base class" <code>ListCachedStream</code>.
</p>
<p>
The code for series is mainly in <code>series_stream.py</code> and <code>series.py</code>. The main class is <code>SeriesStream</code> (which is a misnomer, I'd say). Its main purpose is to set up the protocol that enables recursive definitions, by keeping track of the so called approximate order of a series, which is a lower bound on the exponent of the monomials in the series with non-vanishing coefficient.
</p>
<p>
For each operation on series (binary, like addition, multiplication, composition; unary, like derivative, etc.) introduces a new class, where the above mentioned order and the actual terms are computed.
</p>
<p>
Finally, the classes <code>LazyPowerSeriesRing</code> and <code>LazyPowerSeries</code> in <code>series.py</code> put this into the algebraic framework.
</p>
<p>
There are many things I do not completely understand. For example, for the species code yet another class, <code>SpeciesSeriesStream</code>, is introduced, rather than just using <code>LazyPowerSeries</code>. I have no idea why this is so complicated. (It wasn't complicated in the original aldor code, and it's somehow hard to believe that python would need so much more code.)
</p>
<p>
Assuming that the code is OK I guess it's best if I rebase it and see what happens.
</p>
TicketmantepseMon, 11 Jan 2016 21:45:50 GMT
https://trac.sagemath.org/ticket/15673#comment:41
https://trac.sagemath.org/ticket/15673#comment:41
<p>
So far I have rebased the files <code>new_stream.py</code>, <code>series.py</code> and <code>generating_series.py</code>. I guess it's best to push to a new branch, right?
</p>
<p>
One thing I'd like to note here is that many tests in <code>generating_series.py</code> depend on species, which I haven't rebased yet, and thus fail :-(
</p>
TicketmantepseMon, 11 Jan 2016 23:28:34 GMTbranch changed; commit deleted
https://trac.sagemath.org/ticket/15673#comment:42
https://trac.sagemath.org/ticket/15673#comment:42
<ul>
<li><strong>commit</strong>
<em>5478a2de727c686fd1d892ea8186d54b8d839daa</em> deleted
</li>
<li><strong>branch</strong>
changed from <em>public/ticket/15673</em> to <em>u/mantepse/15673</em>
</li>
</ul>
TicketgitMon, 11 Jan 2016 23:30:00 GMTcommit set
https://trac.sagemath.org/ticket/15673#comment:43
https://trac.sagemath.org/ticket/15673#comment:43
<ul>
<li><strong>commit</strong>
set to <em>aa8fd83522eaeb583da0caa5c6628ddd1ed36b04</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=aa8fd83522eaeb583da0caa5c6628ddd1ed36b04"><span class="icon"></span>aa8fd83</a></td><td><code>rebase Mike Hansen's code</code>
</td></tr></table>
TicketmantepseMon, 11 Jan 2016 23:32:57 GMT
https://trac.sagemath.org/ticket/15673#comment:44
https://trac.sagemath.org/ticket/15673#comment:44
<p>
I have now completed the rebase. All tests pass. It would be great if someone more versed in python than me could look at the design...
</p>
TicketvdelecroixTue, 12 Jan 2016 00:37:30 GMT
https://trac.sagemath.org/ticket/15673#comment:45
https://trac.sagemath.org/ticket/15673#comment:45
<p>
Well done for the rebase!
</p>
<p>
Some personal feelings about the code
</p>
<ol><li>There are public method that should not be there. For example <code>Stream.compute</code>. The documentation mentions <code>Do not use this method</code>. In such case, the method should be private, i.e. starting with an underscore like <code>_compute</code>. Might apply as well to <code>SeriesStream.refine_order</code>, <code>SeriesStream.compute_order</code>, <code>RecursiveStream.not_defined_check</code>, ...
</li></ol><ol start="2"><li>The <code>check_constant_decorator</code> is really ugly. I would implement it directly in the <code>__getitem__</code>.
</li></ol><ol start="3"><li>You should seriously consider replacing <code>new_stream.py</code> with <code>lazy_list.pyx</code> which is currently about 5x faster for <code>__getitem__</code> and provide more or less the same functionality
<pre class="wiki">sage: from sage.combinat.species.new_stream import StreamFromFunction
sage: h = lambda l: 1 if len(l) < 2 else l[-1] + l[-2]
sage: s = StreamFromFunction(h)
sage: from sage.misc.lazy_list import lazy_list
sage: def h2(l): l.append(l[-1]+l[-2])
sage: s2 = lazy_list(initial_values=[1,1],update_function=h2)
</pre>Then
<pre class="wiki">sage: %timeit s[0]
1000000 loops, best of 3: 942 ns per loop
sage: %timeit s2[0]
10000000 loops, best of 3: 148 ns per loop
</pre>Though there are missing features. For example, current <code>lazy_list</code> do not care about being periodic or constant after a certain point. But I would be happy to implement needed stuff from this side.
</li></ol><blockquote>
<p>
This series code would be a good test case to see whether <code>lazy_list</code> are as flexible as they claim to be.
</p>
</blockquote>
<ol start="4"><li>In many situations it would be much faster to use Newton's method rather than an intricated tree of streams.
</li></ol>
TicketmantepseTue, 12 Jan 2016 07:42:01 GMT
https://trac.sagemath.org/ticket/15673#comment:46
https://trac.sagemath.org/ticket/15673#comment:46
<p>
Thanks for your comments!
</p>
<p>
ad 1. and 3.: yes, that's what I want to do. I'm currently trying to figure out whether I should let <code>SeriesStream</code> inherit from <code>lazy_list</code>. I guess that <code>Stream</code>, <code>ListCachedStream</code>, etc. should be eliminated entirely.
</p>
<p>
ad 4.: I guess that you are referring to the examples in the species code - I do not think there is any recursive definition used in library code. Of course Newton would be faster. The point of the recursive facility is only to create a species easily, for example to check the first few terms of the cycle index series. In case one needs more speed, one will have to "really" implement the species.
</p>
<p>
ad 2.: unfortunately, I do not really know what it does. I'll try to figure out.
</p>
TicketelixyreWed, 13 Jan 2016 12:34:58 GMT
https://trac.sagemath.org/ticket/15673#comment:47
https://trac.sagemath.org/ticket/15673#comment:47
<p>
Hello,
</p>
<p>
Thanks to update and improve this code! ;-)
</p>
<p>
I have a stupid question: the <em>lazy</em> thing is a trick to compute efficiently the coefficient of the product of series or some other operations on series, right?
</p>
<p>
About the code, why does <code>LazyPowerSeries</code> only inherit of <code>AlgebraElement</code> and not of <code>Stream</code>? It seems not so python/object to define a lazy series as a <em>capsule</em> of a stream so I want to understand.
</p>
<p>
All I read in the code look like this
</p>
<pre class="wiki">class LazyPowerSeries(...):
....
def get_order(self):
return self._stream.get_order()
....
</pre><p>
so it seems better to inherit of <code>Stream</code>.
</p>
<p>
Jean-Baptiste Priez
</p>
TicketmantepseWed, 13 Jan 2016 12:46:28 GMT
https://trac.sagemath.org/ticket/15673#comment:48
https://trac.sagemath.org/ticket/15673#comment:48
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:47" title="Comment 47">elixyre</a>:
</p>
<blockquote class="citation">
<p>
I have a stupid question: the <em>lazy</em> thing is a trick to compute efficiently the coefficient of the product of series or some other operations on series, right?
</p>
</blockquote>
<p>
No. The laziness is for having potentially infinite sequences.
</p>
<blockquote class="citation">
<p>
About the code, why does <code>LazyPowerSeries</code> only inherit of <code>AlgebraElement</code> and not of <code>Stream</code>?
</p>
</blockquote>
<p>
Unless I misunderstand python's inheritance, the point is that a <code>LazyPowerSeries</code> should not have the methods of it's stream of coefficients.
</p>
<p>
My current plan is to remove <code>Stream</code> entirely, rename <code>SeriesStream</code> to <code>CoefficientStream</code> and make the latter into a ring module, which uses the new <code>lazy_list</code>, or, once that is in place, Daniel Krenn's <code>InfiniteSequence</code>.
</p>
TicketchapotonWed, 13 Jan 2016 19:30:59 GMTmilestone changed
https://trac.sagemath.org/ticket/15673#comment:49
https://trac.sagemath.org/ticket/15673#comment:49
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-7.0</em>
</li>
</ul>
<p>
There is a bad <code>INPUT::</code> that should be replaced by <code>INPUT:</code>
</p>
<p>
and doc does not build, see patchbot report
</p>
TicketmantepseThu, 14 Jan 2016 08:04:54 GMT
https://trac.sagemath.org/ticket/15673#comment:50
https://trac.sagemath.org/ticket/15673#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:49" title="Comment 49">chapoton</a>:
</p>
<blockquote class="citation">
<p>
There is a bad <code>INPUT::</code> that should be replaced by <code>INPUT:</code>
</p>
<p>
and doc does not build, see patchbot report
</p>
</blockquote>
<p>
Thanks, I changed this locally. However, I will not take care of the documentation at the moment, because I'm currently (really!) working on the design.
</p>
<p>
Right now I think that I want a class <code>CoefficientStream</code> to model the algebraic structure of the sequence of coefficients of a formal power series with coefficients in a ring, i.e., inheriting from <code>ModuleElement</code>.
</p>
<p>
I am not yet sure whether the computation of the approximate order really belongs here: after all, we want to recursively specify formal power series, not coefficient streams. The design decision is not completely clear, because formal power series and coefficient streams are almost the same thing - except that most operations feel more natural on the level of formal power series.
</p>
<p>
Suggestions and comments very welcome!
</p>
TicketelixyreThu, 14 Jan 2016 08:26:33 GMT
https://trac.sagemath.org/ticket/15673#comment:51
https://trac.sagemath.org/ticket/15673#comment:51
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15673#comment:50" title="Comment 50">mantepse</a>:
</p>
<blockquote class="citation">
<p>
I'm currently (really!) working on the design.
I am not yet sure whether the computation of the approximate order really belongs here: after all, we want to recursively specify formal power series, not coefficient streams. The design decision is not completely clear, because formal power series and coefficient streams are almost the same thing - except that most operations feel more natural on the level of formal power series.
</p>
<blockquote>
<p>
Suggestions and comments very welcome!
</p>
</blockquote>
</blockquote>
<p>
I will be happy to discuss code design with you.
</p>
<p>
I have some code (about species) on the branch <code>u/elixyre/species</code> (not associated to any ticket). I was trying to redesign the species with the goal to use the current <code>Permutations</code>, <code>Partitions</code>, <em>etc</em> ... I don't used the design Parent-Element, I was to lazy to update this code but I can do it easily...
</p>
<p>
Whatever I recode my own <code>Series</code> on this branch (as a simple exercice to understand operations on series). There is a lot of really simple code that I assume to be a draft of a good (code) design. My code was thought to be simple to improve and understand.
</p>
<p>
(Specially I have a <em>nice</em> simple tool to compute the valuation.)
</p>
<p>
Do you have some branch where you try your own design that I could pull?
</p>
TicketmantepseThu, 14 Jan 2016 11:39:19 GMT
https://trac.sagemath.org/ticket/15673#comment:52
https://trac.sagemath.org/ticket/15673#comment:52
<blockquote class="citation">
<p>
I will be happy to discuss code design with you.
</p>
</blockquote>
<p>
Great!
</p>
<blockquote class="citation">
<p>
I have some code (about species) on the branch <code>u/elixyre/species</code> (not associated to any ticket). I was trying to redesign the species with the goal to use the current <code>Permutations</code>, <code>Partitions</code>, <em>etc</em> ... I don't used the design Parent-Element, I was to lazy to update this code but I can do it easily...
</p>
</blockquote>
<p>
Is this in the species2 directory?
</p>
<blockquote class="citation">
<p>
Whatever I recode my own <code>Series</code> on this branch (as a simple exercice to understand operations on series). There is a lot of really simple code that I assume to be a draft of a good (code) design. My code was thought to be simple to improve and understand.
</p>
<p>
(Specially I have a <em>nice</em> simple tool to compute the valuation.)
</p>
</blockquote>
<p>
So, very likely it makes sense to start from your branch?
</p>
<blockquote class="citation">
<p>
Do you have some branch where you try your own design that I could pull?
</p>
</blockquote>
<p>
No, because I'm doing this with pencil and paper...
</p>
<p>
Eventually we could talk, too, I have webcam + whiteboard.
</p>
Ticket