categories of lazy series

[mantepse]

We should check the categories of our lazy rings:

sage: L = LazyTaylorSeriesRing(QQ, "x, y") ; L in DiscreteValuationRings
True
sage: L in PrincipalIdealDomains
True

is wrong. It is not even a 'valuation ring' , see https://en.wikipedia.org/wiki/Valuation_ring, because neither x/y not y/x is in L. I doubt it should be in UniqueFactorizationDomains, because this category is reserved for constructive UFD's.

In the univariate case, the uniformizer is the generator "x", but this is not yet implemented:

sage: L = LazyTaylorSeriesRing(QQ, "x")
sage: L.uniformizer()
...
NotImplementedError: <abstract method uniformizer at 0x7ff26e85acb0>

Similarly, we have

sage: LazySymmetricFunctions(SymmetricFunctions(QQ).p()) in DiscreteValuationRings
True
sage: LazySymmetricFunctions(SymmetricFunctions(QQ).p()) in PrincipalIdealDomains
True

which is also wrong.

Depends on #32367

CC: @tscrim

Component: categories

Keywords: LazyPowerSeries

Author: Martin Rubey

Branch/Commit: 56cef07

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/34470

[mantepse]

Changed keywords from none to LazyPowerSeries

[tscrim]

comment:3

Indeed, a valuation ring is not simply the ring version of a valuation field.

Something in UFDs does not need to be constructive, although it does make it somewhat useless to be in that category. I cannot seem to find much of anything on factoring multivariate FPS. I suspect we can do something recursive and take advantage of the group of units being so large. Although I don’t know of a way to do this after thinking about it for the past 20 minutes. However, it is known to be a UFD (with finitely many products?).

[mantepse]

comment:4

Init signature: UniqueFactorizationDomains(s=None)
Docstring:     
   The category of unique factorization domains constructive unique
   factorization domains, i.e. where one can constructively factor
   members into a product of a finite number of irreducible elements

(the typo should be a ticket I'll open shortly)

[tscrim]

comment:5

I see. I don’t agree with that definition (there could be ambiguity about what constructively means) as the ability for something to actually do the properties specified in the category is always an implicit requirement. Anyways, it is explicitly requiring it to be done, so it shouldn’t be in UFD for now.

[mantepse]

Author: Martin Rubey

[mantepse]

Dependencies: #32367

[mantepse]

Branch: u/mantepse/categories_of_lazy_series

[mantepse]

comment:8

Shouldn't all of these actually be in GradedAlgebrasWithBasis? I have no idea what the consequences might be. However, it might be nice if, for any element of an integer graded algebra, __getitem__ would be defined as we just did for LazyModuleElement. I'd love to be able to type

sage: s = SymmetricFunctions(QQ).s()
sage: f = s[2,1]*(s[1]+s[2]+s[3]+s[4])
sage: f[::2]
[s[2, 1, 1] + s[2, 2] + s[3, 1], s[3, 2, 1] + s[4, 1, 1] + s[4, 2] + s[5, 1]]

instead of a clumsy list with restrict_degree. More importantly, I'd love to know that this is uniform across graded algebras.

---

Last 10 new commits:

d75ac13	Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series
293b439	adapt doctests
8b6a752	no period at end of input description, break long doctest
f88a5c8	fix arithmetic product with 0 and finite support
89270eb	Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series
b76d8f4	allow to define lazy series using iterators, adapt doctest
4eb4dbd	fix behaviour of `__getitem__` for slices, provide missing doctests, minor simplifications in species directory
6f76b00	replace LazyTaylorSeriesRing and LazyTaylorSeries with LazyPowerSeriesRing and LazyPowerSeries and add appropriate deprecations
ac29928	Merge branch 'u/mantepse/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
b7d1b86	fix categories and add doctests

[mantepse]

Commit: b7d1b86

[sagetrac-git]

Changed commit from b7d1b86 to a742e36

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

a742e36

implement `_im_gens_`, part 1

[tscrim]

comment:10

Replying to Martin Rubey:

Shouldn't all of these actually be in GradedAlgebrasWithBasis? I have no idea what the consequences might be.

This I agree with overall, but Matthias made a good point that most of the default evaluation morphisms would not be as rings but as graded algebras, which have quite strong restrictions. There are ways around this for various special cases, but Hom(R, S) would still not default to the set of ring homomorphism, which would be strange for nearly all of commutative algebra. However, it should be allowed to be in GradedAlgebrasWithBasis() and work.

For the lazy graded algebras, that definitely should be in there.

However, it might be nice if, for any element of an integer graded algebra, __getitem__ would be defined as we just did for LazyModuleElement. I'd love to be able to type

sage: s = SymmetricFunctions(QQ).s()
sage: f = s[2,1]*(s[1]+s[2]+s[3]+s[4])
sage: f[::2]
[s[2, 1, 1] + s[2, 2] + s[3, 1], s[3, 2, 1] + s[4, 1, 1] + s[4, 2] + s[5, 1]]

instead of a clumsy list with restrict_degree. More importantly, I'd love to know that this is uniform across graded algebras.

Strong -1 on this for graded algebras in general because in CFM elements, f[i] should get the coefficient with index i. What happens when the indexing set contains integers? Slices also don’t make sense. Furthermore, implementations should be allowed to implement their own version of __getitem__, which might be useful for them.

We can support that for the lazy graded algebras, although from the above, it creates the same tension with something that should, generically speaking, act like the underlying algebra element. There is some justification for allowing the difference since the user should be aware that it is a completely different type. I didn’t quite think this through so thoroughly when we were first doing this… I see this as a judgement call with which behavior would be better to support, and I don’t have too strong of an opinion either way. (I might even be a bit contrarian either way you chose to make sure the choice is sound, but quite likely not.)

Somewhat related: There was an agreement to explicitly move away from allowing slices for (univariate) polynomials.

---

New commits:

a742e36

implement `_im_gens_`, part 1

[mantepse]

comment:11

Replying to Travis Scrimshaw:

However, it might be nice if, for any element of an integer graded algebra, __getitem__ would be defined as we just did for LazyModuleElement. I'd love to be able to type

sage: s = SymmetricFunctions(QQ).s()
sage: f = s[2,1]*(s[1]+s[2]+s[3]+s[4])
sage: f[::2]
[s[2, 1, 1] + s[2, 2] + s[3, 1], s[3, 2, 1] + s[4, 1, 1] + s[4, 2] + s[5, 1]]

instead of a clumsy list with restrict_degree. More importantly, I'd love to know that this is uniform across graded algebras.

Strong -1 on this for graded algebras in general because in CFM elements, f[i] should get the coefficient with index i. What happens when the indexing set contains integers? Slices also don’t make sense. Furthermore, implementations should be allowed to implement their own version of __getitem__, which might be useful for them.

OK, too bad. I could not think of a sensible example where the indices are integers, but I agree that there might be.

Could we at least have it for symmetric functions and similar stuff, interpreting integer and slice arguments as specifying degrees, and all the rest as indices? And, perhaps more importantly, for polynomials?

Somewhat related: There was an agreement to explicitly move away from allowing slices for (univariate) polynomials.

Yes, I find that this is a very impractical decision for me, because I work a lot with coefficients, and I keep forgetting how to obtain them. Doing list(p)[:5] seems extremely unintuitive for me.

Remembering stuff is even harder when implementations of basic functions are so different:

sage: R.<s,t> = PowerSeriesRing(ZZ); R
Multivariate Power Series Ring in s, t over Integer Ring
sage: f = 1 + t + s + s*t + R.O(3)
sage: f.coefficients()
{1: 1, s: 1, t: 1, s*t: 1}

[tscrim]

comment:12

Replying to Martin Rubey:

Replying to Travis Scrimshaw:

However, it might be nice if, for any element of an integer graded algebra, __getitem__ would be defined as we just did for LazyModuleElement. I'd love to be able to type

sage: s = SymmetricFunctions(QQ).s()
sage: f = s[2,1]*(s[1]+s[2]+s[3]+s[4])
sage: f[::2]
[s[2, 1, 1] + s[2, 2] + s[3, 1], s[3, 2, 1] + s[4, 1, 1] + s[4, 2] + s[5, 1]]

instead of a clumsy list with restrict_degree. More importantly, I'd love to know that this is uniform across graded algebras.

Strong -1 on this for graded algebras in general because in CFM elements, f[i] should get the coefficient with index i. What happens when the indexing set contains integers? Slices also don’t make sense. Furthermore, implementations should be allowed to implement their own version of __getitem__, which might be useful for them.

OK, too bad. I could not think of a sensible example where the indices are integers, but I agree that there might be.

The free monoid/group with one generator comes to mind. The exterior algebra is another if we realize subsets as binary representation of integers (this was originally the GSoC project Trevor was working on until we found it better to continue working with subsets through a different implementation).

Could we at least have it for symmetric functions and similar stuff, interpreting integer and slice arguments as specifying degrees, and all the rest as indices? And, perhaps more importantly, for polynomials?

I am a -1 on doing it for symmetric functions as they are not grouped together by degree like how the implementation is here. I also don’t like such a special case. In principle, considering the input f = s[2], the result of f[2] could support 1 and not 0. It doesn’t because it does not automatically cast the input. However, imagine the surprise if f[2] returned s[2] and not 1. (And doing it a second time _[2] returns 0 since 2 is not a partition and the syntactic sugar rush has ended.) This would be even more so for the above examples.

This is a good chunk of the reason why I am rethinking the behavior of __getitem__ for all lazy graded algebras. Yes, it is more work to type something like homogeneous_component, but at least it is explicit.

Somewhat related: There was an agreement to explicitly move away from allowing slices for (univariate) polynomials.

Yes, I find that this is a very impractical decision for me, because I work a lot with coefficients, and I keep forgetting how to obtain them. Doing list(p)[:5] seems extremely unintuitive for me.

Well, I would probably do [p[k] for k in range(5)] if no slicing was supported to not create a longer list than needed. Basically, my understanding of their decision was to not support slicing because there are too many natural things people would want/expect, so now you just have to be explicit about it. I am not sure how much I (currently) agree with their decision, but I can understand a few different logical arguments behind it.

Remembering stuff is even harder when implementations of basic functions are so different:

sage: R.<s,t> = PowerSeriesRing(ZZ); R
Multivariate Power Series Ring in s, t over Integer Ring
sage: f = 1 + t + s + s*t + R.O(3)
sage: f.coefficients()
{1: 1, s: 1, t: 1, s*t: 1}

Ouch, that is a bit unfortunate. It is generally a good thing to make the API uniform for these things.

[mantepse]

comment:13

OK, we disagree slightly. I guess there is nothing we can do about it, so let it be.

Just a few minor observations:

• Note that currently, __getitem__ of symmetric functions returns 0 when given an integer.

• For lazy series, homogeneous_component would just be yet another alias for __getitem__.

• Also, for a lazy series s we cannot do list(s)[a:b:c]. For power (Taylor) series, we could in principle do lazy_list(s), once lazy_list is imported, but for LazyLaurentSeries this does not work, because it would begin with degree 0.

In summary:

The fundamental problem I see is that there may be ZZ-graded algebras where the index set is a subset of the integers, but the degree is something else. I agree that this is a problem. I disagree that this is a problem for symmetric functions. The current behaviour of f[i] for a symmetric function f and an integer i is even more surprising but nobody has complained about it so far.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

0de1c13	add a warning and an example for the arithmetic product with a constant term
8e5de35	add missing whitespace in docstring
f706c53	Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series
af1de64	Merge branch 'u/mantepse/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
b028c4d	Merge branch 'u/mantepse/categories_of_lazy_series' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
3410eda	fix map_coefficients
8fc2dd1	fix doctests because of `__getitem__` change
2a3389e	compute no more elements than necessary in __getitem__
f687833	Merge branch 'u/mantepse/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
f7d7c4e	adapt doctests

[sagetrac-git]

Changed commit from a742e36 to f7d7c4e

[tscrim]

comment:15

Replying to Martin Rubey:

Just a few minor observations:

• Note that currently, __getitem__ of symmetric functions returns 0 when given an integer.

Indeed, it also returns 0 for things like x[2,1] for x = s[2,1] because it doesn’t actually convert things to a partition to check it.

• For lazy series, homogeneous_component would just be yet another alias for __getitem__.

That is fine (and even desirable) since it would make it compatible with other graded algebras (with basis).

• Also, for a lazy series s we cannot do list(s)[a:b:c]. For power (Taylor) series, we could in principle do lazy_list(s), once lazy_list is imported, but for LazyLaurentSeries this does not work, because it would begin with degree 0.

This is a good argument for adding functionality on top of those for the corresponding polynomial ring for at least the lazy Laurent )and Dirichlet) series. This would also be consistent with iteration over the elements too.

In summary:

The fundamental problem I see is that there may be ZZ-graded algebras where the index set is a subset of the integers, but the degree is something else. I agree that this is a problem. I disagree that this is a problem for symmetric functions. The current behaviour of f[i] for a symmetric function f and an integer i is even more surprising but nobody has complained about it so far.

It is initially surprising. Yet, you already have to know it is a way to pull coefficients of an indexed element, which means you should know it is not a partition that you are passing. Thus, with a moment of thought, it is consistent behavior (as the coefficient of the integer i is clearly 0).

I am okay with doing stuff for the lazy series since they are different objects/implementations, but not for classical symmetric functions. It creates too much tension with the __getitem__ behavior from CFM elements. You would not have list(x)[i] != x[i] for instance. There also is an issue for non-graded bases (say, if I implemented dual Grothendieck functions, something I want to do at some point) behaving very differently than the graded ones (a basis need not even be filtered).

[mantepse]

comment:16

Replying to Travis Scrimshaw:

• For lazy series, homogeneous_component would just be yet another alias for __getitem__.

That is fine (and even desirable) since it would make it compatible with other graded algebras (with basis).

Yes, provided that __getitem__ does not provide this functionality.

Let me stress that for my daily experimental work with sage, aliases are a major problem, because they are listed in the tab completion just as any other method. They even appear twice in the documentation. It happens very frequently that I am looking for a particular functionality, and cannot find it, so I page through the tab completion. As an example, for SymmetricFunctions(QQ).s(), this list has currently 148 elements, even if I remove the underscore methods.

'' (if you happen to know how to make emacs and sage-shell-mode (optionally) omit the underscore methods, please let me know)

Again, this is a major problem for me.

Related to this, less severe, is that tab-completion stops working after methods. So I have to assign names to things, and in the end I am surprised because I accidentally used the same name in a computation for two different things.

• Also, for a lazy series s we cannot do list(s)[a:b:c]. For power (Taylor) series, we could in principle do lazy_list(s), once lazy_list is imported, but for LazyLaurentSeries this does not work, because it would begin with degree 0.

This is a good argument for adding functionality on top of those for the corresponding polynomial ring for at least the lazy Laurent )and Dirichlet) series. This would also be consistent with iteration over the elements too.

I don't understand your proposal here? How would lazy_list(s) know the valuation?

There also is an issue for non-graded bases behaving very differently than the graded ones.

Hm, I don't see that: my proposal (modulo the fundamental problem of integer indices, which probably kills the proposal anyway) is exclusively for algebras with a ZZ-grading.

[mantepse]

comment:17

It is actually a bit strange that we do not include the x^n in the __getitem__ LazyLaurentSeries, univariate LazyPowerSeries and LazyDirichletSeries.

Similarly,

sage: s = SymmetricFunctions(QQ).s()
sage: L = LazySymmetricFunctions(s)
sage: (s[2,1]*s[2,1])[Partition([3,2,1])]
2
sage: L(s[2,1]*s[2,1])[Partition([3,2,1])]
TypeError

is actually quite inconsistent.

So, how about turning things around and make __getitem__ consistently pick out a single coefficient (no idea how to do this with multivariate polynomials, though), and improve restrict_degree and homogeneous_parts to give us the other thing.

Of course, this is a bit impractical, because for univariate power series I am not interested at all in the x^n, wheras for multivariate power series, I am only interested in the full graded piece.

[mantepse]

comment:18

I just realised that I am confusing two different instances of __getitem__:

• SymmetricFunctions(QQ).s().__getitem__, and

• SymmetricFunctions(QQ).s().an_element().__getitem__.

Clearly, the first one should only take partitions.

However, for the second, it might actually be more consistent, to only take integers and slices.

[tscrim]

comment:19

Replying to Martin Rubey:

Replying to Travis Scrimshaw:

• For lazy series, homogeneous_component would just be yet another alias for __getitem__.

That is fine (and even desirable) since it would make it compatible with other graded algebras (with basis).

Yes, provided that __getitem__ does not provide this functionality.

This would be a bad practice. We agree that things in the category should not assume that __getitem__ is implementing this, right? So if I write generic code at the category level that is using this property of being in the category, I need this method. We cannot remove such an alias (or redirection or code duplication) without breaking that.

Let me stress that for my daily experimental work with sage, aliases are a major problem, because they are listed in the tab completion just as any other method. They even appear twice in the documentation. It happens very frequently that I am looking for a particular functionality, and cannot find it, so I page through the tab completion. As an example, for SymmetricFunctions(QQ).s(), this list has currently 148 elements, even if I remove the underscore methods.

I agree that such pollution can be difficult at times. I usually know possible first letters, so that significantly narrows down my search (e.g., doing s.e<tab>). It would be nice to remove the duplicate documentation for aliases, but I don't think sphinx thinks its a priority for them.

'' (if you happen to know how to make emacs and sage-shell-mode (optionally) omit the underscore methods, please let me know)

Unfortunately I have no idea as I don't use emacs.

Again, this is a major problem for me.

I don't think there is too much anyone can do about this. It is better to have things discoverable by tab completion, and we want methods that are useful for other people to be included to.

Related to this, less severe, is that tab-completion stops working after methods. So I have to assign names to things, and in the end I am surprised because I accidentally used the same name in a computation for two different things.

I don't understand this. Do you mean it does not work for attributes? I have those intermingled in my tab completion lists.

• Also, for a lazy series s we cannot do list(s)[a:b:c]. For power (Taylor) series, we could in principle do lazy_list(s), once lazy_list is imported, but for LazyLaurentSeries this does not work, because it would begin with degree 0.

This is a good argument for adding functionality on top of those for the corresponding polynomial ring for at least the lazy Laurent (and Dirichlet) series. This would also be consistent with iteration over the elements too.

I don't understand your proposal here? How would lazy_list(s) know the valuation?

They don't, and that is a benefit to me. You don't fall into the pitfalls of the polynomials.

There also is an issue for non-graded bases behaving very differently than the graded ones.

Hm, I don't see that: my proposal (modulo the fundamental problem of integer indices, which probably kills the proposal anyway) is exclusively for algebras with a ZZ-grading.

I am focusing on just the symmetric function part now. The ring of symmetric functions has a ZZ-grading, but not every basis consists of homogeneous elements (i.e., is naturally ZZ-graded). What should I expect if I use a basis such as g[la] = s[la] + lower deg terms? It is a filtered basis of a graded algebra.

In particular, consider g[i] = s[i] for all positive integers i and g[1,1] = s[1,1] - s[1]. Then if x = g[1,1], then the degree 2 homogeneous component of x would be g[1,1] + g[1], which would be really strange for x[2]. If x[2] == g[1,1], then this would not be compatible with switching to the Schur basis. Or would it simply return 0? Or raise an error?

NB: Our implementation only works for graded bases.

[mantepse]

comment:20

Replying to Travis Scrimshaw:

I agree that such pollution can be difficult at times. I usually know possible first letters, so that significantly narrows down my search (e.g., doing s.e<tab>).

I miscommunicated. My problem is when I actually do not know whether some sort of functionality exists. For example, I'd like to get all elements of a given degree in a multivariate polynomial. So I do

sage: R.<x,y,z> = ZZ[]; f = R.an_element(); f.<tab>

Now, emacs offers me 97 methods. Fortunately, I can search in the list of completions, where I find degree, degrees, total_degree, weighted_degree. Those do not fit. I also notice truncate, monomials, and so on. With a lot of luck I will actually find homogeneous_components, buried among the other 96 methods.

I am not saying that this can be made much better easily. However, I am saying that this can be made much worse, by introducing more aliases. I am guessing that it would be extremely difficult for emacs to detect whether one method is an alias of another.

[mantepse]

comment:21

Replying to Travis Scrimshaw:

Hm, I don't see that: my proposal (modulo the fundamental problem of integer indices, which probably kills the proposal anyway) is exclusively for algebras with a ZZ-grading.

