-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
shorten doctests in sage/rings/polynomial/multi_polynomial_ideal.py #7939
Comments
comment:1
Note that just about every time I run all tests I get the following:
Although, I never get this error when just running |
comment:3
Robert wrote:
I am afraid I cannot contribute much. One relevant pointer could be that we are shuffling a lot of data between Singular and Sage, potentially via temporary files, this could explain why no process ever gets over 10%? |
comment:4
I decided to take another look. In the attached patch I move most of the functions in On my Macbook Pro vanilla Sage 4.3 takes roughly 48 seconds to doctest As a side-effect, a lot of the ideal operations are considerably (100x and such) faster now and the libsingular functions interface is more robust and handles more functions now. Note that I tried to be a bit smart about the creation of the libsingular functions. One can now do:
which will load 'primdec.lib' first and then create a wrapper for The attached patch requires an updated SPKG which is available at: http://sage.math.washington.edu/home/malb/spkgs/singular-3-1-0-4-20100120.spkg I didn't mark any doctest |
Author: Martin Albrecht |
comment:6
sage.math:
|
comment:7
The updated patch fixes all doctest issues (on sage.math) for me. |
comment:8
Martin, This is great stuff! I'll try to look at it as soon as I get the released 4.3.1. |
comment:9
Some details on how much faster single functions got: vanilla sage: P = PolynomialRing(GF(127),5,'x')
sage: I = sage.rings.ideal.Cyclic(P)
sage: %time _ = I.triangular_decomposition()
CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s
Wall time: 4.83 s
sage: %timeit I.basis_is_groebner(); I.basis_is_groebner.clear_cache()
10 loops, best of 3: 520 ms per loop
sage: I = Ideal([P.random_element() for _ in range(P.ngens())])
sage: %time _ = I.variety()
CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s
Wall time: 4.25 s patch sage: P = PolynomialRing(GF(127),5,'x')
sage: I = sage.rings.ideal.Cyclic(P)
sage: %time _ = I.triangular_decomposition()
CPU times: user 0.05 s, sys: 0.00 s, total: 0.05 s
Wall time: 0.64 s
sage: %timeit I.basis_is_groebner(); I.basis_is_groebner.clear_cache()
1000 loops, best of 3: 1.98 ms per loop
sage: I = Ideal([P.random_element() for _ in range(P.ngens())])
sage: %time _ = I.variety()
CPU times: user 0.09 s, sys: 0.00 s, total: 0.09 s
Wall time: 0.64 s All timings on sage.math. |
comment:10
Hi! Regarding the option handling. Maybe we should use Pythons with statement:
Here an example from PolyBoRi with rings instead of options
But this would affect the whole interface of the option class (not immediately setting options in singular...) Cheers, |
comment:11
Passes tests for me. I tried to play with this a little bit, which lead to some questions:
(If yes, maybe this should be a new ticket.)
Is this a bug? Or am I doing something silly? If it's the latter, it would be good if there were an easy way for me to get help from the documentation. I tried groebner? and groebner?? (which give very different results) but I couldn't get an answer quickly. So I feel a little clueless at the moment. I'm hoping your answers will help me out, and I'll look at this again. (I still think it's terrific stuff, though!) |
comment:12
Replying to @aghitza:
Yes, that should be possible since Do you like the name "ff" by the way (function factory)? It should be short but precise. "factory" is out, because there is a module in Singular called factory (for factorisation).
Works for me, I just tried it.
answer quickly.
|
comment:13
Replying to @sagetrac-PolyBoRi:
Actually, the interface should be:
We do that for the
Mhh, does Cython support this yet? |
comment:14
That would awesome and exception safe.
Good question. Cheers, |
comment:15
Replying to @malb:
Well, the other possibility that springs to mind is "funfact" :) Seriously, I think "ff" is fine.
And now it also works for me. I restarted sage and tried it again and it seems fine. I'm not sure what triggered it before. I'll let you know if I happen to run into it again.
Here is what I get when I do these two: With
If I do
(Sorry these are a bit long.) But it looks like the first includes part, but not all, of the second. What would I like to see? (I'm not sure if this is feasible without a lot of work, but here goes.) If I type
and maybe a couple more showing other arguments/options would get me started with using the function. So I would think that it's more useful and natural to have something like the above, followed by the Singular help that shows all the options, bells, and whistles. Again, I don't know if this is feasible, but it would be nice. If that's not possible, maybe have a docstring that shows how to use some of the more popular Singular functions from Sage. If that's followed by the Singular help for the particular function I'm looking at at the moment, I should be able to put the two together and understand how to do things. |
comment:16
IMHO Sage specific documentation belongs in the layer around this generic Singular interface.
But that would be the responsible of another layer;-). |
comment:17
Replying to @sagetrac-PolyBoRi:
It seems it does. |
comment:18
Replying to @aghitza: For
It seems the second option is feasible. |
comment:19
The list of ToDos I can see is:
I will work on this soon-ish, let me know if there are other issues I should address. |
comment:20
Hmmm, tab completion is probably hard. I followed its trace to grammar.y:
I actually prints something... |
comment:21
We use that already for the pexpect interface, I was thinking about only calling that but that wouldn't update the list once a new library is loaded in libsingular but not in Singular itself. def trait_names(self):
"""
Return a list of all Singular commands.
EXAMPLES::
sage: singular.trait_names()
['exteriorPower',
...
'stdfglm']
"""
p = re.compile("// *([a-z0-9A-Z_]*).*") #compiles regular expression
proclist = self.eval("listvar(proc)").splitlines()
return [p.match(line).group(int(1)) for line in proclist] |
comment:22
Martin, you know Singular better than most of my collegues in KL. |
comment:23
probably it comes down to
I seem already to be infected by the Singular code... |
comment:24
This is such a fun way of not working on my thesis. The updated patch improves the following things:
I didn't address the singular options interface yet (next on my list). |
comment:25
The attached updated patch should take care of all remaining known outstanding issues. For instance, you can now do this: sage: P.<a,b,c,d,e> = PolynomialRing(GF(127))
sage: I = sage.rings.ideal.Cyclic(P)
sage: std = sage.libs.singular.ff.std
sage: from sage.libs.singular.option import opt, opt_ctx
sage: opt['redTail']
True
sage: std(I)[-1]
d^2*e^6 + 28*b*c*d + ...
sage: with opt_ctx(redTail=False,redSB=False):
... std(I)[-1]
d^2*e^6 + 8*c^3 + ...
sage: opt['redTail']
True |
comment:26
Fixing doctest issues. |
comment:27
With the latest patch, I'm now seeing
|
comment:28
Attachment: mpoly_ideal_libsingular.patch.gz That's because I uploaded the wrong file somehow. Now it should be the right one. |
Reviewer: Michael Brickenstein, Alex Ghitza |
comment:29
This looks good to me. There are only a few typos that are fixed by the small referee patch. One last question: in Anyway, positive review for the updated spkg and Martin's patch. If someone can have a quick look at the referee patch, we're done. In terms of the original motivation for this ticket (what was it already?): the file |
apply after the previous patch |
comment:30
Attachment: trac_7939-referee.patch.gz Alex's patch looks good. |
comment:31
Replying to @aghitza:
I was a bit split about leaving the pexpect interface stuff in or throwing it out completely. Singular supports some of its ideal operations over the complex numbers, although they probably don't make much sense there (rounding errors, 0 != 0 etc.). libSingular does not support complex numbers yet (although it is implemented in #7577 and waits for input on a design decision) and thus theoretical we are loosing some functionality. Then again, we are loosing functionality which does not really make much sense (e.g. you want to be careful about computing a Gröbner basis to get the variety of an ideal over CC) This is why I only half hearted removed the pexpect stuff (which supports CC). |
comment:32
Merged patches in this order: Merged singular-3-1-0-4-20100120.spkg in the standard spkg repository. |
Merged: sage-4.3.2.alpha0 |
Some of these doctests need to be marked
# long time
, at the very least.CC: @sagetrac-PolyBoRi
Component: interfaces
Author: Martin Albrecht
Reviewer: Michael Brickenstein, Alex Ghitza
Merged: sage-4.3.2.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/7939
The text was updated successfully, but these errors were encountered: