Prune in skew-commutative rings

[pzinn]

consider the following:

i1 : R=QQ[a_0..a_4,SkewCommutative=>toList(0..4)]

o1 = R

o1 : PolynomialRing

i2 : I=ideal (a_0,a_2,a_1*a_3)

o2 = ideal (a , a , a a )
             0   2   1 3

o2 : Ideal of R

i3 : prune I

o3 = ideal 0

o3 : Ideal of QQ[a , a , a ]
                  1   3   4

That seems wrong to me. Either this needs to be fixed, or if Prune can't handle SkewCommutative rings, then it should probably give an error message.

[mikestillman]

OK, that’s not good!

On Mar 10, 2018, at 7:56 PM, Paul Zinn-Justin notifications@github.com wrote:

consider the following:

i1 : R=QQ[a_0..a_4,SkewCommutative=>toList(0..4)]

o1 = R

o1 : PolynomialRing

i2 : I=ideal (a_0,a_2,a_1*a_3)

o2 = ideal (a , a , a a ) 0 2 1 3

o2 : Ideal of R

i3 : prune I

o3 = ideal 0

o3 : Ideal of QQ[a , a , a ] 1 3 4 That seems wrong to me. If Prune can't handle SkewCommutative rings, then it should probably give an error message.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Macaulay2/M2/issues/756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGPRyH1VDwRvgH8dgyRMjtFZoNIIovmks5tdHZNgaJpZM4Slgo7.

[eisenbud]

This has nothing to do with skew rings! Prune just doesn’t work on ideals —David i24 : R = ZZ/101[a]

o24 = R

o24 : PolynomialRing

i25 : I = ideal a

o25 = ideal a

o25 : Ideal of R

i26 : prune I

o26 = ideal ()

R = ZZ/101[a_0..a_4]

o14 = R

o14 : PolynomialRing

i15 : I = ideal(a_0,a_2,a_1*a_3)

o15 = ideal (a , a , a a ) 0 2 1 3

o15 : Ideal of R

i16 : prune I

o16 = ideal(a a ) 1 3

-- David Eisenbud Director, Mathematical Sciences Research Institute; and Professor of Mathematics, University of California, Berkeley www.msri.org/~de

On Mar 10, 2018, at 5:01 PM, Mike Stillman notifications@github.com wrote:

OK, that’s not good!

On Mar 10, 2018, at 7:56 PM, Paul Zinn-Justin notifications@github.com wrote:

consider the following:

i1 : R=QQ[a_0..a_4,SkewCommutative=>toList(0..4)]

o1 = R

o1 : PolynomialRing

i2 : I=ideal (a_0,a_2,a_1*a_3)

o2 = ideal (a , a , a a ) 0 2 1 3

o2 : Ideal of R

i3 : prune I

o3 = ideal 0

o3 : Ideal of QQ[a , a , a ] 1 3 4 That seems wrong to me. If Prune can't handle SkewCommutative rings, then it should probably give an error message.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Macaulay2/M2/issues/756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGPRyH1VDwRvgH8dgyRMjtFZoNIIovmks5tdHZNgaJpZM4Slgo7.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pzinn]

in your example David I think everything's OK: really it's pruning the corresponding quotient ring, and in your case it's indeed getting ring of the linear equation by elimination to produce the zero ideal (in the ring with no variables).

[eisenbud]

But prune module I produces a different result!

David

David Eisenbud Director, Mathematical Sciences Research Institute; and Professor of Mathematics,University of California, Berkeley www.msri.org/~de

On Mar 10, 2018, at 6:50 PM, Paul Zinn-Justin notifications@github.com wrote:

in your example David I think everything's OK: really it's pruning the corresponding quotient ring, and in your case it's indeed getting ring of the linear equation by elimination to produce the zero ideal (in the ring with no variables).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[pzinn]

yes, Prune (minimalPresentation) for modules and Prune for ideals are two completely different functions, doing different things. The fact that they have the same name is very confusing, I agree.

[DanGrayson]

The behavior is documented, but it's very strange:

       * Usage:J = minimalPresentation I
       * Function: "prune"
       * Inputs:
           * I, an ideal, in a ring S
       * Optional inputs:
           * Exclude => ..., 
       * Outputs:
           * J, an ideal,  in a new ring Q with S/I isomorphic to Q/J

I would expect any operation on an ideal to return an ideal of the same ring.

