Re: [sage-devel] Re: Implementing rings of coordinates
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.
* Nils Bruin [2018-11-22 11:10:11]:
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.
On Thursday, November 22, 2018 at 9:48:41 AM UTC-8, Salvatore Stella wrote:
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
* Simon King > [2018-11-22 14:10:14]:
>On 2018-11-22, Simon King > wrote:
>> 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.
>To unsubscribe from this group and stop receiving emails from it, send an
email to sage-devel+...@googlegroups.com .
>To post to this group, send email to sage-...@googlegroups.com
.
>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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Implementing rings of coordinates
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.
* Nils Bruin [2018-11-22 11:10:11]:
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.
On Thursday, November 22, 2018 at 9:48:41 AM UTC-8, Salvatore Stella wrote:
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
* Simon King > [2018-11-22 14:10:14]:
>On 2018-11-22, Simon King > wrote:
>> 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.
>To unsubscribe from this group and stop receiving emails from it, send an
email to sage-devel+...@googlegroups.com .
>To post to this group, send email to sage-...@googlegroups.com
.
>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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Implementing rings of coordinates
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.
On Thursday, November 22, 2018 at 9:48:41 AM UTC-8, Salvatore Stella wrote:
>
> 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
>
>
>
>
>
> * Simon King > [2018-11-22 14:10:14]:
>
> >On 2018-11-22, Simon King > wrote:
> >> 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.
> >To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com .
> >To post to this group, send email to sage-...@googlegroups.com
> .
> >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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Implementing rings of coordinates
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
* Simon King [2018-11-22 14:10:14]:
On 2018-11-22, Simon King wrote:
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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Implementing rings of coordinates
Done: https://trac.sagemath.org/ticket/26741 It appears that the change messes up with coercions. More details in the ticket description. S. * Simon King [2018-11-22 14:10:14]: On 2018-11-22, Simon King wrote: 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. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. 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. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Implementing rings of coordinates
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.
* Simon King [2018-11-21 12:03:24]:
Dear S.,
On 2018-11-20, VulK wrote:
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
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
Re: [sage-devel] Re: Implementing rings of coordinates
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
* Simon King [2018-11-21 12:03:24]:
Dear S.,
On 2018-11-20, VulK wrote:
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
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.
To unsubscribe from
