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
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
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
rewri
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
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 a
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 unsubs
Dear Salvatore,
On 2018-11-21, VulK wrote:
> is there any reason why `MPolynomialRing_polydict`
> hardcodes `MPolynomial_polydict` as its element class?
I believe it shouldn't hard-code it.
> I would have expected something like
>
> ```
> class MPolynomialRing_polydict( MPolynomialRing_macaul
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 som
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
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
10 matches
Mail list logo