[mikestillman]

The reason for this version of the function is for the case when it is impossible to compute a Groebner basis of I. One would really want to do “ minimalPresentation(S/I)”, but that requires a Groebner basis for I. On the other hand, it is (often) easy to use linear equations to reduce the number of variables in a ring, obtaining Q/J. I needed this for example for affine and local rings of Hilbert schemes, where the Groebner basis computations were not feasible.

I agree completely: this is a too cute use of the same name. It should have a longer name (not sure what is best though), indicating better what it is doing. Suggestions? Can we change the behavior at this point anyway?

On Mar 11, 2018, at 8:10 AM, Daniel R. Grayson notifications@github.com wrote:

The behavior is documented, but it's very strange:

   * Usage:J = minimalPresentation I
   * Function: "prune"
   * Inputs:
       * I, an ideal, in a ring S
   * Optional inputs:
       * Exclude => ..., 
   * Outputs:
       * J, an ideal,  in a new ring Q with S/I isomorphic to Q/J

I would expect any operation on an ideal to return an ideal of the same ring.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Macaulay2/M2/issues/756#issuecomment-372110539, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGPR82JVbbwnSXWbHPqyx8_nQq4ewsMks5tdRQ1gaJpZM4Slgo7.

[DanGrayson]

Hmm? It looks like it computes the gb anyway:

        * Consequences:
            * minimalPresentation stores the isomorphism  from S/I to Q/J as
              I.cache.minimalPresentationMap , where I is the input ideal and the inverse of
              this map as I.cache.minimalPresentationMapInv

[DanGrayson]

What about introducing a type called RingPresentation? Its elements would be pairs (R,I) that are to be thought of as presentations for quotient rings. Then prune would be a fine name to use on such things.

[pzinn]

To be honest, prune Ideal is a really convenient function, and changing its syntax to something more cumbersome doesn't seem very appealing to me. Giving different names to prune/minimalPresentation Ideal vs prune/minimalPresentation Module is probably a good idea, though. None of which has anything to do with the current issue :-P

[eisenbud]

I do think that this function strays from the M2 ideal of writing math. Not looking at the documentation (but having introduced the name "prune", with Mike, approximately a hundred years ago) I was fooled by the name. I understand "minimalPresentation(S/I); and I can see the need for removing extra variables, but maybe the name should indicate that. How about

trimVariables (S/I)

or some such?

David

David Eisenbud Director, Mathematical Sciences Research Institute; and Professor of Mathematics,University of California, Berkeley www.msri.org/~de

On Mar 11, 2018, at 5:10 AM, Daniel R. Grayson notifications@github.com wrote:

The behavior is documented, but it's very strange:

   * Usage:J = minimalPresentation I
   * Function: "prune"
   * Inputs:
       * I, an ideal, in a ring S
   * Optional inputs:
       * Exclude => ..., 
   * Outputs:
       * J, an ideal,  in a new ring Q with S/I isomorphic to Q/J

I would expect any operation on an ideal to return an ideal of the same ring.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[DanGrayson]

minimalPresentation(S/I) already conveys the ideal that both generators and relations should be minimized.

We do want Macaulay2 code to look like math, and the variables of the ambient ring are not the generators that one thinks of when seeing code like minimalPresentation I, so I think something has to be done. The new syntax would not be much more cumbersome, and it would offer a big advantage -- so surprises.

[pzinn]

I'm tempted to give up on this issue. Are skew-commutative rings going to be made obsolete by the new AssociativeAlgebras package? it would certainly clean up the code quite a bit.

[DanGrayson]

I think the new package is unrelated to this issue.

Why don't we just make prune of an ideal be undefined?

[pzinn]

It definitely is unrelated to the issue (as is most of the discussion in this thread!). My point was, will we still need the skew-commutative code once we have fully noncommutative algebras? And once again the issue has nothing to do with the synonym prune. The same issue would arise with minimumPresentation.

[DanGrayson]

Ah, now I see your original point.

[moorewf]

I don't expect skew-commutative rings to go away, since the current skew-commutative GB implementation (i.e. as a quotient of an exterior algebra) is much faster than the noncommutative algebra GB implementation (i.e. as a quotient of the free algebra). In addition, GBs will be finite over the exterior algebra, while even if the quotient one is considering is finite, the GB in the associative algebra may be infinite.

[pzinn]

in the latest version of M2, seems the bug is gone. closing.