I am focusing on just the symmetric function part now. The ring of symmetric functions has a ZZ-grading, but not every basis consists of homogeneous elements (i.e., is naturally ZZ-graded). What should I expect if I use a basis such as g[la] = s[la] + lower deg terms? It is a filtered basis of a graded algebra.

In particular, consider g[i] = s[i] for all positive integers i and g[1,1] = s[1,1] - s[1]. Then if x = g[1,1], then the degree 2 homogeneous component of x would be g[1,1] + g[1], which would be really strange for x[2]. If x[2] == g[1,1], then this would not be compatible with switching to the Schur basis. Or would it simply return 0? Or raise an error?

Why would it be strange for x[2] to return g[1,1] + g[1]?

NB: Our implementation only works for graded bases.

Yes, I can think of some places where things might go wrong. Do you have an example in sage (or is there an easy way to define a basis) such that I can experiment?

[mantepse]

comment:22

Answering my own question:

sage: ht = SymmetricFunctions(QQ).ht()
sage: s = SymmetricFunctions(QQ).s()
sage: s(ht[2])
-s[1] + s[2]

is a basis which is not homogeneous. I am guessing that there is some trouble here:

sage: ht[2].homogeneous_degree()
2
sage: s(ht[2]).homogeneous_degree()
ValueError
sage: (ht[1] + ht[2]).homogeneous_degree()
ValueError
sage: s(ht[1] + ht[2]).homogeneous_degree()
2

[tscrim]

comment:82

Ah, right, we do use the graded property. In fact, we even need it: it an algebra was (lower) filtered, we could have accumulation in the constant coefficient.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

ddc04a1

Fixing last pyflakes things.

[sagetrac-git]

Changed commit from e077b66 to ddc04a1

[tscrim]

comment:85

Patchbot here was morally green (something seems broken with its giac and unrelated to this ticket) up to the pyflakes things I just fixed.

I think anything further can be done on subsequent tickets and we are at a good cutoff point. If you're happy as well, we feel free to set a positive review.

[tscrim]

comment:87

This has no additional conflict with the changes I made in #34413.

[mantepse]

Changed branch from u/tscrim/categories_lazy_series-34470 to u/mantepse/categories_lazy_series-34470

[sagetrac-git]

Changed commit from ddc04a1 to 41ca99b

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. Last 10 new commits:

97df300	Updating sf/sfa.py doctest due to #34494.
1388b8a	Merge branch 'u/chapoton/34494' of https://github.com/sagemath/sagetrac-mirror into public/rings/lazy_series_revert-34383
7bfe5f7	Merge branch 'public/rings/lazy_series_revert-34383' of https://github.com/sagemath/sagetrac-mirror into public/rings/lazy_series_revert-34383
2039990	Updating doctest due to changes from #34494.
cdea820	Merge branch 'public/rings/lazy_series_revert-34383' of https://github.com/sagemath/sagetrac-mirror into u/tscrim/derivatives_lazy_series-34413
b7f04ed	Merge branch 'develop' of trac.sagemath.org:sage into t/34413/derivatives_lazy_series-34413
2325826	Merge branch 'u/mantepse/derivatives_lazy_series-34413' of trac.sagemath.org:sage into t/34422/implement_functorial_composition_of_lazy_symmetric_functiosn
ebcf5c3	Merge branch 'u/mantepse/implement_functorial_composition_of_lazy_symmetric_functiosn' of trac.sagemath.org:sage into t/34423/implement_arithmetic_product_of_lazy_symmetric_functions
4172688	Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series-32367
41ca99b	Merge branch 'u/mantepse/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series-34470

[mantepse]

comment:90

trivial (automatic) merge, necessary to make the patchbots happy.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

67dff95	Merge branch 'develop' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series-32367
4fc981b	fix for pyflakes and blocks
56cef07	Merge branch 'u/mantepse/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series-34470

[sagetrac-git]

Changed commit from 41ca99b to 56cef07

[mantepse]

comment:92

Trivial merge, done because I keep switching between 9.8.beta0 and 9.8.beta1, which is a waste of time.

[vbraun]

Changed branch from u/mantepse/categories_lazy_series-34470 to 56cef07