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