Opened 2 years ago

Closed 2 years ago

# The unit ideal is not prime or primary

Reported by: Owned by: cremona major sage-6.2 algebra unit prime primary ideal pbruin Peter Bruin John Cremona N/A u/pbruin/15745-primary_decomposition_unit_ideal (Commits) 295c7fd72cc777f3d5c2b2b25b2895c5c67e6170

### Description

On sage-support on 2014-01-27, Jack <kroeker@…> reported:

```I'm a bit confused about Sage's answer if Ideal(1) is prime.

R.<x,y>= QQ[]
I = Ideal(R(1))
I.is_prime()

Sage (5.11, not only)  says yes,
conflicting to the definition, http://en.wikipedia.org/wiki/Prime_ideal
Has somebody an expanation of this behaviour?
```

and in the following discussion it was agreed that this is incorrect, as is I.is_primary()}} (gives True not False) and {{{I.primary_decomposition() (gives a nonempty list) and {{{I.is_maximal())}} (raises an error instead of returning False).

This originates with Singular, but could easily be fixed in Sage.

### comment:1 Changed 2 years ago by pbruin

• Authors set to Peter Bruin
• Branch set to u/pbruin/15745-primary_decomposition_unit_ideal
• Commit set to 295c7fd72cc777f3d5c2b2b25b2895c5c67e6170
• Status changed from new to needs_review

In this branch:

• return empty primary decomposition for the unit ideal
• fix a different bug uncovered by the above fix (comparison of ideals was wrong in some cases when using different term orders)
• improve documentation of [complete_]primary_decomposition()

### comment:2 follow-up: ↓ 4 Changed 2 years ago by cremona

Looks good to me. I am not sure why we need to have a primer about definition and existence of primary decompositions in the docstring at all, let alone three times! But as long as they are correct (which they are, and I should know since I'll lecturing about all that later this term) I am certainly not going to suggest that they are removed.

Apart from tidying the documentation the patch just has two things, the easy one (deal with the unit ideal properly) and something else. Would it be possible to have an example of how the second change corrects something which used to be wrong?

Last edited 2 years ago by cremona (previous) (diff)

### comment:3 Changed 2 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:4 in reply to: ↑ 2 Changed 2 years ago by pbruin

Looks good to me. I am not sure why we need to have a primer about definition and existence of primary decompositions in the docstring at all, let alone three times! But as long as they are correct (which they are, and I should know since I'll lecturing about all that later this term) I am certainly not going to suggest that they are removed.

Yes, given that the small primer was already there I thought it made more sense to tidy it up than to remove it altogether.

Apart from tidying the documentation the patch just has two things, the easy one (deal with the unit ideal properly) and something else. Would it be possible to have an example of how the second change corrects something which used to be wrong?

The thing that failed after I made the first fix was a doctest that checked that the product of the primary ideals in the primary decomposition was equal to the original ideal. The problem was that comparison of ideals was broken in the following situation: I and J are ideals of R = Q[x,y], a Gröbner basis of J has been computed for a different monomial ordering than the default one for R, and no Gröbner basis for I has been computed. The reason why it didn't work is that the equality I = J was tested using the default monomial ordering of R, but with the "wrong" Gröbner basis for J. My fix makes sure that the comparison uses the monomial ordering of the cached Gröbner basis.

How was the bug triggered by the new check for the unit ideal? At the point this check is done, no Gröbner bases have been computed for any ideal, so Sage decides to use the degrevlex ordering, while the R in the doctest has the lex ordering. So a Gröbner basis for the degrevlex ordering is cached, and on the other hand when the product of the ideals in the primary decomposition is made it has no cached Gröbner basis, which brings us in the situation above.

I could have written a new doctest, but since it is already tested by an existing doctest I thought it wasn't really necessary, and I didn't see a natural way of explaining the above problem in the patch. I should have explained in my previous comment why there is no new doctest in the patch, though.

### comment:5 Changed 2 years ago by cremona

• Reviewers set to John Cremona
• Status changed from needs_review to positive_review

That's certainly a good enough explanation for me!

### comment:6 Changed 2 years ago by vbraun

• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.