Re: [sage-support] Re: Calculation of basis taking over 12 hours?

On Mar 30, 2016, at 9:48 PM, saad khalid wrote: > > Also, I was wondering, does Sage use Singular for all groebner basis > calculations? I was reading that FGb has a much faster implementation: > http://www-salsa.lip6.fr/~jcf/FGb/index.html > > I can't seem to find out

[sage-support] Re: Calculation of basis taking over 12 hours?

Also, I was wondering, does Sage use Singular for all groebner basis calculations? I was reading that FGb has a much faster implementation: http://www-salsa.lip6.fr/~jcf/FGb/index.html I can't seem to find out anywhere if we have any implementation of the F4/F5 algorithms through FGb. If we

[sage-support] Re: Calculation of basis taking over 12 hours?

Oh wow... so there's a possibility that the calculation might take million of years for what I'm trying to do? Or there some easy way to approximate how long it will take based off of how many variables I have? Thank you! -Saad On Wednesday, March 30, 2016 at 2:35:07 PM UTC-5, mmarco wrote: >

[sage-support] Re: Is a binary app install possible on OSX 10.11 for 7.1 (or 7.2beta)?

On Wednesday, March 30, 2016 at 9:38:26 PM UTC+1, Des Johnston wrote: > > Both 7.1 and the beta0 of 7.2 give me first run errors on OSX 10.11 on a > Macbook: > > *after *editing an initial print statement that otherwise throws an > immediate error in relocate-once.py > IMHO OSX 10.11.4 still

[sage-support] Is a binary app install possible on OSX 10.11 for 7.1 (or 7.2beta)?

Both 7.1 and the beta0 of 7.2 give me first run errors on OSX 10.11 on a Macbook: *after *editing an initial print statement that otherwise throws an immediate error in relocate-once.py from print "relocate-once.py -d " to print("relocate-once.py -d ") I get

[sage-support] Benchmark linear system solve (sage x python(jupyter))

Hello everyone I tested the code below and noticed that the code done in python proved faster. does anyone know why? Sagemath code: A = random_matrix(RDF,5000,5000) B = random_vector(RDF,5000) %time x =A\B CPU time: 11.11 s, Wall time: 11.10 s or %time x = A.solve_right(B) CPU time:

[sage-support] Re: Calculation of basis taking over 12 hours?

All known gröbner basis algorithms have double exponential complexity. It means that the time you would need to complete a computation grows very quickly when you move to a high number of variables. It is not surprising at all that it may take days or even much more (think of millions of years)

[sage-support] Calculation of basis taking over 12 hours?

Hello everyone! I'm trying to run macauly through sage(it won't work properly on my own laptop, I think that some of the calculations take up too much ram and crash my laptop). Anyways, so everything has worked fine except calculating the groebner basis in this one case. Note that this crashed

Re: [sage-support] Re: libgap, simple membership question

On Wed, Mar 30, 2016 at 9:27 AM, Pierre wrote: > >> It also seems that "SymmetricGoup" has its elements live in a pexpect gap, >> not in libgap. It might be attractive to move that too. > > > I was wondering about that: so many sage objects are really GAP objects >

[sage-support] Re: libgap, simple membership question

> It also seems that "SymmetricGoup" has its elements live in a pexpect gap, > not in libgap. It might be attractive to move that too. > I was wondering about that: so many sage objects are really GAP objects wrapped up, with the old code using the pexpect interface, is the plan to re-write

[sage-support] Re: libgap, simple membership question

On Wednesday, March 30, 2016 at 7:46:29 AM UTC-7, Pierre wrote: > > Come to think of it, I just spotted a little bug in libgap: > > sage: p= Permutation([ (1, 2, 3), (4, 5) ]) > sage: pp= libgap( p ); pp > > [ 2, 3, 1, 5, 4 ] > > Here pp is a list, not a permutation ! GAP should respond

[sage-support] Re: libgap, simple membership question

Come to think of it, I just spotted a little bug in libgap: sage: p= Permutation([ (1, 2, 3), (4, 5) ]) sage: pp= libgap( p ); pp [ 2, 3, 1, 5, 4 ] Here pp is a list, not a permutation ! GAP should respond (1,2,3)(4,5), regardless of Sage's default behaviour of printing permutations as lists.

[sage-support] Re: Multivariate division with remainder of polynomials

Hi Jeroen, (Disclaimer: what follows is based on what I gathered while writing the French Sage book a few years ago and may non longer be accurate!) Jeroen Demeyer wrote: > I am having a hard time understanding the precise semantics of > multivariate polynomial quo_rem(). The documentation only

[sage-support] Re: libgap, simple membership question

ideally, one would want to overload __contains__ for libgap objects. https://docs.python.org/2/reference/datamodel.html#object.__contains__ then the syntax 'g in G' would just work. (not sure how easy this is) On Wednesday, March 30, 2016 at 10:39:14 AM UTC+1, Pierre wrote: > > Hi ! > > I've

[sage-support] Re: libgap, simple membership question

awesome! perfect solution :-) thanks ! On Wednesday, March 30, 2016 at 2:22:31 PM UTC+2, Volker Braun wrote: > > The "in" operator is the "\in" function in gap: > > sage: G = libgap.SymmetricGroup(3) > sage: g = libgap.eval("(1,2,3)") > sage: isContainedIn = libgap.function_factory(r'\in') >

[sage-support] Re: libgap, simple membership question

The "in" operator is the "\in" function in gap: sage: G = libgap.SymmetricGroup(3) sage: g = libgap.eval("(1,2,3)") sage: isContainedIn = libgap.function_factory(r'\in') sage: isContainedIn(g, G) true On Wednesday, March 30, 2016 at 11:39:14 AM UTC+2, Pierre wrote: > > Hi ! > > I've been

[sage-support] libgap, simple membership question

Hi ! I've been playing with libgap, which is great (I love the fact that lists returned by GAP now start at 0...) I have been unable, however, to elegantly work around the following simple taks. Suppose: sage: G= libgap.SymmetricGroup(3) sage: g= libgap.eval("(1,2,3)") sage: g in G # error