Opened 5 months ago
Closed 4 months ago
#34470 closed defect (fixed)
categories of lazy series
Reported by:  mantepse  Owned by:  

Priority:  major  Milestone:  sage9.8 
Component:  categories  Keywords:  LazyPowerSeries 
Cc:  tscrim  Merged in:  
Authors:  Martin Rubey  Reviewers:  Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  56cef07 (Commits, GitHub, GitLab)  Commit:  56cef070ebee69841f1ead61344557d10d0b56a0 
Dependencies:  #32367  Stopgaps: 
Description (last modified by )
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.
Change History (94)
comment:1 Changed 5 months ago by
Cc:  tscrim added 

Component:  PLEASE CHANGE → categories 
Keywords:  LazyPowerSeries added 
Type:  PLEASE CHANGE → defect 
comment:2 Changed 5 months ago by
Description:  modified (diff) 

comment:3 Changed 5 months ago by
comment:4 Changed 5 months ago by
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)
comment:5 Changed 5 months ago by
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.
comment:6 Changed 5 months ago by
Authors:  → Martin Rubey 

Dependencies:  → #32367 
comment:7 Changed 5 months ago by
Branch:  → u/mantepse/categories_of_lazy_series 

comment:8 followup: 10 Changed 5 months ago by
Commit:  → b7d1b867793601ac3108944231dde2175234eba9 

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

comment:9 Changed 5 months ago by
Commit:  b7d1b867793601ac3108944231dde2175234eba9 → a742e36ca720f6eb22be9d8a4c309f0c2ae00082 

Branch pushed to git repo; I updated commit sha1. New commits:
a742e36  implement _im_gens_, part 1

comment:10 followup: 11 Changed 5 months ago by
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 forLazyModuleElement
. I'd love to be able to typesage: 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

comment:11 followup: 12 Changed 5 months ago by
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 forLazyModuleElement
. I'd love to be able to typesage: 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 indexi
. 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}
comment:12 Changed 5 months ago by
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 forLazyModuleElement
. I'd love to be able to typesage: 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 indexi
. 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.
comment:13 followup: 15 Changed 5 months ago by
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 dolist(s)[a:b:c]
. For power (Taylor) series, we could in principle dolazy_list(s)
, oncelazy_list
is imported, but forLazyLaurentSeries
this does not work, because it would begin with degree 0.
In summary:
The fundamental problem I see is that there may be ZZgraded 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.
comment:14 Changed 5 months ago by
Commit:  a742e36ca720f6eb22be9d8a4c309f0c2ae00082 → f7d7c4e1cd2f7d5218471e34b3535549363864cf 

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

comment:15 followup: 16 Changed 5 months ago by
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 dolist(s)[a:b:c]
. For power (Taylor) series, we could in principle dolazy_list(s)
, oncelazy_list
is imported, but forLazyLaurentSeries
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 ZZgraded 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 functionf
and an integeri
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 nongraded 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).
comment:16 followup: 19 Changed 5 months ago by
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 sageshellmode (optionally) omit the underscore methods, please let me know)
Again, this is a major problem for me.
Related to this, less severe, is that tabcompletion 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 dolist(s)[a:b:c]
. For power (Taylor) series, we could in principle dolazy_list(s)
, oncelazy_list
is imported, but forLazyLaurentSeries
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 nongraded 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 ZZgrading.
comment:17 Changed 5 months ago by
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.
comment:18 Changed 5 months ago by
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.
comment:19 followups: 20 21 Changed 5 months ago by
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 sageshellmode (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 tabcompletion 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 dolist(s)[a:b:c]
. For power (Taylor) series, we could in principle dolazy_list(s)
, oncelazy_list
is imported, but forLazyLaurentSeries
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 nongraded 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 ZZgrading.
I am focusing on just the symmetric function part now. The ring of symmetric functions has a ZZgrading, but not every basis consists of homogeneous elements (i.e., is naturally ZZgraded). 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.
comment:20 followup: 23 Changed 5 months ago by
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.
comment:21 followup: 24 Changed 5 months ago by
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 ZZgrading.
I am focusing on just the symmetric function part now. The ring of symmetric functions has a ZZgrading, but not every basis consists of homogeneous elements (i.e., is naturally ZZgraded). 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 integersi
andg[1,1] = s[1,1]  s[1]
. Then ifx = g[1,1]
, then the degree 2 homogeneous component ofx
would beg[1,1] + g[1]
, which would be really strange forx[2]
. Ifx[2] == g[1,1]
, then this would not be compatible with switching to the Schur basis. Or would it simply return0
? 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?
comment:22 Changed 5 months ago by
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
comment:23 Changed 5 months ago by
Replying to Martin Rubey:
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 noticetruncate
,monomials
, and so on. With a lot of luck I will actually findhomogeneous_components
, buried among the other 96 methods.
I see. We might need some better classlevel documentation or more tutorials. If I couldn’t immediately find it by tab completion, I might then go to the doc for the class and skim through its methods, and then up through the categories. Although I think I quickly realize certain large chunks of the tab completion available methods can be ignored because I know they are not what I want.
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.
Indeed, we should be careful to not overpopulate any namespace. Yet, we generally cannot keep it so small.
Detecting when a method is an alias of another is easy I think, just check the address of the method:
sage: class Foo: ....: def bar(x): ....: return x + 5 ....: baz = bar sage: Foo.bar is Foo.baz True
However, the question is which one to keep. The alias sometimes can be the one you will actually recognize (e.g., same function but different names coming from different fields).
comment:24 Changed 5 months ago by
Replying to Martin Rubey:
Replying to Travis Scrimshaw:
In particular, consider
g[i] = s[i]
for all positive integersi
andg[1,1] = s[1,1]  s[1]
. Then ifx = g[1,1]
, then the degree 2 homogeneous component ofx
would beg[1,1] + g[1]
, which would be really strange forx[2]
. Ifx[2] == g[1,1]
, then this would not be compatible with switching to the Schur basis. Or would it simply return0
? Or raise an error?Why would it be strange for
x[2]
to returng[1,1] + g[1]
?
It is returning something that is not obviously homogeneous, and you get more terms than before. I guess for filtered algebras you can make it be “up to degree i,” which is how we define degree for filtered: the smallest filtered piece something belongs to. Although using that, slices do not make sense.
comment:25 Changed 5 months ago by
Yes. I was just about to send the following, before you answered :)
Apparently, I misunderstood the notion of homogeneous component in a filtered algebra, at least if I follow FilteredModulesWithBasis
. In your example, g[1,1] + g[1]
would not be considered homogeneous. In fact, right now it seems to me that it is not possible to define "homogeneous element" other than depending on a basis.
comment:26 Changed 5 months ago by
sorry, I meant "homogeneous component", not "homogeneous element".
comment:27 Changed 5 months ago by
It is perhaps slightly nonstandard notion of degree and homogeneous, but we wanted to make filtered and graded stuff behave somewhat uniformly/consistently.
comment:28 Changed 5 months ago by
Commit:  f7d7c4e1cd2f7d5218471e34b3535549363864cf → 90e2c2178f6418cc6a6c9cbd40a4d8de2e18b376 

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
c90cb91  Merge branch 'u/mantepse/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series' of https://github.com/sagemath/sagetracmirror into u/tscrim/replace_lazy_power_series32367

3bd9f8c  Fixing coefficients bug and some doc tweaks.

555d1b0  fix LazyPowerSeries._element_constructor_ when passed a function

baea68d  pass functions using coefficients to element constructor

7745337  remove unused variable detected by pyflakes

cdad494  do not advertise L(None) in favour of L.define()

e8c7636  advertise passing None to the constructor

f541f3d  add links to relaxed padics

1df62c8  fix wrong ring in doctest

90e2c21  Merge branch 'u/mantepse/replace_lazy_power_series32367' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series

