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

fix MIPVariable inheritance #21353

Closed
videlec opened this issue Aug 26, 2016 · 66 comments
Closed

fix MIPVariable inheritance #21353

videlec opened this issue Aug 26, 2016 · 66 comments

Comments

@videlec
Copy link
Contributor

videlec commented Aug 26, 2016

Let MIPVariable not inherit from Element but SageObject. The only reason it used to be this way is to be able to multiply variables with scalars that can be dealt with in other ways. The previous inheritance scheme used the old parent framework that we try to get rid of.

See also the task ticket: #21380

Depends on #24096

CC: @tscrim @nthiery @simon-king-jena @mkoeppe

Component: categories

Author: Vincent Delecroix, Travis Scrimshaw

Branch/Commit: 76c7fab

Reviewer: Vincent Delecroix, Travis Scrimshaw

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

@videlec videlec added this to the sage-7.4 milestone Aug 26, 2016
@videlec
Copy link
Contributor Author

videlec commented Aug 26, 2016

Commit: aba5b74

@videlec
Copy link
Contributor Author

videlec commented Aug 26, 2016

New commits:

aba5b7421353: remove guess_category

@videlec
Copy link
Contributor Author

videlec commented Aug 26, 2016

Branch: u/vdelecroix/21353

@videlec

This comment has been minimized.

@nthiery
Copy link
Contributor

nthiery commented Aug 27, 2016

comment:4

+1 on getting rid of this kludge if we finally can!

About the change Parent.__init__ -> Ring.__init__: if this does not induce complications, I would tend to use the occasion to not have InfinityRing inherit from Ring and instead pass category=Rings() to Parent.__init__.

I don't expect a need for pure speed for this parent, right? Of course the elements could still belong to RingElement.

@tscrim
Copy link
Collaborator

tscrim commented Aug 27, 2016

comment:5

Replying to @nthiery:

About the change Parent.__init__ -> Ring.__init__: if this does not induce complications, I would tend to use the occasion to not have InfinityRing inherit from Ring and instead pass category=Rings() to Parent.__init__.

Doing that change would remove some functionality from InfinityRing (although I highly, highly doubt anyone is creating things like ideals of the infinity ring). Although that would be something

I don't expect a need for pure speed for this parent, right? Of course the elements could still belong to RingElement.

I believe we have this parent (essentially) nailed in memory at startup because of oo. So I don't think this is an issue at the end of the day.

@videlec
Copy link
Contributor Author

videlec commented Aug 27, 2016

comment:6

It does introduce complications: removing the inheritance from Ring causes error due to the absence of methods is_integral_domain and is_field. Some doctests are creating vector/matrices over the infinity ring.

@nthiery
Copy link
Contributor

nthiery commented Aug 28, 2016

comment:7

Replying to @videlec:

It does introduce complications: removing the inheritance from Ring causes error due to the absence of methods is_integral_domain and is_field. Some doctests are creating vector/matrices over the infinity ring.

Ah, shoot. That would be easy to fix by moving up those methods to
Rings, which anyway we want to do at some point. But then that's
starting to shift beyond the scope of this ticket.

As an intermediate step, one could keep for now the inheritance from
Ring, and pass a category=Rings() argument to Parent.

As you feel like guys!

@videlec
Copy link
Contributor Author

videlec commented Aug 31, 2016

comment:8

I am setting #20686 as a dependency since it is very likely to create merge failures.

Replying to @nthiery:

Replying to @videlec:

It does introduce complications: removing the inheritance from Ring causes error due to the absence of methods is_integral_domain and is_field. Some doctests are creating vector/matrices over the infinity ring.

Ah, shoot. That would be easy to fix by moving up those methods to
Rings, which anyway we want to do at some point. But then that's
starting to shift beyond the scope of this ticket.

If you do open a ticket for that, I would be happy to review.

As an intermediate step, one could keep for now the inheritance from
Ring, and pass a category=Rings() argument to Parent.

Well be better to get rid of sage.structure.rings.Ring in one step.

@videlec
Copy link
Contributor Author

videlec commented Aug 31, 2016

Dependencies: #20686

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 19, 2016

Changed commit from aba5b74 to 81506ff

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Sep 19, 2016

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

81506ff21353: remove guess_category

@videlec
Copy link
Contributor Author

videlec commented Sep 19, 2016

comment:10

rebased

@jdemeyer
Copy link

comment:11

Replying to @videlec:

rebased

...on an old version of Sage.

Still needs rebase.

@jdemeyer

This comment has been minimized.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 13, 2016

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0e095c521353: remove guess_category

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Oct 13, 2016

Changed commit from 81506ff to 0e095c5

@videlec
Copy link
Contributor Author

videlec commented Oct 13, 2016

comment:14

rebased on rc1

@jdemeyer
Copy link

Changed dependencies from #20686 to none

@jdemeyer
Copy link

comment:16

If this passes doctests, I have no objections. Nicolas?

@jdemeyer
Copy link

comment:17

Maybe two details: we should add a check like

if not isinstance(category, Category)
    raise TypeError(f"invalid category {category} for {self}")

(or at least check that category is not None)

And remove the "or None" from the documentation line

- ``category`` -- a category, or list or tuple thereof, or ``None``

@tscrim
Copy link
Collaborator

tscrim commented Oct 31, 2017

comment:42

I didn't see how that was possible because this moves two calls to is_Matrix and their imports (even if it was not consolidated into 1 top-level import). Really #24096 is positively reviewed, so it's not a big deal.

@jdemeyer
Copy link

comment:43

Replying to @tscrim:

I didn't see how that was possible because this moves two calls to is_Matrix and their imports

OK, I thought that you only added imports in this patch, but you did indeed move an import.

@jdemeyer
Copy link

Changed dependencies from #24109 #24096 to #24096

@jdemeyer
Copy link

comment:44

Merge conflict. Note that you may want to wait until the next beta when #24096 is merged.

@jdemeyer

This comment has been minimized.

@jdemeyer jdemeyer changed the title get rid of guess_category Various fixes in category initialization Nov 29, 2017
@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 30, 2017

Changed commit from f1fc365 to 5897f6d

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 30, 2017

Branch pushed to git repo; I updated commit sha1. New commits:

5897f6dMerge branch 'public/categoires/some_cleanup-21353' of git://trac.sagemath.org/sage into public/categoires/some_cleanup-21353

@tscrim
Copy link
Collaborator

tscrim commented Dec 30, 2017

comment:47

Rebased

@tscrim tscrim modified the milestones: sage-8.1, sage-8.2 Dec 30, 2017
@videlec

This comment has been minimized.

@videlec videlec changed the title Various fixes in category initialization fix MIPVariable inheritance Dec 30, 2017
@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 30, 2017

Changed commit from 5897f6d to 76c7fab

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 30, 2017

Branch pushed to git repo; I updated commit sha1. New commits:

76c7fab21353: extra doctest

@videlec
Copy link
Contributor Author

videlec commented Dec 30, 2017

Reviewer: Vincent Delecroix

@videlec
Copy link
Contributor Author

videlec commented Dec 30, 2017

comment:51

Added an extra doctest for checking about the base ring being taken into account.

I am happy with the current version.

@tscrim
Copy link
Collaborator

tscrim commented Dec 30, 2017

comment:52

LGTM, thanks.

@tscrim
Copy link
Collaborator

tscrim commented Dec 30, 2017

Changed reviewer from Vincent Delecroix to Vincent Delecroix, Travis Scrimshaw

@vbraun
Copy link
Member

vbraun commented Jan 1, 2018

Changed branch from public/categoires/some_cleanup-21353 to 76c7fab

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

6 participants