Opened 5 months ago

Closed 4 months ago

#34470 closed defect (fixed)

categories of lazy series

Reported by: mantepse Owned by:
Priority: major Milestone: sage-9.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:

Status badges

Description (last modified by 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.

Change History (94)

comment:1 Changed 5 months ago by mantepse

Cc: tscrim added
Component: PLEASE CHANGEcategories
Keywords: LazyPowerSeries added
Type: PLEASE CHANGEdefect
Last edited 5 months ago by mantepse (previous) (diff)

comment:2 Changed 5 months ago by mantepse

Description: modified (diff)

comment:3 Changed 5 months ago by tscrim

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?).

comment:4 Changed 5 months ago by mantepse

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 tscrim

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 mantepse

Authors: Martin Rubey
Dependencies: #32367

comment:7 Changed 5 months ago by mantepse

Branch: u/mantepse/categories_of_lazy_series

comment:8 Changed 5 months ago by mantepse

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:

d75ac13Merge 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
293b439adapt doctests
8b6a752no period at end of input description, break long doctest
f88a5c8fix arithmetic product with 0 and finite support
89270ebMerge 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
b76d8f4allow to define lazy series using iterators, adapt doctest
4eb4dbdfix behaviour of __getitem__ for slices, provide missing doctests, minor simplifications in species directory
6f76b00replace LazyTaylorSeriesRing and LazyTaylorSeries with LazyPowerSeriesRing and LazyPowerSeries and add appropriate deprecations
ac29928Merge 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
b7d1b86fix categories and add doctests

comment:9 Changed 5 months ago by git

Commit: b7d1b867793601ac3108944231dde2175234eba9a742e36ca720f6eb22be9d8a4c309f0c2ae00082

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

a742e36implement _im_gens_, part 1

comment:10 in reply to:  8 ; Changed 5 months ago by tscrim

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:

a742e36implement _im_gens_, part 1

comment:11 in reply to:  10 ; Changed 5 months ago by mantepse

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}

comment:12 in reply to:  11 Changed 5 months ago by tscrim

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.

comment:13 Changed 5 months ago by mantepse

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.

comment:14 Changed 5 months ago by git

Commit: a742e36ca720f6eb22be9d8a4c309f0c2ae00082f7d7c4e1cd2f7d5218471e34b3535549363864cf

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

0de1c13add a warning and an example for the arithmetic product with a constant term
8e5de35add missing whitespace in docstring
f706c53Merge 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
af1de64Merge 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
b028c4dMerge branch 'u/mantepse/categories_of_lazy_series' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
3410edafix map_coefficients
8fc2dd1fix doctests because of __getitem__ change
2a3389ecompute no more elements than necessary in __getitem__
f687833Merge 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
f7d7c4eadapt doctests

comment:15 in reply to:  13 ; Changed 5 months ago by tscrim

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).

comment:16 in reply to:  15 ; Changed 5 months ago by mantepse

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.

comment:17 Changed 5 months ago by mantepse

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 mantepse

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 in reply to:  16 ; Changed 5 months ago by tscrim

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.

comment:20 in reply to:  19 ; Changed 5 months ago by mantepse

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 in reply to:  19 ; Changed 5 months ago by mantepse

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?

comment:22 Changed 5 months ago by mantepse

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 in reply to:  20 Changed 5 months ago by tscrim

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 notice truncate, monomials, and so on. With a lot of luck I will actually find homogeneous_components, buried among the other 96 methods.

I see. We might need some better class-level 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).

Last edited 5 months ago by tscrim (previous) (diff)

comment:24 in reply to:  21 Changed 5 months ago by tscrim

Replying to Martin Rubey:

Replying to Travis Scrimshaw:

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]?

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 mantepse

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 mantepse

sorry, I meant "homogeneous component", not "homogeneous element".

comment:27 Changed 5 months ago by tscrim

It is perhaps slightly non-standard 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 git

Commit: f7d7c4e1cd2f7d5218471e34b3535549363864cf90e2c2178f6418cc6a6c9cbd40a4d8de2e18b376

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

c90cb91Merge branch 'u/mantepse/replace_lazy_power_series_in_species_directory_with_the_new_lazy_taylor_series' of https://github.com/sagemath/sagetrac-mirror into u/tscrim/replace_lazy_power_series-32367
3bd9f8cFixing coefficients bug and some doc tweaks.
555d1b0fix LazyPowerSeries._element_constructor_ when passed a function
baea68dpass functions using coefficients to element constructor
7745337remove unused variable detected by pyflakes
cdad494do not advertise L(None) in favour of L.define()
e8c7636advertise passing None to the constructor
f541f3dadd links to relaxed p-adics
1df62c8fix wrong ring in doctest
90e2c21Merge branch 'u/mantepse/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series

comment:29 Changed 5 months ago by mantepse

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 tscrim

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 mantepse

Just let me know what I should implement, so we don't tread on each others toes.

comment:32 Changed 5 months ago by tscrim

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 cherry-pick stuff as necessary.

BTW - the controversial stuff here is the UFD category part.

comment:33 Changed 5 months ago by mantepse

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 in reply to:  33 Changed 5 months ago by tscrim

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 cherry-picked the _im_gens_ there too.

comment:35 Changed 5 months ago by git

Commit: 90e2c2178f6418cc6a6c9cbd40a4d8de2e18b376e3e331c49b9a464abd3d37b03e72a3a6dfdf8f51

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

23d951fDoing some reviewer changes.
6a3559eMerge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of https://github.com/sagemath/sagetrac-mirror into public/lazy_series/dvr_methods-TBA
6969549Implementing methods for DVF.
91244f3Merge branch 'public/lazy_series/dvr_methods-TBA' into u/tscrim/replace_lazy_power_series-32367
0a8b4c6implement _im_gens_, part 1
380ddc9adapt doctests
69d44abRemoving old use of LazyTaylorSeriesRing from my changes.
de6f16eMerge branch 'u/tscrim/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_of_lazy_series
e3e331cadd and correct some_elements for all rings, run all tests in the TestSuite (many fail)

comment:36 Changed 5 months ago by mantepse

Hurray, I actually found a real bug in the comparison of 'exact' series :-)

comment:37 Changed 5 months ago by git

Commit: e3e331c49b9a464abd3d37b03e72a3a6dfdf8f5100aaca080f0be83e5cede0970a035dc084923596

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

00aaca0introduce halting precision

comment:38 Changed 5 months ago by git

Commit: 00aaca080f0be83e5cede0970a035dc084923596f9dd62e7b9db93db213eb4d8b10e7e1f77920a5d

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

f9dd62efix equality of exact series, do not produce coefficients of polynomials by iterating over them

comment:39 Changed 5 months ago by git

Commit: f9dd62e7b9db93db213eb4d8b10e7e1f77920a5db9a66bed5b72672327ad1335461fe0833f11a0b5

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

b9a66beimplement missing required method lift_to_precision

comment:40 Changed 5 months ago by git

Commit: b9a66bed5b72672327ad1335461fe0833f11a0b588109cc334038473f7ef9d6318a64fea4a8e5456

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

88109ccfix precision also in species directory, do not forget to switch it off after doctest

comment:41 Changed 5 months ago by mantepse

Status: newneeds_review

comment:42 Changed 5 months ago by tscrim

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)
Last edited 5 months ago by tscrim (previous) (diff)

comment:43 Changed 5 months ago by mantepse

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 git

Commit: 88109cc334038473f7ef9d6318a64fea4a8e545608baf9a88210fee39bb5dd84064adddf7d1365e6

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

08baf9afix punctuation in docstrings

comment:45 Changed 5 months ago by mantepse

Some more low-hanging fruits, possibly for other tickets:

  • move the two checks in the global TESTS: section of lazy_series.py to the TestSuite 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 and some_elements in general. Currently, most examples are 'exact'. Why is an_element of ZZ just 1, 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 non-lazy sums of the form sum(a[i]*b[i] for i in ...) in stream.py. These should possibly be replaced by something like
    s = 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 mantepse

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 in reply to:  43 Changed 5 months ago by tscrim

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 in reply to:  45 Changed 5 months ago by tscrim

Replying to Martin Rubey:

Some more low-hanging fruits, possibly for other tickets:

  • move the two checks in the global TESTS: section of lazy_series.py to the TestSuite 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 and some_elements in general. Currently, most examples are 'exact'. Why is an_element of ZZ just 1, 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 non-lazy sums of the form sum(a[i]*b[i] for i in ...) in stream.py. These should possibly be replaced by something like
    s = 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 git

Commit: 08baf9a88210fee39bb5dd84064adddf7d1365e65bd0331f4210eb4c76eca6bc8b28331931443117

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

5bd0331correct an_element and some_elements, implement is_unit, _test_invert

comment:50 Changed 5 months ago by mantepse

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 tscrim

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 xval(f) F(x) = f(x) and similarly G(x) using g(x). This breaks up into 2 cases:

  1. If val(f) >= val(g), we have f(x) / g(x) = xval(f) - val(g) F(x) / G(x).
  2. 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) = df(X) F(X), where F(X) is a unit and df(X) is the lowest degree portion of f(X); similarly for g(X). Then, we have

gcd(f(X), g(X)) = gcd(df(X)F(X), dg(X)G(X)) = gcd(df(X), dg(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

Last edited 5 months ago by tscrim (previous) (diff)

comment:52 Changed 5 months ago by git

Commit: 5bd0331f4210eb4c76eca6bc8b283319314431171722eca9a24029683fd137eda0fbc063cd044fad

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

1722ecafix is_unit

comment:53 Changed 5 months ago by mantepse

funniest bug ever :-)

comment:54 Changed 5 months ago by mantepse

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 tscrim

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:56 Changed 5 months ago by mantepse

See #34549 for lrcalc.

comment:57 Changed 5 months ago by git

Commit: 1722eca9a24029683fd137eda0fbc063cd044fadcdf821a895d6c4ed46992d209cb5cdfbb6ae6d39

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

cdf821aimprove 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 tscrim

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 mantepse

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): 
    763763
    764764        EXAMPLES::
    765765
    766             sage: Zp(3)._test_invert()
     766            sage: L = LazyLaurentSeriesRing(QQ, 'z')
     767            sage: L._test_invert()
    767768
    768769        .. SEEALSO::
    769770
    class LazyDirichletSeriesRing(LazySeriesRing): 
    21752176    Element = LazyDirichletSeries
    21762177
    21772178    def __init__(self, base_ring, names, sparse=True, category=None):
    2178         """
     2179        r"""
    21792180        Initialize the ring.
    21802181
    21812182        TESTS::
    class LazyDirichletSeriesRing(LazySeriesRing): 
    21982199            sage: L in PrincipalIdealDomains
    21992200            False
    22002201
    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 non-invertible series, i.e., series with
     2206        vanishing constant term.
    22022207
    22032208        .. TODO::
    22042209
    22052210            According to the answers in
    22062211            https://mathoverflow.net/questions/5522/dirichlet-series-with-integer-coefficients-as-a-ufd,
    22072212            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, 103--109,
     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
    22092241        """
    22102242        if base_ring.characteristic() > 0:
    22112243            raise ValueError("positive characteristic not allowed for Dirichlet series")

comment:60 in reply to:  38 Changed 5 months ago by mantepse

Replying to git:

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

f9dd62efix equality of exact series, do not produce coefficients of polynomials by iterating over them

The following commit fixes an oversight in this commit.

comment:61 Changed 5 months ago by git

Commit: cdf821a895d6c4ed46992d209cb5cdfbb6ae6d39fbccb39ebef9bf107463c9955c8f254aa1dfe685

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

fbccb39normalize degree in Stream_exact for correct equality

comment:62 Changed 5 months ago by tscrim

Branch: u/mantepse/categories_of_lazy_seriesu/tscrim/categories_lazy_series-34470
Commit: fbccb39ebef9bf107463c9955c8f254aa1dfe685b930f58d4fcece6371e14d2aba6fc53e653c24b1
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:

3d5b8cfLast little things from the patchbot.
aa593b5Merge branch 'u/mantepse/categories_of_lazy_series' of https://github.com/sagemath/sagetrac-mirror into u/tscrim/categories_lazy_series-34470
840539dMore tests, more bugs fixed.
b930f58Merge branch 'u/mantepse/categories_of_lazy_series' of https://github.com/sagemath/sagetrac-mirror into u/tscrim/categories_lazy_series-34470

comment:63 Changed 5 months ago by mantepse

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:64 Changed 5 months ago by mantepse

(so, in case you continue while I sleep, please check #34552)

comment:65 Changed 5 months ago by git

Commit: b930f58d4fcece6371e14d2aba6fc53e653c24b1b47407b38c76f7cc6f58777bf8d6cf5feb19d4f5

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

b47407bImplementing _floordiv_, Stream._true_order to boolean, first fraction field, more tests, marking long tests.

comment:66 Changed 5 months ago by mantepse

Travis, do you know already why this branch is failing tests in the species directory?


New commits:

b47407bImplementing _floordiv_, Stream._true_order to boolean, first fraction field, more tests, marking long tests.

comment:67 in reply to:  66 Changed 5 months ago by tscrim

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 tscrim

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 field R((x)) when R 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.

Last edited 5 months ago by tscrim (previous) (diff)

comment:69 Changed 5 months ago by tscrim

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 mantepse

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 mantepse

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 git

Commit: b47407b38c76f7cc6f58777bf8d6cf5feb19d4f5e077b6655df290286c71404f4756babc97965f24

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

e077b66Using dynamic classes for FPS gcd.

comment:73 Changed 5 months ago by tscrim

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 tscrim

Also +1 for cutting this ticket off and moving on to #34552 for additional changes.

comment:75 Changed 5 months ago by mantepse

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 mantepse

#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 mantepse

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 tscrim

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 mantepse

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 tscrim

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 mantepse

I actually think that having a graded algebra with a non-graded 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 tscrim

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 mkoeppe

Milestone: sage-9.7sage-9.8

comment:84 Changed 5 months ago by git

Commit: e077b6655df290286c71404f4756babc97965f24ddc04a1a02b26270a89be3a2a56a193d6d794b42

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

ddc04a1Fixing last pyflakes things.

comment:85 Changed 5 months ago by tscrim

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 mantepse

Status: needs_reviewpositive_review

comment:87 Changed 5 months ago by tscrim

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

comment:88 Changed 4 months ago by mantepse

Branch: u/tscrim/categories_lazy_series-34470u/mantepse/categories_lazy_series-34470

comment:89 Changed 4 months ago by git

Commit: ddc04a1a02b26270a89be3a2a56a193d6d794b4241ca99b7bfee0c11c4ece0bffa0b9230a7b4f67b
Status: positive_reviewneeds_review

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

97df300Updating sf/sfa.py doctest due to #34494.
1388b8aMerge branch 'u/chapoton/34494' of https://github.com/sagemath/sagetrac-mirror into public/rings/lazy_series_revert-34383
7bfe5f7Merge branch 'public/rings/lazy_series_revert-34383' of https://github.com/sagemath/sagetrac-mirror into public/rings/lazy_series_revert-34383
2039990Updating doctest due to changes from #34494.
cdea820Merge branch 'public/rings/lazy_series_revert-34383' of https://github.com/sagemath/sagetrac-mirror into u/tscrim/derivatives_lazy_series-34413
b7f04edMerge branch 'develop' of trac.sagemath.org:sage into t/34413/derivatives_lazy_series-34413
2325826Merge branch 'u/mantepse/derivatives_lazy_series-34413' of trac.sagemath.org:sage into t/34422/implement_functorial_composition_of_lazy_symmetric_functiosn
ebcf5c3Merge 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
4172688Merge branch 'u/mantepse/implement_arithmetic_product_of_lazy_symmetric_functions' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series-32367
41ca99bMerge branch 'u/mantepse/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series-34470

comment:90 Changed 4 months ago by mantepse

Status: needs_reviewpositive_review

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

comment:91 Changed 4 months ago by git

Commit: 41ca99b7bfee0c11c4ece0bffa0b9230a7b4f67b56cef070ebee69841f1ead61344557d10d0b56a0
Status: positive_reviewneeds_review

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

67dff95Merge branch 'develop' of trac.sagemath.org:sage into t/32367/replace_lazy_power_series-32367
4fc981bfix for pyflakes and blocks
56cef07Merge branch 'u/mantepse/replace_lazy_power_series-32367' of trac.sagemath.org:sage into t/34470/categories_lazy_series-34470

comment:92 Changed 4 months ago by mantepse

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 mantepse

Status: needs_reviewpositive_review

comment:94 Changed 4 months ago by vbraun

Branch: u/mantepse/categories_lazy_series-3447056cef070ebee69841f1ead61344557d10d0b56a0
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.