Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

base_extend() not implemented in MPolynomialRing #9902

Open
vbraun opened this issue Sep 12, 2010 · 3 comments
Open

base_extend() not implemented in MPolynomialRing #9902

vbraun opened this issue Sep 12, 2010 · 3 comments

Comments

@vbraun
Copy link
Member

vbraun commented Sep 12, 2010

The base class Ring defines base_extend(), but the implementation needs to be overridden in the derived class MPolynomialRing:

sage: sage: P.<x,y,z> = PolynomialRing(QQ,'x, y, z'); P
Multivariate Polynomial Ring in x, y, z over Rational Field
sage: P.base_extend(CC)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/vbraun/opt/sage-4.5.3/devel/sage-main/<ipython console> in <module>()

/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/sage/rings/ring.so in sage.rings.ring.Ring.base_extend (sage/rings/ring.c:3190)()

TypeError: no base extension defined

The patch implements the override and adds documentation.

CC: @novoselt @nilesjohnson

Component: commutative algebra

Author: Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/9902

@vbraun
Copy link
Member Author

vbraun commented Sep 12, 2010

Attachment: trax_9902_fix_base_extension.patch.gz

Initial patch

@vbraun
Copy link
Member Author

vbraun commented Dec 20, 2010

comment:2

Andrey, I wrote this patch a while a go to be able to extend the base field of the toric coordinate ring. It might be useful...

@novoselt
Copy link
Member

comment:3

I am not quite sure it is the right approach. It seems to me that we have two methods: change_ring that constructs "the same object but over different ring" and base_extend which does the same, but only if there is a natural coercion. Given this description, it seems to me that there should be only one implementation of base_extend in the base class:

def base_extend(self, R):
    if R.has_coerce_map(self.base_ring()):
        return self.change_ring(R)
    else:
        raise TypeError("%s cannot be extened to %s!" % (self.base_ring(), R))

and then each derived class should implement change_ring only. (If the detailed error message breaks a lot of doctests I am fine with keeping the current one.) Thoughts?

There is also discrepancy between actual argument names and their description in documentation (base_ring vs. R).

@jdemeyer jdemeyer modified the milestones: sage-5.11, sage-5.12 Aug 13, 2013
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.1, sage-6.2 Jan 30, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.2, sage-6.3 May 6, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.3, sage-6.4 Aug 10, 2014
@mkoeppe mkoeppe removed this from the sage-6.4 milestone Dec 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants