#1396 closed enhancement (duplicate)
Ideal.groebner_basis should accept keyword arguments for strategy parameters
Reported by: | malb | Owned by: | malb |
---|---|---|---|
Priority: | minor | Milestone: | sage-duplicate/invalid/wontfix |
Component: | commutative algebra | Keywords: | libSingular options |
Cc: | Merged in: | ||
Authors: | Simon King | Reviewers: | Martin Albrecht |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
e.g. Singular supports redTail
and such. We should provide a somewhat unified interface for those (probably modelled after whatever Singular provides).
Attachments (3)
Change History (20)
comment:1 Changed 14 years ago by
- Status changed from new to assigned
comment:2 Changed 14 years ago by
- Owner changed from malb to john_perry
- Status changed from assigned to new
comment:3 in reply to: ↑ description ; follow-up: ↓ 4 Changed 14 years ago by
comment:4 in reply to: ↑ 3 Changed 14 years ago by
Replying to john_perry:
I.set_singular_option("lazy"); I.groebner_basis()
That stuff somewhat works already:
sage: singular.option('lazy') sage: singular.option() //options: lazy redefine loadLib usage prompt
The point of this ticket is that the user can be ignorant of the fact that (s)he is running Singular in the background and can specify options for a particular GB computation.
Changed 14 years ago by
[with patch, needs work] Adds options to groebner_basis for lazy, redTail, redSB, and notSugar -- currently implemented for Singular only
comment:5 Changed 14 years ago by
- Status changed from new to assigned
- Summary changed from Ideal.groebner_basis should accept keyword arguments for strategy parameters to [with patch, needs work] Ideal.groebner_basis should accept keyword arguments for strategy parameters
comment:6 Changed 14 years ago by
- Owner changed from john_perry to malb
- Status changed from assigned to new
comment:7 Changed 12 years ago by
- Keywords libSingular options added
- Report Upstream set to N/A
- Status changed from needs_work to needs_review
- Summary changed from [with patch, needs work] Ideal.groebner_basis should accept keyword arguments for strategy parameters to Ideal.groebner_basis should accept keyword arguments for strategy parameters
This patch extends Martin's work on libSingular options. Now, the options degBound
and multBound
can be used. A decorator, applied to all relevant methods, ensures that standard options are used unless explicitly requested by setting named arguments -- even if outside the methods other options are set.
The options can be named in Python style (deg_bound) or in Singular style (degBound
), at the user's choice.
Examples:
- Degree bound
sage: R.<x,y> = QQ[] sage: I = R*[x^3+y^2,x^2*y+1] sage: from sage.libs.singular.option import opt # Use prot and deg_bound sage: I.groebner_basis(prot=True, deg_bound=2) std in (0),(x,y),(dp(2),C) [4294967295:2]3ss (S:1)- product criterion:0 chain criterion:0 [x^3 + y^2, x^2*y + 1] # Set prot and degBound outside the method sage: opt['prot'] = True # Singular style name sage: opt['degBound'] = 2 # ... but inside the method, standard options are used: sage: I.groebner_basis() [x^3 + y^2, x^2*y + 1, y^3 - x] sage: opt['prot'] True # Python style name sage: opt['deg_bound'] 2 # similarly in Singular, rather than libSingular sage: I.groebner_basis(algorithm='singular',deg_bound=2) [x^3 + y^2, x^2*y + 1] sage: singular.eval('degBound=2') 'degBound=2;' sage: I.groebner_basis(algorithm='singular') [x^3 + y^2, x^2*y + 1, y^3 - x] sage: singular.eval('degBound') '2'
- Multiplicity bound
sage: Rlocal.<x,y,z> = PolynomialRing(QQ, order='ds') sage: J = [x^7+y^7+z^6,x^6+y^8+z^7,x^7+y^5+z^8, x^2*y^3+y^2*z^3+x^3*z^2,x^3*y^2+y^3*z^2+x^2*z^3]*Rlocal # prot: sage: J.groebner_basis(prot=True) std in basering [1048575:2]5(4)s(3)s6s7s8s(4)s(5)sH(13)9(3)sH(12)8(4)s(5).s.s9....sH(11)8.10 (S:10)----------- product criterion:9 chain criterion:30 [x^3*y^2 + y^3*z^2 + x^2*z^3, x^2*y^3 + x^3*z^2 + y^2*z^3, y^5, x^6, x^4*z^2 - y^4*z^2 - x^2*y*z^3 + x*y^2*z^3, z^6, y^4*z^3 - y^3*z^4 - x^2*z^5, x^3*y*z^4 - x^2*y^2*z^4 + x*y^3*z^4, x^3*z^5, x^2*y*z^5 + y^3*z^5, x*y^3*z^5] # bounding the multiplicity sage: J.groebner_basis(prot=True,mult_bound=100) std in basering [1048575:2]5(4)s(3)s6s7s8s(4)s(5)sH(13) (S:5)------ product criterion:7 chain criterion:7 [x^3*y^2 + y^3*z^2 + x^2*z^3, x^2*y^3 + x^3*z^2 + y^2*z^3, y^5, x^6 + x*y^4*z^5, x^4*z^2 - y^4*z^2 - x^2*y*z^3 + x*y^2*z^3, z^6 - x*y^4*z^4 - x^3*y*z^5] # Set the multBound in Singular sage: singular.eval('multBound=100') 'multBound=100;' # ... nevertheless, the default multBound=0 is used: sage: J.groebner_basis(algorithm='singular') [x^3*y^2 + y^3*z^2 + x^2*z^3, x^2*y^3 + x^3*z^2 + y^2*z^3, y^5, x^6, x^4*z^2 - y^4*z^2 - x^2*y*z^3 + x*y^2*z^3, z^6, y^4*z^3 - y^3*z^4 - x^2*z^5, x^3*y*z^4 - x^2*y^2*z^4 + x*y^3*z^4, x^3*z^5, x^2*y*z^5 + y^3*z^5, x*y^3*z^5] sage: singular.eval('multBound') '100' # ... unless requested otherwise sage: J.groebner_basis(algorithm='singular',mult_bound=100) [x^3*y^2 + y^3*z^2 + x^2*z^3, x^2*y^3 + x^3*z^2 + y^2*z^3, y^5, x^6 + x*y^4*z^5, x^4*z^2 - y^4*z^2 - x^2*y*z^3 + x*y^2*z^3, z^6 - x*y^4*z^4 - x^3*y*z^5]
I just verified that sage -testall
passes. So, ready for review!
One remark: It turned out to be impossible to doctest libSingular's
protocol output. I inserted examples with protocol in the documentation, for illustration, but don't test these. Of course, deg_bound and mult_bound is doctested.
Changed 12 years ago by
Replaces the first patch. Full support for all Singular options in both Singular and libSingular
comment:8 Changed 12 years ago by
- Status changed from needs_review to positive_review
The patch looks good, is well documented, applies cleanly, doctests pass. My referee patch adds one whitespace character thus I feel I can give it a positive review.
comment:9 Changed 12 years ago by
Applying trac1396-singular_options.patch to a long queue of other patches I've put together for 4.5.2.alpha0, I get
$ hg qpush applying trac1396-singular_options.patch patching file sage/libs/singular/singular-cdefs.pxi Hunk #2 FAILED at 993 1 out of 3 hunks FAILED -- saving rejects to file sage/libs/singular/singular-cdefs.pxi.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac1396-singular_options.patch
Earlier tickets in the queue include #6922 and #9499. Since sage/libs/singular/singular-cdefs.pxi.rej
contains just
-
singular-cdefs.pxi
995 994 poly *prCopyR_NoSort(poly *p, ring *r, ring *dest_r) 996 995 poly *prCopyR(poly *p, ring *r, ring *dest_r) 997 996 998 999 1000 997 cdef int LANG_TOP 1001 998 1002 999 cdef extern from "stairc.h":
I'll ignore the rejects, refresh the patch, and attach the refreshed patch here. Please let me know if this is a problem.
Changed 12 years ago by
Rebased for 4.5.2.alpha0 queue. See comment 9. Replaces all previous patches.
comment:10 Changed 12 years ago by
- Merged in set to sage-4.5.2.alpha0
- Resolution set to fixed
- Reviewers set to Martin Albrecht
- Status changed from positive_review to closed
comment:11 follow-up: ↓ 13 Changed 12 years ago by
This ticket might be the source of an "Unhandled SIGSEGV" on t2. Please see #9583, a blocker for Sage 4.5.2.
comment:12 Changed 12 years ago by
Perhaps I didn't rebase the patch properly?
comment:13 in reply to: ↑ 11 ; follow-up: ↓ 15 Changed 12 years ago by
Replying to mpatel:
This ticket might be the source of an "Unhandled SIGSEGV" on t2. Please see #9583, a blocker for Sage 4.5.2.
Backing out the patch does allow Sage to start on t2.math, so for 4.5.2, I'm going to yank this patch, and open another ticket; this patch can go back in, along with the necessary spkg, in the next release. Sorry.
We don't have an "unmerged in:" field, but this patch is getting "unmerged" in 4.5.2.alpha1.
comment:14 Changed 12 years ago by
The new ticket is #9599.
comment:15 in reply to: ↑ 13 Changed 12 years ago by
Replying to ddrake:
Replying to mpatel:
This ticket might be the source of an "Unhandled SIGSEGV" on t2. Please see #9583, a blocker for Sage 4.5.2.
Backing out the patch does allow Sage to start on t2.math, so for 4.5.2, I'm going to yank this patch, and open another ticket; this patch can go back in, along with the necessary spkg, in the next release. Sorry.
We don't have an "unmerged in:" field, but this patch is getting "unmerged" in 4.5.2.alpha1.
Should it not be set back to "needs work" then? That seems the most accurate description of the status - more accurate so than "fixed".
Dave
comment:16 Changed 12 years ago by
Should it not be set back to "needs work" then? That seems the most accurate description of the status - more accurate so than "fixed".
I think we should just change focus to #9599, the new ticket for re-merging this patch.
comment:17 Changed 12 years ago by
- Merged in sage-4.5.2.alpha0 deleted
- Milestone changed from sage-4.5.2 to sage-duplicate/invalid/wontfix
- Resolution changed from fixed to duplicate
Replying to malb:
I have a version of this going now, with the behavior similar to what the ticket requests. However, would it be more desirable to allow the user's options to persist through several operations, using an interface such as (say)
I.set_singular_option("lazy"); I.groebner_basis()
rather than add arguments only to the Groebner basis command, such as
I.groebner_basis(lazy=True)