[sage-devel] Implementing rings of coordinates

[VulK]

Dear all,
I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.

Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?

From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?

In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?
Thanks
S.

[Simon King]

Dear S.,

Post by VulK
I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.
Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?
From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?

I guess as the author of InfinitePolynomial*, I should chime in.

Unfortunately I don't know the background of what you want to achieve.
In particular, I don't know what indexing set you need. Of course,
changing _repr_ in a sub-class is not a hack but common usage.

Perhaps I should try to explain the purpose of InfinitePolynomial: You
have a finite list of symbols and for each symbol you have a family of
generators indexed by natural numbers. Together, they generate a free
commutative K-algebra R (an "infinite polynomial ring"), where K is a field.
Then, the symmetric group S of the natural numbers acts on each family
of generators by permuting indices. Any ideal J in R that is (as a set)
invariant under the S-action is finitely generated in the sense that there
is a finite list of elements g1,...,gn of J such that the union of the
S-orbits of g1,...,gn generates J as an R-ideal. Moreover, ideal
containment can be effectively tested by some flavour of Gröbner basis
theory ("symmetric Gröbner bases").

The purpose of my implementation is to compute symmetric Gröbner bases
and test ideal containment.

Is any of that useful for your application? Or do you just need an
algebra with an indexed family of generators? Then, I suppose it is
possible to implement it using the stuff in sage.sets.family, together
with sage.combinat.free_module.CombinatorialFreeModule

Inspite of its name, CombinatorialFreeModule can be used to implement an
algebra. Beware, however, that it is all a very *general* implementation in
*Python* (not Cython) and (I think) quite convoluted and indirect [e.g.,
apparently one is supposed to implement multiplication of elements not
by providing _mul_ for the elements but by providing a method
product_on_basis for the ring, which is then used in a multiplication
method (again not of the elements but of the ring) that is provided by
the category of AlgebrasWithBasis that is then finally used in a
multiplication method for elements that (if I recall correctly) also is
implemented in Python and is inherited from the category framework].

So, my impression has been that CombinatorialFreeModule is by design not
to be competitive in terms of speed. But I am sure that other people will
disagree with me on that point.

I would recommend to find an appropriate Cython base class for your elements.
You'd sub-class it (in Cython, if you care for speed), by providing _mul_
and _lmul_ for the elements. The parent (i.e., ring) can very well be
implemented in Python, as typically speed matters less for the ring than
for its elements. I could actually imagine to use
CombinatorielFreeModule to implement the ring, but without relying on
product_on_basis, and use a Cython class for the elements.

And please do use the category and coercion framework! You may want to
read this thematic tutorial:
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html

Post by VulK
In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?

There is no default implementation for the __call__() method of ring
elements. So, I guess you can just provide it. It's the usual cython way
of making something callable.

Best regards,
Simon

[VulK]

Hi Simon,
thank you for the explanation. As you guessed I do not need ideals nor
Gröbner basis. Forget for the moment the matter of infinitely many
generators: what I would like to implement is a polynomial ring whose
variables are certain functions. One possible way to do this would be to wrap
around multivariate polynomials with a class that keeps a dictionary in
between the actual dummy variables in the ring and the functions I would like
as generators. I would then perform substitutions every time that's needed.
My impression though is that this will get soon very messy.

Going the CombinatorialFreeModule route sounds like a good option (speed is
not a concern at the moment) but I am not sure if there is any facility
already in place to build a monomial basis out of some generators.

Thanks again
Salvatore

Post by Simon King
Dear S.,

Post by VulK
I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.
Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?
From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?

