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

LeftIdeal replaces the old Ideal; new Ideal is two-sided #2912

Closed
wants to merge 23 commits into from

Conversation

antonleykin
Copy link
Contributor

@antonleykin antonleykin commented Aug 7, 2023

Ideal is a type of LeftIdeal now.

  • Most functions are defined for LeftIdeal;
  • the ones that make sense only for a two-sided ideal are defined for Ideal.
  • The method ideal constructs an ideal typical for the given ring: e.g.,
    • LeftIdeal for a Weyl algebra and
    • Ideal for all other algebras: e.g., polynomial ring, skew-commutative ring, AssociativeAlgebra, etc.

Current state:

  • there seem to be no errors in the build process
  • there still may be methods that can migrate from Ideal to LeftIdeal; currently
    • (clean session of M2) #methods Ideal is 223 and # methods LeftIdeal is 66
    • (after needsPackage "BernsteinSato") #methods Ideal is 271 and # methods LeftIdeal is 151

Whoever is interested in noncommutative things, please look at this.

@mahrud
Copy link
Member

mahrud commented Aug 8, 2023

Since the majority of Core code related to ideals is being touched, I think this is a good opportunity to move all of them into ideals.m2, with separation of those defined for LeftIdeal and those defined for Ideal.

@antonleykin
Copy link
Contributor Author

Since the majority of Core code related to ideals is being touched, I think this is a good opportunity to move all of them into ideals.m2, with separation of those defined for LeftIdeal and those defined for Ideal.

I agree, but it may be best to keep the edits in-place for now, so that people reviewing them can do so easily and are convinced that these are non-drastic (and hold water).

@mahrud
Copy link
Member

mahrud commented Sep 9, 2023

Totally valid point. My only suggestion is that we can add a second commit that does the moving. This way the first commit can be reviewed first (github allows reviewing commit by commit), and the second will be only a movement so should require minimal reviewing. No strong preference.

@mikestillman
Copy link
Member

@DanGrayson This pull request (currently a draft request) consists of one commit. However, it shows many commits by others that we have just recently merged into development, making it hard to see what has been added in this pull request. It also contains a conflicting file now, even though the request (I think) has nothing to do with that. Any idea how to fix this problem?

@mikestillman
Copy link
Member

@moorewf and @ggsmith This pull request will be changed to non-draft soon. What are your thoughts on it?

@d-torrance
Copy link
Member

It looks like commits from development were cherry-picked onto this branch (there are lots of messages like "d-torrance authored and Anton Leykin committed 2 days ago" under the "Commits" tab) rather than merging development or rebasing on top of it. Assuming that the development branch is up-to-date locally, git rebase development and then pushing this branch with the --force option should fix it.

@antonleykin
Copy link
Contributor Author

It looks like commits from development were cherry-picked onto this branch (there are lots of messages like "d-torrance authored and Anton Leykin committed 2 days ago" under the "Commits" tab) rather than merging development or rebasing on top of it. Assuming that the development branch is up-to-date locally, git rebase development and then pushing this branch with the --force option should fix it.

Thanks, @d-torrance !
Is there an easy way to avoid these kind of cherrypicks?
(I believe these particular ones were obtained by a combination of pulls and pushes done by magit.)

What is the simplest workflow to avoid this?
Should we

  • git rebase main/development (here: main is Macaulay2 as apposed to origin which is antonleykin) and then
  • git push --force (forcing a push every time?)

@d-torrance
Copy link
Member

Thanks, @d-torrance ! Is there an easy way to avoid these kind of cherrypicks? (I believe these particular ones were obtained by a combination of pulls and pushes done by magit.)

I think just be careful when rebasing. I'm not entirely sure what happened, but it looks like something that might have happened if you were on development and did git rebase LeftModule instead of the other way around.

What is the simplest workflow to avoid this? Should we

  • git rebase main/development (here: main is Macaulay2 as apposed to origin which is antonleykin) and then
  • git push --force (forcing a push every time?)

Yes, that should work! I generally like rebasing like this instead of merging on my pull requests so we don't end up with even more merge commits than we already have.

@mahrud
Copy link
Member

mahrud commented Nov 19, 2023

Just getting around to looking into this PR. I'm wondering, wouldn't the following alternative be simpler?

  • Let Ideal be an abstract type, meaning not necessarily two-sided
  • Define methods that work for any type of ideal for Ideal
  • Add LeftIdeal as a subtype of Ideal (i.e. opposite of this PR)
  • Whenever a method should do something different for left ideals, define a method which either implements the specialized routine or returns an error.

Is there a problem with this approach?

@pzinn
Copy link
Contributor

pzinn commented Nov 21, 2023

I know this has been discussed at length (including today!), but for what it's worth, here are my 2 cents:
why do we care about left ideals anyway? I understand why we care about two-sided ideals: that's because they're needed to make quotient rings. But left ideals are really just left modules which happen to be sitting in the ring. There's not much more about them that's interesting. So what we should be focusing on is defining left/right/bimodules...

@mahrud
Copy link
Member

mahrud commented Nov 21, 2023

That's an interesting perspective. It would certainly simplify the work, in that we wouldn't need to implement left modules and also left ideals, for instance.

In this case, there are 3 options for ideal(x,dx) in a Weyl algebra:

  1. give an error, explaining that ideals in M2 must be two sided
  2. give the corresponding two sided ideal, in this case ideal 1
  3. give the corresponding left module instead.

I can see pros/cons for all three.

@mikestillman
Copy link
Member

@pzinn I agree, an interesting point.

@moorewf What do you think about not having left/right ideals, instead just having left/right modules?

@moorewf
Copy link
Contributor

moorewf commented Nov 21, 2023

I'm fine with that as well. There doesn't seem to be a need to distinguish between the two.

@antonleykin
Copy link
Contributor Author

A sensible solution could be to have LeftIdeal to support the math habits of the $D$-modules community (a left ideal generated by a system of differential operators is as traditional as an ideal generated by polynomials), but I can see how (for instance in general associative algebras) we can get by without introducing RightIdeal... unless someone demands it.

@pzinn
Copy link
Contributor

pzinn commented Nov 21, 2023

But couldn't you define your D-modules as left modules rather than left ideals? after all, they are called D-modules...

@mahrud
Copy link
Member

mahrud commented Nov 21, 2023

You could alternatively define LeftIdeal to inherit from left modules, no? As long as nobody needs methods defined for ideals that are not defined for modules (which I don't think is the case), I think this would work.

@mahrud
Copy link
Member

mahrud commented Nov 22, 2023

I realized #3003 probably caused all the conflicts here, but since all of them are just renames from Dmodules/X to WeylAlgebras/X, a rebase should be able to fix it.

jkyang92 and others added 12 commits November 22, 2023 22:10
Added isPseudomonomial as exported function
When checking more than one package, this was causing build
failures ("Syntax error: end of file unexpected").
It's now a wrapper around substitute(RingElement, List) to avoid
issues where the matrix that was constructed ended up being over the
wrong ring.

We also check that the number of elements in the array matches the
number of generators of the ring.
We already know that we'll have ZZ objects since this is a method, so
there's no reason to check their type again.  Also, neither nrows or
ncols makes sense to be 0, so we raise an error in that case as well.
d-torrance and others added 11 commits November 22, 2023 22:10
* Various navigation buttons presumably once used in the html
  documentation, plus the Makefile and Scheme files used to generate
  them in Gimp.
* Redundant 9planets.jpg -- we use 9planets.gif in the html
  documentation.
* Several others of unknown purpose:
  - doc-no-buttons.css
  - styleswitcher.js
  - recbg.jpg
We also switch member -> isMember
Ideal is a type of LeftIdeal.
Most functions are defined for LeftIdeal; the ones that make sense
only for a two-sided ideal are defined for Ideal.
The method `ideal` constructs an ideal typical for the given ring:
e.g., LeftIdeal for a Weyl algebra and Ideal for a commutative or
skew-commutative ring.

Current state:
FirstPackage, Style, Macaulay2Doc install without errors,
there are errors in packages related to D-modules.
@antonleykin
Copy link
Contributor Author

This sequence doesn't seem to help

git rebase main/development 
git push --force

Experts on rebasing, what do you suggest?

@antonleykin
Copy link
Contributor Author

antonleykin commented Dec 13, 2023

superseded by #3020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants