M2
M2 copied to clipboard
Removing MonomialIdeal from top level
Short version: we can remove the type MonomialIdeal in the top level and instead install hooks on functions that have faster algorithms with monomial ideals that check if the input is a monomial ideal and if so use the faster algorithm. This is already accomplished for quotient, saturate, intersect, and annihilator in #1385.
Longer version: I understand that the Ideal vs MonomialIdeal dichotomy started a long time ago, and it makes sense that in the engine they can be stored differently, but I don't think they serve a good purpose at the top level anymore. The type Ideal can be changed to transparently store the ideals in the appropriate engine level object based on whether the ideal is actually a monomial ideal. Is there any issue with this?
Beside obvious programming pitfalls of dealing with different types, here are some issues with it:
i1 : S = ZZ[x,y];
i2 : isMonomialIdeal ideal "2x"
o2 = false
i3 : isMonomialIdeal monomialIdeal "2x"
o3 = true
i6 : E = kk[x,y, SkewCommutative => true];
i7 : monomialIdeal "x"
stdio:7:1:(3): error: expected a commutative ring
i8 : isMonomialIdeal ideal "x"
o8 = true
i13 : use S;
i14 : R = S/ideal"x";
i16 : monomialIdeal ideal "y"
stdio:16:1:(3): error: expected a polynomial ring without quotient elements
i17 : isMonomialIdeal ideal "y"
o17 = false
Why is it required that the ring be a commutative polynomial ring? I can imagine many places where lifting those requirements would actually be useful, e.g. when dealing with zero dimensional rings.
@mahrud I am inclined to agree, especially as this type was the source of the recent MonomialIdeal::sat bug...
On some examples though, there can be a serious difference in size of the object (a monomial ideal can take much less space, if there are many variables). But these are not common cases.
To be clear, I wasn't suggesting any changes in the engine or even the interpreter, only changing the top level so the type Ideal covers both types of storing an ideal.