I guess as the author of InfinitePolynomial*, I should chime in.
Unfortunately I don't know the background of what you want to achieve.
In particular, I don't know what indexing set you need. Of course,
changing _repr_ in a sub-class is not a hack but common usage.
Perhaps I should try to explain the purpose of InfinitePolynomial: You
have a finite list of symbols and for each symbol you have a family of
generators indexed by natural numbers. Together, they generate a free
commutative K-algebra R (an "infinite polynomial ring"), where K is a field.
Then, the symmetric group S of the natural numbers acts on each family
of generators by permuting indices. Any ideal J in R that is (as a set)
invariant under the S-action is finitely generated in the sense that there
is a finite list of elements g1,...,gn of J such that the union of the
S-orbits of g1,...,gn generates J as an R-ideal. Moreover, ideal
containment can be effectively tested by some flavour of Gröbner basis
theory ("symmetric Gröbner bases").
The purpose of my implementation is to compute symmetric Gröbner bases
and test ideal containment.
Is any of that useful for your application? Or do you just need an
algebra with an indexed family of generators? Then, I suppose it is
possible to implement it using the stuff in sage.sets.family, together
with sage.combinat.free_module.CombinatorialFreeModule
Inspite of its name, CombinatorialFreeModule can be used to implement an
algebra. Beware, however, that it is all a very *general* implementation in
*Python* (not Cython) and (I think) quite convoluted and indirect [e.g.,
apparently one is supposed to implement multiplication of elements not
by providing _mul_ for the elements but by providing a method
product_on_basis for the ring, which is then used in a multiplication
method (again not of the elements but of the ring) that is provided by
the category of AlgebrasWithBasis that is then finally used in a
multiplication method for elements that (if I recall correctly) also is
implemented in Python and is inherited from the category framework].
So, my impression has been that CombinatorialFreeModule is by design not
to be competitive in terms of speed. But I am sure that other people will
disagree with me on that point.
I would recommend to find an appropriate Cython base class for your elements.
You'd sub-class it (in Cython, if you care for speed), by providing _mul_
and _lmul_ for the elements. The parent (i.e., ring) can very well be
implemented in Python, as typically speed matters less for the ring than
for its elements. I could actually imagine to use
CombinatorielFreeModule to implement the ring, but without relying on
product_on_basis, and use a Cython class for the elements.
And please do use the category and coercion framework! You may want to
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html

Post by VulK
In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?

There is no default implementation for the __call__() method of ring
elements. So, I guess you can just provide it. It's the usual cython way
of making something callable.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[VulK]

Dear All,
I decided to try inheriting from polynomials, specifically from
`MPolynomialRing_polydict` and `MPolynomial_polydict`, but I noticed
something strange: is there any reason why `MPolynomialRing_polydict`
hardcodes `MPolynomial_polydict` as its element class?

I would have expected something like

```
class MPolynomialRing_polydict( MPolynomialRing_macaulay2_repr, PolynomialRing_singular_repr, MPolynomialRing_base):

Element = MPolynomial_polydict
```
followed by the use of `Element` whenever this was needed. Instead this class
defines a method `_poly_class` which is only used once in `__init__` to
define generators (at line 142). Afterwards, every method that needs to build
elements imports again MPolynomial_polydict. This happens for example at line
437 for `__call__` and again at line 646 for `monomial_quotient`.

This obviously makes it complicated to add funtionality to the elements.
Thanks
S.

Post by Simon King
Dear S.,

Post by VulK
I am trying to implement the ring of coordinates of a Lie group in the
perspective of Peter-Weyl theorem.
Concretely I would like to define a polynomial ring with infinitely many
generators each depending on two points on a lattice. These generators
satisfy many relations but, for the moment, I am happy to forget this fact.
Is this possible in the current sage framework? Which are the classes I
should inherit from?
From a quick look at available classes it looks like InfinitePolynomialRing
and InfinitePolynomial might be the one I am after but I do not see how to
change the indexing sets as I need apart from brute force: I could keep a
dictionary and hack _repr_ accordingly. Any better idea?

I guess as the author of InfinitePolynomial*, I should chime in.
Unfortunately I don't know the background of what you want to achieve.
In particular, I don't know what indexing set you need. Of course,
changing _repr_ in a sub-class is not a hack but common usage.
Perhaps I should try to explain the purpose of InfinitePolynomial: You
have a finite list of symbols and for each symbol you have a family of
generators indexed by natural numbers. Together, they generate a free
commutative K-algebra R (an "infinite polynomial ring"), where K is a field.
Then, the symmetric group S of the natural numbers acts on each family
of generators by permuting indices. Any ideal J in R that is (as a set)
invariant under the S-action is finitely generated in the sense that there
is a finite list of elements g1,...,gn of J such that the union of the
S-orbits of g1,...,gn generates J as an R-ideal. Moreover, ideal
containment can be effectively tested by some flavour of Gröbner basis
theory ("symmetric Gröbner bases").
The purpose of my implementation is to compute symmetric Gröbner bases
and test ideal containment.
Is any of that useful for your application? Or do you just need an
algebra with an indexed family of generators? Then, I suppose it is
possible to implement it using the stuff in sage.sets.family, together
with sage.combinat.free_module.CombinatorialFreeModule
Inspite of its name, CombinatorialFreeModule can be used to implement an
algebra. Beware, however, that it is all a very *general* implementation in
*Python* (not Cython) and (I think) quite convoluted and indirect [e.g.,
apparently one is supposed to implement multiplication of elements not
by providing _mul_ for the elements but by providing a method
product_on_basis for the ring, which is then used in a multiplication
method (again not of the elements but of the ring) that is provided by
the category of AlgebrasWithBasis that is then finally used in a
multiplication method for elements that (if I recall correctly) also is
implemented in Python and is inherited from the category framework].
So, my impression has been that CombinatorialFreeModule is by design not
to be competitive in terms of speed. But I am sure that other people will
disagree with me on that point.
I would recommend to find an appropriate Cython base class for your elements.
You'd sub-class it (in Cython, if you care for speed), by providing _mul_
and _lmul_ for the elements. The parent (i.e., ring) can very well be
implemented in Python, as typically speed matters less for the ring than
for its elements. I could actually imagine to use
CombinatorielFreeModule to implement the ring, but without relying on
product_on_basis, and use a Cython class for the elements.
And please do use the category and coercion framework! You may want to
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html

Post by VulK
In a second moment I would like to be able to evaluate the element of this
ring at point on the group; is there a way to make them callable?

There is no default implementation for the __call__() method of ring
elements. So, I guess you can just provide it. It's the usual cython way
of making something callable.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Simon King]

Dear Salvatore,

Post by VulK
is there any reason why `MPolynomialRing_polydict`
hardcodes `MPolynomial_polydict` as its element class?

I believe it shouldn't hard-code it.

Post by VulK
I would have expected something like
```
Element = MPolynomial_polydict
```
followed by the use of `Element` whenever this was needed. Instead this class
defines a method `_poly_class` which is only used once in `__init__` to
define generators (at line 142). Afterwards, every method that needs to build
elements imports again MPolynomial_polydict.

It would be fine (and is done in other examples) to assign self.Element
during __init__. In other words, it is not compulsory that Element is a
class attribute; it can very well be an attribute of an instance.

However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors. If "self" is an element of some algebraic
parent, then the arithmetic methods of self (such as _mul_, _add_)
should create and return instances of self.parent().element_class, which
is a class dynamically created from self.parent().Element and from
information encoded in self.parent().category().

Might be a good idea to create a trac ticket for it.

Best regards,
Simon

[Simon King]

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".

[VulK]

Done: https://trac.sagemath.org/ticket/26741
It appears that the change messes up with coercions. More details in the
ticket description.
S.

Post by Simon King

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[VulK]

After a more accurate inspection, it appears that MPolynomialRing_polydict is
in quite a bad shape. First of all it redefines __call__ which, if I read [1]
correctly, should not be done. Second, within the many cases in __call__ one
can find:

{{{
510 elif isinstance(x, dict):
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in iteritems(x)})
}}}

and few lines below

{{{
561 if isinstance(x, dict):
562 return MPolynomial_polydict(self, x)
}}}

Clearly some housekeeping is in order. I'll try to do something about it and
then post again. Any input is welcome
S.

[1] http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics

Post by Simon King

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[Nils Bruin]

Pay attention, though. There may be all kinds of guidelines about how to
write sage code "appropriately", but in classes where performance is very
important there may be shortcuts that violate the guidelines. That may very
well be intentional. It may also be that it's legacy code and that
rewriting it according to the latest trends does not particularly affect
performance negatively.

Post by VulK
After a more accurate inspection, it appears that MPolynomialRing_polydict is
in quite a bad shape. First of all it redefines __call__ which, if I read [1]
correctly, should not be done. Second, within the many cases in __call__ one
{{{
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in iteritems(x)})
}}}
and few lines below
{{{
562 return MPolynomial_polydict(self, x)
}}}
Clearly some housekeeping is in order. I'll try to do something about it and
then post again. Any input is welcome
S.
[1]
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics

Post by Simon King

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".
--
You received this message because you are subscribed to the Google Groups

"sage-devel" group.

Post by Simon King
To unsubscribe from this group and stop receiving emails from it, send an

<javascript:>.

Post by Simon King
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[VulK]

You make a very good point, I'll try to be careful. I doubt this is a case of
efficiency since now __call__ goes through redundant cases and even has an
argument that is not used anywhere. Anyway I will cobble together something
and we can do speed testing before merging.

Post by Nils Bruin
Pay attention, though. There may be all kinds of guidelines about how to
write sage code "appropriately", but in classes where performance is very
important there may be shortcuts that violate the guidelines. That may very
well be intentional. It may also be that it's legacy code and that
rewriting it according to the latest trends does not particularly affect
performance negatively.

Post by VulK
After a more accurate inspection, it appears that MPolynomialRing_polydict is
in quite a bad shape. First of all it redefines __call__ which, if I read [1]
correctly, should not be done. Second, within the many cases in __call__ one
{{{
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in iteritems(x)})
}}}
and few lines below
{{{
562 return MPolynomial_polydict(self, x)
}}}
Clearly some housekeeping is in order. I'll try to do something about it and
then post again. Any input is welcome
S.
[1]
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics

Post by Simon King

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".
--
You received this message because you are subscribed to the Google Groups

"sage-devel" group.

Post by Simon King
To unsubscribe from this group and stop receiving emails from it, send an

<javascript:>.

Post by Simon King
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[VulK]

There is now a ticket (#26741) ready for review in which the changes have
been implemented. I decided not to refactor __call__ because the number of
failing doctest was quite big. Maybe this is a project for a separate ticket.

I have no idea on how to test reliably if the changes introduced any
measurable slowdown. Can anyone chime in on how to do it?
Thanks
S.

Post by Nils Bruin
Pay attention, though. There may be all kinds of guidelines about how to
write sage code "appropriately", but in classes where performance is very
important there may be shortcuts that violate the guidelines. That may very
well be intentional. It may also be that it's legacy code and that
rewriting it according to the latest trends does not particularly affect
performance negatively.

Post by VulK
After a more accurate inspection, it appears that MPolynomialRing_polydict is
in quite a bad shape. First of all it redefines __call__ which, if I read [1]
correctly, should not be done. Second, within the many cases in __call__ one
{{{
511 K = self.base_ring()
512 return MPolynomial_polydict(self, {i: K(a) for i, a in iteritems(x)})
}}}
and few lines below
{{{
562 return MPolynomial_polydict(self, x)
}}}
Clearly some housekeeping is in order. I'll try to do something about it and
then post again. Any input is welcome
S.
[1]
http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#coercion-the-basics

Post by Simon King

Post by Simon King
However, I believe it is bad usage to hard-code a certain class as
output of arithmetic errors.

Oops. "errors" is an error, it should be "operations".
--
You received this message because you are subscribed to the Google Groups

"sage-devel" group.

Post by Simon King
To unsubscribe from this group and stop receiving emails from it, send an

<javascript:>.

Post by Simon King
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.