Re: [sage-devel] OS X Mavericks
On Mon, Nov 18, 2013 at 10:07 PM, R. Andrew Ohana wrote: > I've uploaded a binary to > http://boxen.math.washington.edu/home/ohanar/builds/sage-5.13.beta3-x86_64-Darwin.dmg > -- no promises it will work for you. > This worked for me. Thank you! > > On Sun, Nov 17, 2013 at 11:51 PM, R. Andrew Ohana > wrote: >> >> I've opened #15433 to trac porting to 10.9. >> >> >> On Sat, Nov 16, 2013 at 10:18 PM, R. Andrew Ohana >> wrote: >>> >>> Ok, I've successfully built a fully working copy of sage on 10.9 (i.e. >>> passes all >>> doctests with 3 exceptions, see below). >>> >>> polybori: I stopped experiencing the issue others are having (and still >>> have not >>> been able to figure out what resolved it for me) >>> >>> scipy: This seems like more or less the same issue that we had with 10.8 >>> -- see >>> #13309. An easy work around until scipy is updated is to add >>> -D__ACCELERATE__ to the CPPFLAGS. >>> >>> r: links against CoreData, which in turn links against sqlite. >>> Unfortunately, it >>> seems like CoreData now requires the extra modules Apple has included in >>> the >>> system copy of sqlite. As I see it we have 2 options: >>> 1) include these extra modules to support CoreData >>> 2) switch to using the system sqlite on osx >>> I would vote for the 2nd, as I think it would reduce future headache (and >>> it isn't >>> crucial for our purposes to have the most recent version of sqlite). >>> Doing this >>> currently produces 3 doctests errors that explicitly test our copy of >>> sqlite >>> >>> sage library: the system cblas won't pretend it is atlas anymore, so set >>> BLAS2 to 'cblas' >>> >>> gcc: at least for me, I was finding that the resulting libstdc++ was >>> missing some >>> symbols. I haven't looked into this yet (I instead used homebrew's gcc). >>> >>> -- >>> Andrew >> >> >> >> >> -- >> Andrew > > > > > -- > Andrew > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] OS X Mavericks
I've uploaded a binary to http://boxen.math.washington.edu/home/ohanar/builds/sage-5.13.beta3-x86_64-Darwin.dmg-- no promises it will work for you. On Sun, Nov 17, 2013 at 11:51 PM, R. Andrew Ohana wrote: > I've opened #15433 to trac porting to 10.9. > > > On Sat, Nov 16, 2013 at 10:18 PM, R. Andrew Ohana > wrote: > >> Ok, I've successfully built a fully working copy of sage on 10.9 (i.e. >> passes all >> doctests with 3 exceptions, see below). >> >> polybori: I stopped experiencing the issue others are having (and still >> have not >> been able to figure out what resolved it for me) >> >> scipy: This seems like more or less the same issue that we had with 10.8 >> -- see >> #13309. An easy work around until scipy is updated is to add >> -D__ACCELERATE__ to the CPPFLAGS. >> >> r: links against CoreData, which in turn links against sqlite. >> Unfortunately, it >> seems like CoreData now requires the extra modules Apple has included in >> the >> system copy of sqlite. As I see it we have 2 options: >> 1) include these extra modules to support CoreData >> 2) switch to using the system sqlite on osx >> I would vote for the 2nd, as I think it would reduce future headache (and >> it isn't >> crucial for our purposes to have the most recent version of sqlite). >> Doing this >> currently produces 3 doctests errors that explicitly test our copy of >> sqlite >> >> sage library: the system cblas won't pretend it is atlas anymore, so set >> BLAS2 to 'cblas' >> >> gcc: at least for me, I was finding that the resulting libstdc++ was >> missing some >> symbols. I haven't looked into this yet (I instead used homebrew's gcc). >> >> -- >> Andrew >> > > > > -- > Andrew > -- Andrew -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] patchbot and whitespace?
I think the patchbot may have some trouble with patches correcting whitespace. On: http://trac.sagemath.org/ticket/15367 the patchbot complained (correctly) about whitespace. I'm pretty sure I corrected it with the latest commit, but the last run of the patchbot (triggered by the commit) reports exactly the same whitespace problems. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] (Singular's) syz() over integers
Hello,
Singular's syz function (and probably others) is screwed up over integers.
Here is a failing example
Z = IntegerRing(); Z
R. = PolynomialRing(Z )
I= R.ideal([x*y-3,
3*y^6+18*y^5*z-9*y^4*z^2-27*y^2*z^4-162*y*z^5+81*z^6-y^4,
27*x*z^6+3*y^5+18*y^4*z-9*y^3*z^2-27*y*z^4-162*z^5-y^3,
9*x^2*z^6-54*x*z^5+3*y^4+18*y^3*z-9*y^2*z^2-27*z^4-y^2,
3*x^3*z^6-18*x^2*z^5-9*x*z^4+3*y^3+18*y^2*z-9*y*z^2-y,
x^4*z^6-6*x^3*z^5-3*x^2*z^4+3*y^2+18*y*z-9*z^2-1
])
s = R.ideal([x*y+1,
-4,
-2*x*y-2,
-2*y^3-2*y^2*z-2*y*z^2-2*z^3-2*y^2,
-2*x*z^3+2*y^2+2*y*z+2*z^2+2*y,
-x*y+3,
-3*y^6-18*y^5*z+9*y^4*z^2+27*y^2*z^4+162*y*z^5-81*z^6+y^4,
-27*x*z^6-3*y^5-18*y^4*z+9*y^3*z^2+27*y*z^4+162*z^5+y^3,
-9*x^2*z^6+54*x*z^5-3*y^4-18*y^3*z+9*y^2*z^2+27*z^4+y^2
]);
from sage.libs.singular.function import lib as singular_lib
from sage.libs.singular.function import singular_function assingular_function
singular_lib('primdec.lib')
syz = singular_function("syz")
syzI = syz(I) # ok
# check syzI (I'm not sure if I do it correctly...)
matrix([list(x) for x in syzI])*transpose(matrix(gens(I)))
syz(s) # have fun
The syz(s) call will eat up all your memory very fast.
I tried the same in another CAS (Macaulay2) without problems.
If the results are correct (are there some tests out there) ,
its probably ok to leave it as it is, but I would like a replacement.
Any suggestions?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: patchbot problem?
Thats a race in the dev scripts, see http://trac.sagemath.org/ticket/14482#comment:158 On Monday, November 18, 2013 12:05:39 AM UTC-5, Nils Bruin wrote: > > I noticed a failed doctest report by a patchbot: > > > http://patchbot.sagemath.org/log/15432/Ubuntu/12.10/x86_64/3.5.0-17-generic/pi/2013-11-17%2018:44:09%20-0800 > > which I could reproduce on my own computer with 5.13b2 by pulling the > branch and doing sage -b. > However, after issuing `make` the doctest succeeded (well, it timed out, > but sage -t --long succeeded). Does that indicate an error in dependency > tracking in sage -b? How do you know if running sage -b is enough or when a > full make is required? > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: xrange vs. xsrange
On Mon, Nov 18, 2013 at 7:15 AM, Volker Braun wrote: > The [...] * n construct creates a list with n identical entries (NOT: n > copies). You can't construct the cartesian product with a single generator, > you need copies: This isn't the full story, since the code works fine with xrange. The problem is that the xsrange code is caching iter(...), but the code Joel Mohler for multi-range iteration assumes that the iterator is not cached. Consider: sage: v = xsrange(2) sage: iv = iter(v) sage: iv2 = iter(v) sage: iv is iv2 True # ugh -- wrong sage: iv.next() 0 sage: iv2.next() 1 # WRONG sage: iv.next() Traceback # WRONG StopIteration As compared to: sage: v = xrange(2) sage: iv = iter(v) sage: iv2 = iter(v) sage: iv is iv2 False sage: iv.next() 0 sage: iv2.next() 0# right sage: iv.next() 1# right For example, this is a reasonable thing to write in code: sage: v = xsrange(3) sage: [(i,j) for i in v for j in v] [(0, 1), (0, 2)]# totally wrong Why is this happening? The actual code for xsrange just uses yield (and a closure), i.e., it's basically the following: def f(): for k in xrange(3): yield k Note that: sage: a = f() sage: s1 = iter(a) sage: s2 = iter(a) sage: s1 is s2 True # bad I think xsrange should be rewritten to not use yield, but use a class with an __iter__ method. I did some hg blaming and that xsrange codes been pushed around for a while; things have been like this in sage for a long time. - William -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: xrange vs. xsrange
The [...] * n construct creates a list with n identical entries (NOT: n copies). You can't construct the cartesian product with a single generator, you need copies: sage: x = xsrange(2) sage: y = x sage: x.next() 0 sage: y.next() 1 sage: x.next() --- StopIteration Traceback (most recent call last) in () > 1 x.next() StopIteration: On Monday, November 18, 2013 7:12:49 AM UTC-5, John Cremona wrote: > > sage: len(list(cartesian_product_iterator([xsrange(2)]*3))) > 0 > sage: len(list(cartesian_product_iterator([xrange(2)]*3))) > 8 > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: xrange vs. xsrange
On Monday, November 18, 2013 7:12:49 AM UTC-5, John Cremona wrote: > > Why the difference here? > > sage: len(list(cartesian_product_iterator([xsrange(2)]*3))) > 0 > sage: len(list(cartesian_product_iterator([xrange(2)]*3))) > 8 > > I thought that xsrange was a simple plugin-in replacement for xrange, > but yielding Sage integers instead of ints. But it seems as if there > are more differences! > > Well, the types are subtly different. sage: xsrange(2) sage: type(_) sage: type(xrange(2)) and since the Cartesian thingie uses xmrange_iter under the hood, which More precisely, return the iterator over all objects of type typ of n-tuples of Python ints with entries between 0 and the integers in the sizes list. The iterator is empty if sizes is empty or contains any non-positive integer. Notice the following does work. sage: list(cartesian_product_iterator([list(xsrange(2))]*3)) [(0, 0, 0), (0, 0, 1), (0, 1, 0), (0, 1, 1), (1, 0, 0), (1, 0, 1), (1, 1, 0), (1, 1, 1)] so it has to be something about the generator - note that xm... uses _xmrange_iter under ITS hood, so who knows where the regress ends. I'd investigate more but I have to go teach :) but I figure you'll be able to track it down pretty quickly. - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Adding a patch to a closed ticket not yet released
On 18 November 2013 12:52, Jeroen Demeyer wrote: > On 2013-11-18 13:42, John Cremona wrote: >> >> This is really a question for Jeroen, as release manager. for 5.13: >> >> Ticket #13615 was merged into 5.13.beta0 after positive review. This >> morning a student of mine found a small bug, which I have sorted out >> in a 1-line bugfix (plus 5 lines for a new doctest). I have a patch >> for that. >> >> Should I add that patch to the ticket? I don't think I have the right >> to un-close it. Or should I open a new ticket with a reference added >> to #13615 for the extra patch? >> >> Obviously I would like to get my bugfix positively reviewed and into >> 5.13, and want to avoid at all costs the possibility of the already >> merged patches at #13615 being kicked out (perhaps on the dubious >> grounds that there may be more bugs: that's always true!). > > > A closed ticket should never be re-opened, simply create a new ticket and > put cross-references in the ticket description both ways. Done: #15434 needing review. Thanks, John > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Adding a patch to a closed ticket not yet released
On 2013-11-18 13:42, John Cremona wrote: This is really a question for Jeroen, as release manager. for 5.13: Ticket #13615 was merged into 5.13.beta0 after positive review. This morning a student of mine found a small bug, which I have sorted out in a 1-line bugfix (plus 5 lines for a new doctest). I have a patch for that. Should I add that patch to the ticket? I don't think I have the right to un-close it. Or should I open a new ticket with a reference added to #13615 for the extra patch? Obviously I would like to get my bugfix positively reviewed and into 5.13, and want to avoid at all costs the possibility of the already merged patches at #13615 being kicked out (perhaps on the dubious grounds that there may be more bugs: that's always true!). A closed ticket should never be re-opened, simply create a new ticket and put cross-references in the ticket description both ways. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Adding a patch to a closed ticket not yet released
This is really a question for Jeroen, as release manager. for 5.13: Ticket #13615 was merged into 5.13.beta0 after positive review. This morning a student of mine found a small bug, which I have sorted out in a 1-line bugfix (plus 5 lines for a new doctest). I have a patch for that. Should I add that patch to the ticket? I don't think I have the right to un-close it. Or should I open a new ticket with a reference added to #13615 for the extra patch? Obviously I would like to get my bugfix positively reviewed and into 5.13, and want to avoid at all costs the possibility of the already merged patches at #13615 being kicked out (perhaps on the dubious grounds that there may be more bugs: that's always true!). John -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] xrange vs. xsrange
Why the difference here? sage: len(list(cartesian_product_iterator([xsrange(2)]*3))) 0 sage: len(list(cartesian_product_iterator([xrange(2)]*3))) 8 I thought that xsrange was a simple plugin-in replacement for xrange, but yielding Sage integers instead of ints. But it seems as if there are more differences! John -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