comment:29 Changed 5 months ago by
I just noticed that it would be great to absorb the two check
functions in the TESTS
section, line 103ff of lazy_ring.py
into the TestSuite
framework, but I do not know how to do this.
sage: L = LazyPowerSeriesRing(ZZ, 't, s') sage: L.some_elements() [1 + 1 + 1 + 1 + O(t,s)^5]
is a bad bug. Most of the some_elements
methods return a very poor selection.
sage: LazyDirichletSeriesRing(ZZ, 't, s') Lazy Dirichlet Series Ring in t over Integer Ring
is a bit surprising.
comment:30 Changed 5 months ago by
I will respond in more detail and to the other ticket when I get back after dinner.
To add to the TestSuite
, you just need to name a function _test_foo
.
The result of some_elements()
generally needs a bit of human intervention.
comment:31 Changed 5 months ago by
Just let me know what I should implement, so we don't tread on each others toes.
comment:32 Changed 5 months ago by
I spent basically no time doing what I did. Feel free to go ahead and do what you want/need to do. I can just cherrypick stuff as necessary.
BTW  the controversial stuff here is the UFD category part.
comment:33 followup: 34 Changed 5 months ago by
OK, I am going to spend one more afternoon on this. I'll try to put everything in different commits as much as seems reasonable. It would be great however, if you could point out which patchbot was failing on #32367.
comment:34 Changed 5 months ago by
Replying to Martin Rubey:
OK, I am going to spend one more afternoon on this. I'll try to put everything in different commits as much as seems reasonable. It would be great however, if you could point out which patchbot was failing on #32367.
I just did a moment ago. I also pushed my changes and cherrypicked the _im_gens_
there too.
comment:35 Changed 5 months ago by
Commit:  90e2c2178f6418cc6a6c9cbd40a4d8de2e18b376 → e3e331c49b9a464abd3d37b03e72a3a6dfdf8f51 

Branch pushed to git repo; I updated commit sha1. New commits:
23d951f  Doing some reviewer changes.

6a3559e  Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of https://github.com/sagemath/sagetracmirror into public/lazy_series/dvr_methodsTBA

6969549  Implementing methods for DVF.

91244f3  Merge branch 'public/lazy_series/dvr_methodsTBA' into u/tscrim/replace_lazy_power_series32367

0a8b4c6  implement _im_gens_, part 1

380ddc9  adapt doctests

69d44ab  Removing old use of LazyTaylorSeriesRing from my changes.

de6f16e  Merge branch 'u/tscrim/replace_lazy_power_series32367' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series

e3e331c  add and correct some_elements for all rings, run all tests in the TestSuite (many fail)

comment:36 Changed 5 months ago by
Hurray, I actually found a real bug in the comparison of 'exact' series :)
comment:37 Changed 5 months ago by
Commit:  e3e331c49b9a464abd3d37b03e72a3a6dfdf8f51 → 00aaca080f0be83e5cede0970a035dc084923596 

Branch pushed to git repo; I updated commit sha1. New commits:
00aaca0  introduce halting precision

comment:38 followup: 60 Changed 5 months ago by
Commit:  00aaca080f0be83e5cede0970a035dc084923596 → f9dd62e7b9db93db213eb4d8b10e7e1f77920a5d 

Branch pushed to git repo; I updated commit sha1. New commits:
f9dd62e  fix equality of exact series, do not produce coefficients of polynomials by iterating over them

comment:39 Changed 5 months ago by
Commit:  f9dd62e7b9db93db213eb4d8b10e7e1f77920a5d → b9a66bed5b72672327ad1335461fe0833f11a0b5 

Branch pushed to git repo; I updated commit sha1. New commits:
b9a66be  implement missing required method lift_to_precision

comment:40 Changed 5 months ago by
Commit:  b9a66bed5b72672327ad1335461fe0833f11a0b5 → 88109cc334038473f7ef9d6318a64fea4a8e5456 

Branch pushed to git repo; I updated commit sha1. New commits:
88109cc  fix precision also in species directory, do not forget to switch it off after doctest

comment:41 Changed 5 months ago by
Status:  new → needs_review 

comment:42 Changed 5 months ago by
Good catch. Although I am wondering how much more complicated equality becomes if we do not insist. I will try to take a look today, and if not, then tomorrow.
Also
 TESTS: + TESTS:: sage: L.<t> = LazyPowerSeriesRing(QQ)
comment:43 followup: 47 Changed 5 months ago by
I actually think now that it is better this way. We probably don't gain anything by postponing. In any case it is premature optimization.
comment:44 Changed 5 months ago by
Commit:  88109cc334038473f7ef9d6318a64fea4a8e5456 → 08baf9a88210fee39bb5dd84064adddf7d1365e6 

Branch pushed to git repo; I updated commit sha1. New commits:
08baf9a  fix punctuation in docstrings

comment:45 followup: 48 Changed 5 months ago by
Some more lowhanging fruits, possibly for other tickets:
 move the two checks in the global
TESTS:
section oflazy_series.py
to theTestSuite
framework. The padics people have some very nice tests, by the way. I wonder why there is no generic test of division in the category framework, or did I overlook it? Possibly related: #17965
 implement
some_elements
for the graded completion, and think of better_an_element
andsome_elements
in general. Currently, most examples are 'exact'. Why isan_element
ofZZ
just1
, the is not a very typical element.
 Stream_cauchy_compose and Stream_plethysm have some similarities, maybe we can make them more obvious.
 there are some nonlazy sums of the form
sum(a[i]*b[i] for i in ...)
instream.py
. These should possibly be replaced by something likes = zero for i in ...: left = a[i] if left: s += left * b[i]
(not only for performance, but also we should not evaluate
b[i]
when we shouldn't, even if this makes the sum asymmetric). This should be a helper function
 the testsuites now give us a very rough performance measure, maybe we can exploit that
 I vaguely remember that somewhere in
lazy_series.py
I had to be careful when trying to detect a geometric series. This should be easier now.
comment:46 Changed 5 months ago by
I just noticed in discrete_valuation.py
def super_categories(self): """ EXAMPLES:: sage: DiscreteValuationRings().super_categories() [Category of euclidean domains] """ return [EuclideanDomains()]
shouldn't that be PrincipalIdealDomains()
, according to https://en.wikipedia.org/wiki/Discrete_valuation_ring?
comment:47 Changed 5 months ago by
Replying to Martin Rubey:
I actually think now that it is better this way. We probably don't gain anything by postponing. In any case it is premature optimization.
+1 It is an implementation detail that we can easily change later on.
comment:48 Changed 5 months ago by
Replying to Martin Rubey:
Some more lowhanging fruits, possibly for other tickets:
 move the two checks in the global
TESTS:
section oflazy_series.py
to theTestSuite
framework. The padics people have some very nice tests, by the way. I wonder why there is no generic test of division in the category framework, or did I overlook it? Possibly related: #17965
Division is not guaranteed except in Fields
, so it doesn’t make sense to test it in any more general category. However, I don’t think there are any such tests.
 implement
some_elements
for the graded completion, and think of better_an_element
andsome_elements
in general. Currently, most examples are 'exact'. Why isan_element
ofZZ
just1
, the is not a very typical element.
The result of an_element()
doesn’t need to be so generic. Beyond an example, it is used by the coercion framework for setting things up via the generic coercion map using _element_constructor_
.
 Stream_cauchy_compose and Stream_plethysm have some similarities, maybe we can make them more obvious.
+1 Probably good place for subclassing.
 there are some nonlazy sums of the form
sum(a[i]*b[i] for i in ...)
instream.py
. These should possibly be replaced by something likes = zero for i in ...: left = a[i] if left: s += left * b[i](not only for performance, but also we should not evaluate
b[i]
when we shouldn't, even if this makes the sum asymmetric). This should be a helper function
Sounds good overall. I might need to see details before a final verdict, but I think it should be good.
 the testsuites now give us a very rough performance measure, maybe we can exploit that
Indeed.
 I vaguely remember that somewhere in
lazy_series.py
I had to be careful when trying to detect a geometric series. This should be easier now.
Great! I think this was with exact series in some way. I don’t remember exactly, but I also recall something like that.
comment:49 Changed 5 months ago by
Commit:  08baf9a88210fee39bb5dd84064adddf7d1365e6 → 5bd0331f4210eb4c76eca6bc8b28331931443117 

Branch pushed to git repo; I updated commit sha1. New commits:
5bd0331  correct an_element and some_elements, implement is_unit, _test_invert

comment:50 Changed 5 months ago by
I did a few more corrections (in fact, I overlooked the wrong _an_element in my previous commit).
Unfortunately, I really should stop now.
If there is anything which absolutely needs to be done for positive review, please let me know. Otherwise, I'd like to move the remaining stuff into new tickets.
comment:51 Changed 5 months ago by
One thing I would really like to see is an attempt to make a positive valuation element for some_elements
of the LazyCompletionGradedAlgebra
:
it = iter(self._laurent_poly_ring.basis()) extra_elt = sum(b for _ in range(4) if (b := next(it)).degree()) if extra_elt: elts.append(extra_elt)
Of course, if the graded algebra is "trivial" with everything in degree 0, this won't get anything (or if the first few basis elements are all degree 0). So we just need to protect against that.
Other than that, I think we should bring this these into UFDs where appropriate. That way we signal the correct mathematical information, and the functions that want the constructive behavior will fail with either an AttributeError
or a NotImplementedError
.
Actually, FPS in a single variable are a Euclidean domain (see this MSE post): The Euclidean algorithm uses the valuation and works as follows:
For f(x) / g(x), we want to consider f(x) = q(x) g(x) + r(x). Define F(x) by x^{val(f)} F(x) = f(x) and similarly G(x) using g(x). This breaks up into 2 cases:
 If val(f) >= val(g), we have f(x) / g(x) = x^{val(f)  val(g)} F(x) / G(x).
 If val(f) < val(g), then we have q(x) = 0 and r(x) = f(x). Then we proceed with the Euclidean algorithm.
For this implementation, we can simply in the __init__
make self.euclidean_degree = self.valuation
. This would also become a simple quo_rem
function.
Furthermore, this gives me an idea for doing the GCD. Let f(X) = d_{f}(X) F(X), where F(X) is a unit and d_{f}(X) is the lowest degree portion of f(X); similarly for g(X). Then, we have
gcd(f(X), g(X)) = gcd(d_{f}(X)F(X), d_{g}(X)G(X)) = gcd(d_{f}(X), d_{g}(X))
This would then be very easy to implement. I can do this tomorrow if you don't want to do it.
Once we do this, this we achieve the actual stated goal of the ticket. :P
comment:52 Changed 5 months ago by
Commit:  5bd0331f4210eb4c76eca6bc8b28331931443117 → 1722eca9a24029683fd137eda0fbc063cd044fad 

Branch pushed to git repo; I updated commit sha1. New commits:
1722eca  fix is_unit

comment:54 Changed 5 months ago by
The following would make our test suite run *much* faster.
diff git a/src/sage/libs/lrcalc/lrcalc.py b/src/sage/libs/lrcalc/lrcalc.py index b541bfacd89..1bfaba4ec14 100644  a/src/sage/libs/lrcalc/lrcalc.py +++ b/src/sage/libs/lrcalc/lrcalc.py @@ 202,7 +202,7 @@ def _lrcalc_dict_to_sage(result): sage: mult([2,1],[3,2,1],3) # indirect doctest {[3, 3, 3]: 1, [4, 3, 2]: 2, [4, 4, 1]: 1, [5, 2, 2]: 1, [5, 3, 1]: 1} """  return {_Partitions(la): Integer(k) for la, k in result.items()} + return {_Partitions.element_class(_Partitions, la): Integer(k) for la, k in result.items()} def lrcoef_unsafe(outer, inner1, inner2): r"""
comment:55 Changed 5 months ago by
Indeed, and much better is_unit
tests. :)
+1 for comment:54; this avoids some checks IIRC.
I am not sure for comment:46 in light of comment:51. I am not immediately sure if the valuation always defines a Euclidean function, but I am thinking it does. Although we might not be able to do a generic implementation as everything depends on quo_rem
and there might be other (and better) Euclidean functions.
comment:57 Changed 5 months ago by
Commit:  1722eca9a24029683fd137eda0fbc063cd044fad → cdf821a895d6c4ed46992d209cb5cdfbb6ae6d39 

Branch pushed to git repo; I updated commit sha1. New commits:
cdf821a  improve equality, raise errors when trying to invert series which are known not to be invertible, be more careful not to compute terms

comment:58 Changed 5 months ago by
Thanks.
Unfortunately what I said about the gcd proof is false. We cannot simply factor out the lowest term like that. Consider f(x,y) = x + y + HOT
, but we can only span a 2 dimensional subspace of span{x^2, xy, y^2}
for any given unit. This discrepancy only gets worse for higher degrees. Thus, there exists elements in Rx,y? / U, where U is the group of units, whose representatives are always infinite sums.
We might be able to do something using something in this article, but it seems a bit involved.
Perhaps it is best to leave the UFD separate for now.
comment:59 Changed 5 months ago by
Yes, please! I'd really like to have factorization, but more than that I'd like to have the current branch in develop.
I tried to find some facts concerning formal Dirichlet series. What I found would be the diff below. However, I do not want to hold up this ticket any longer. So I'd rather include it in a later ticket. I suggest that we document your findings there, also.

src/sage/rings/lazy_series_ring.py
diff git a/src/sage/rings/lazy_series_ring.py b/src/sage/rings/lazy_series_ring.py index ca2ccf29f2c..a3dcd136aa2 100644
a b class LazySeriesRing(UniqueRepresentation, Parent): 763 763 764 764 EXAMPLES:: 765 765 766 sage: Zp(3)._test_invert() 766 sage: L = LazyLaurentSeriesRing(QQ, 'z') 767 sage: L._test_invert() 767 768 768 769 .. SEEALSO:: 769 770 … … class LazyDirichletSeriesRing(LazySeriesRing): 2175 2176 Element = LazyDirichletSeries 2176 2177 2177 2178 def __init__(self, base_ring, names, sparse=True, category=None): 2178 """2179 r""" 2179 2180 Initialize the ring. 2180 2181 2181 2182 TESTS:: … … class LazyDirichletSeriesRing(LazySeriesRing): 2198 2199 sage: L in PrincipalIdealDomains 2199 2200 False 2200 2201 2201 In particular, it is not a :wikipedia:`discrete_valuation_ring`. 2202 In particular, it is not a 2203 :wikipedia:`discrete_valuation_ring`. On the other hand, it 2204 is a :wikipedia:`local_ring`. The unique maximal ideal 2205 consists of all noninvertible series, i.e., series with 2206 vanishing constant term. 2202 2207 2203 2208 .. TODO:: 2204 2209 2205 2210 According to the answers in 2206 2211 https://mathoverflow.net/questions/5522/dirichletserieswithintegercoefficientsasaufd, 2207 2212 the ring of formal Dirichlet series is actually a 2208 UniqueFactorizationDomain. 2213 :wikipedia:`Unique_factorization_domain`. 2214 2215 .. NOTE:: 2216 2217 An interesting valuation is described in Emil Daniel 2218 Schwab; Gheorghe Silberberg A note on some discrete 2219 valuation rings of arithmetical functions Archivum 2220 Mathematicum, Vol. 36 (2000), No. 2, 103109, 2221 http://dml.cz/dmlcz/107723. Let `J_k` be the ideal of 2222 Dirichlet series whose coefficient `f[n]` of `n^s` 2223 vanishes if `n` has less than `k` prime factors, counting 2224 multiplicities. For any Dirichlet series `f`, let `D(f)` 2225 be the largest integer `k` such that `f` is in `J_k`. 2226 Then `D` is surjective, `D(f g) = D(f) + D(g)` for 2227 nonzero `f` and `g`, and `D(f + g) \geq \min(D(f), D(g))` 2228 provided that `f + g` is nonzero. 2229 2230 For example, `J_1` are series with no constant term, and 2231 `J_2` are series such that `f[1]` and `f[p]` for prime 2232 `p` vanish. 2233 2234 Since this is a chain of increasing ideals, the ring of 2235 formal Dirichlet series is not a 2236 :wikipedia:`Noetherian_ring`. 2237 2238 Evidently, this valuation cannot be computed for a given 2239 series. 2240 2209 2241 """ 2210 2242 if base_ring.characteristic() > 0: 2211 2243 raise ValueError("positive characteristic not allowed for Dirichlet series")
comment:60 Changed 5 months ago by
comment:61 Changed 5 months ago by
Commit:  cdf821a895d6c4ed46992d209cb5cdfbb6ae6d39 → fbccb39ebef9bf107463c9955c8f254aa1dfe685 

Branch pushed to git repo; I updated commit sha1. New commits:
fbccb39  normalize degree in Stream_exact for correct equality

comment:62 Changed 5 months ago by
Branch:  u/mantepse/categories_of_lazy_series → u/tscrim/categories_lazy_series34470 

Commit:  fbccb39ebef9bf107463c9955c8f254aa1dfe685 → b930f58d4fcece6371e14d2aba6fc53e653c24b1 
Reviewers:  → Travis Scrimshaw 
I found a number of additional bugs from some additional test suites to test the different categories. I will have more changes, but now I really need to go to bed. It took me much longer than it should have to find the bad equality test that stemmed from not converting the coefficients to the base ring in _an_element_
.
New commits:
3d5b8cf  Last little things from the patchbot.

aa593b5  Merge branch 'u/mantepse/categories_of_lazy_series' of https://github.com/sagemath/sagetracmirror into u/tscrim/categories_lazy_series34470

840539d  More tests, more bugs fixed.

b930f58  Merge branch 'u/mantepse/categories_of_lazy_series' of https://github.com/sagemath/sagetracmirror into u/tscrim/categories_lazy_series34470

comment:63 Changed 5 months ago by
I'm sorry about that, I fixed the same bug independently (and it took me a very long time, too). Unfortunately, I did this in #34552.
comment:65 Changed 5 months ago by
Commit:  b930f58d4fcece6371e14d2aba6fc53e653c24b1 → b47407b38c76f7cc6f58777bf8d6cf5feb19d4f5 

Branch pushed to git repo; I updated commit sha1. New commits:
b47407b  Implementing _floordiv_, Stream._true_order to boolean, first fraction field, more tests, marking long tests.

comment:66 followup: 67 Changed 5 months ago by
Travis, do you know already why this branch is failing tests in the species directory?
New commits:
b47407b  Implementing _floordiv_, Stream._true_order to boolean, first fraction field, more tests, marking long tests.

comment:67 Changed 5 months ago by
Replying to Martin Rubey:
Travis, do you know already why this branch is failing tests in the species directory?
No, I don't. I haven't been testing that directory. Let me do so right now.
comment:68 Changed 5 months ago by
In the branch I just pushed, I made some changes:
 I fixed a major bug with the
UniqueRepresentation
.  I changed
_true_order
to be a boolean as I felt there was no reason to duplicate the approximate and actual orders (now they can't get out of sync).  I made the
R[[x]]
fraction fieldR((x))
whenR
is a field.  Implemented
f // g
generically. It won't necessarily fail outright if it cannot work as it has to actually try to do the normal division.  I marked some tests as
# long time
as they were taking nearly 2 seconds on my (8 year old) laptop.  I brought in your doc in comment:59.
Next to figure out what is going wrong with the species.
comment:69 Changed 5 months ago by
Ah, I know why: I am dynamically setting the Element
attribute of the FPS based on the input ring.
comment:70 Changed 5 months ago by
Oh wow, you did a lot of work!
I fixed a few bugs also in #34552, so I think it would be prudent not to increase the scope of this branch.
comment:71 Changed 5 months ago by
Also, just as a heads up, I will eventually want to make things in __invert__
and revert
fully lazy, see the todo notes in #34552.
Finally: I wanted to introduce something simlilar to LazyPowerSeries_gcd
for revert
and compose
, except that I only need it for the testsuite. Maybe there is a more structured way?
comment:72 Changed 5 months ago by
Commit:  b47407b38c76f7cc6f58777bf8d6cf5feb19d4f5 → e077b6655df290286c71404f4756babc97965f24 

Branch pushed to git repo; I updated commit sha1. New commits:
e077b66  Using dynamic classes for FPS gcd.

comment:73 Changed 5 months ago by
Here is the fix for species.
I decided to do the mixin approach for FPS (in contrast to FLS) since it is more specialized code. I could simply move [x]gcd
to the LazyPowerSeries
class and add checks to error out when invalid. This gets rid of the dynamic class, but they will always appear (where we have less understanding, even over Z as I understand it). Your choice.
comment:74 Changed 5 months ago by
Also +1 for cutting this ticket off and moving on to #34552 for additional changes.
comment:75 Changed 5 months ago by
Sorry, I don't understand enough of mixin, please decide yourself.
Just an explanation (no need to change anything now) for my seemingly weird true_order
duplicating approximate_order
. The idea (I don't know yet whether it was good or not) was as follows:
true_order
could be used in places where we currently use approximate_order
, and sometimes even without checking. However, if we make a mistake, and true_order
is actually not yet set, we would be told by the exception that would be raised (because we cannot compute with None
).
comment:76 Changed 5 months ago by
#32367 is not positive review, by the way. Is something missing there, or do you want to make them positive all at once?
comment:77 Changed 5 months ago by
Shall we somehow notify Volker that it is only necessary to merge the top ticket (which will be either this one or #34552)?
comment:78 Changed 5 months ago by
Then let’s leave it as is.
I see. We could go back to doing _true_order
being an (extended?) integer then. It is unlikely that they do get out of sync, but some care might be needed, especially with the _element_constructor_
. We should note this reasoning somewhere in either a code or regular doc comment.
#32367 is just waiting for a green patchbot. If you want to run all tests and build the doc to verify my changes are good, then you can set a positive review as well.
The whole sequence of tickets will be merged. We have set them up so they merge cleanly. There is nothing we need to worry about for that.
comment:79 Changed 5 months ago by
OK. I thought the github patchbot is enough.
Concerning _true_order_
: once the dust has settled, I might work on #34553 and check whether it is overall better to improve _approximate_order_
in Stream_inexact.__getitem__
. I am quite sure it is, but I'd like to have a good testsuite first. So, currently it's premature optimization.
I was thinking about my very original goal, extending species to the multivariate setting. Possibly it makes sense to regard them as a graded algebra. They have a basis (see https://en.wikipedia.org/wiki/Burnside_ring), but usually we do not want to compute in this basis, and only use the grading.
comment:80 Changed 5 months ago by
There are mechanisms in Sage to have a basis in a graded algebra that is not graded (or even filtered). I guess in some way, as long as we have a way to separate elements of the ring into graded pieces, we can use the LazyCompletionSeries
. Actually, in that way this would work for filtered algebras as well (with the generalized definition of homogeneous).
comment:81 Changed 5 months ago by
I actually think that having a graded algebra with a nongraded basis, but using the "generalized" definition of graded is going to be problematic, because our product assumes that it knows in which graded piece it is.
But let's see when we get there.
comment:82 Changed 5 months ago by
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.
comment:83 Changed 5 months ago by
Milestone:  sage9.7 → sage9.8 

comment:84 Changed 5 months ago by
Commit:  e077b6655df290286c71404f4756babc97965f24 → ddc04a1a02b26270a89be3a2a56a193d6d794b42 

Branch pushed to git repo; I updated commit sha1. New commits:
ddc04a1  Fixing last pyflakes things.

comment:85 Changed 5 months ago by
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.
comment:86 Changed 5 months ago by
Status:  needs_review → positive_review 

comment:87 Changed 5 months ago by
This has no additional conflict with the changes I made in #34413.
comment:88 Changed 4 months ago by
Branch:  u/tscrim/categories_lazy_series34470 → u/mantepse/categories_lazy_series34470 

comment:89 Changed 4 months ago by
Commit:  ddc04a1a02b26270a89be3a2a56a193d6d794b42 → 41ca99b7bfee0c11c4ece0bffa0b9230a7b4f67b 

Status:  positive_review → needs_review 
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/sagetracmirror into public/rings/lazy_series_revert34383

7bfe5f7  Merge branch 'public/rings/lazy_series_revert34383' of https://github.com/sagemath/sagetracmirror into public/rings/lazy_series_revert34383

2039990  Updating doctest due to changes from #34494.

cdea820  Merge branch 'public/rings/lazy_series_revert34383' of https://github.com/sagemath/sagetracmirror into u/tscrim/derivatives_lazy_series34413

b7f04ed  Merge branch 'develop' of trac.sagemath.org:sage into t/34413/derivatives_lazy_series34413

2325826  Merge branch 'u/mantepse/derivatives_lazy_series34413' 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_series32367

41ca99b  Merge branch 'u/mantepse/replace_lazy_power_series32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series34470

comment:90 Changed 4 months ago by
Status:  needs_review → positive_review 

trivial (automatic) merge, necessary to make the patchbots happy.
comment:91 Changed 4 months ago by
Commit:  41ca99b7bfee0c11c4ece0bffa0b9230a7b4f67b → 56cef070ebee69841f1ead61344557d10d0b56a0 

Status:  positive_review → needs_review 
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_series32367

4fc981b  fix for pyflakes and blocks

56cef07  Merge branch 'u/mantepse/replace_lazy_power_series32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series34470

comment:92 Changed 4 months ago by
Trivial merge, done because I keep switching between 9.8.beta0 and 9.8.beta1, which is a waste of time.
comment:93 Changed 4 months ago by
Status:  needs_review → positive_review 

comment:94 Changed 4 months ago by
Branch:  u/mantepse/categories_lazy_series34470 → 56cef070ebee69841f1ead61344557d10d0b56a0 

Resolution:  → fixed 
Status:  positive_review → closed 
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?).