Re: [sage-devel] Re: Unexpected failure on a test with znpoly
On Mon, Apr 4, 2011 at 5:01 AM, Bill Hart wrote: > Is the problem reproducible? > > If so, a valgrind log would be useful to debug the problem. It should > find the source of any segfault. zn_poly would need to be compiled > with the -g option to GCC. It could of course be a compiler bug. > Possibly compilation with a lower optimisation level would make it > disappear. > > Bill. Bill, Do you know if the zn_poly test suite uses any random numbers? If so, does it use a random time-dependent seed, and if so, does it print out that seed? -- William > > On Apr 3, 6:00 am, "Dr. David Kirkby" wrote: >> I've built Sage tons of time on OpenSolaris as a 32-bit application, and >> rarely >> had any problems for the last 6 months or so. In fact, I've built >> sage-4.7.alpha3 several times without issue. >> >> znpoly is a slightly unusual .spkg in Sage, in that it runs a minimal test >> suite >> irrespective of the setting of SAGE_CHECK. If SAGE_CHECK is set to "yes" >> then it >> runs a more comprehensive set of tests. >> >> But today with the sage-4.7.alpha3 I got a totally unexpected failure. >> >> gcc -g -g -fPIC -O3 -L. >> -I/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/include -I./include >> -DDEBUG -o test/support-DEBUG.o -c test/support.c >> gcc -g -o test/test src/array-DEBUG.o src/invert-DEBUG.o >> src/ks_support-DEBUG.o >> src/mulmid-DEBUG.o src/mulmid_ks-DEBUG.o src/misc-DEBUG.o >> src/mpn_mulmid-DEBUG.o >> src/mul-DEBUG.o src/mul_fft-DEBUG.o src/mul_fft_dft-DEBUG.o >> src/mul_ks-DEBUG.o >> src/nuss-DEBUG.o src/pack-DEBUG.o src/pmf-DEBUG.o src/pmfvec_fft-DEBUG.o >> src/tuning-DEBUG.o src/zn_mod-DEBUG.o test/test-DEBUG.o test/ref_mul-DEBUG.o >> test/invert-test-DEBUG.o test/pmfvec_fft-test-DEBUG.o >> test/mulmid_ks-test-DEBUG.o test/mpn_mulmid-test-DEBUG.o >> test/mul_fft-test-DEBUG.o test/mul_ks-test-DEBUG.o test/nuss-test-DEBUG.o >> test/pack-test-DEBUG.o test/support-DEBUG.o >> -L/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/lib -lgmp -lm >> test/test -quick all >> mpn_smp_basecase()... ok >> mpn_smp_kara()... make[2]: *** [check] Segmentation Fault (core dumped) >> make[2]: Leaving directory >> `/export/home/drkirkby/newdocs/sage-4.7.alpha3/spkg/build/zn_poly-0.9.p5/sr >> c' >> Error running zn_poly's quick test suite (make check). >> >> real 5m41.143s >> user 1m8.034s >> sys 0m5.595s >> sage: An error occurred while installing zn_poly-0.9.p5 >> >> After I typed "make again" I see: >> >> Successfully installed zn_poly-0.9.p5 >> >> So for some unknown reason, znpoly has failed to pass the self-tests, when >> I've >> probably built it 100 times before and it passed each time. >> >> As usual, I checked the system log and see nothing to indicate the system >> had a >> problem like a memory error, disk error, lack of swap space etc. >> >> Dave > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] random() and the random module
On Sun, Apr 3, 2011 at 7:01 PM, D. M. Monarres wrote: > Was working on some code that required the random shuffling of the order of > a list and noticed that there was both a random() function implemented in > the sage library and a random module in the python standard library. > Importing the latter seems to overwrite the former and I was wondering if > that was done deliberately. Yes. There is a Sage module sage.misc.prandom that defines very similar random functions as the standard library random function, and *all* of those functions are imported by default. However, the Sage ones play better with the set_random_seed function in Sage. E.g., sage: set_random_seed(0); sage.misc.prandom.randint(0,10) 1 sage: set_random_seed(0); sage.misc.prandom.randint(0,10) 1 sage: set_random_seed(0); sage.misc.prandom.randint(0,10) 1 sage: import random sage: set_random_seed(0); random.randint(0,10) 1 sage: set_random_seed(0); random.randint(0,10) 8 As you can see, if you want to use the set_random_seed function, which works with essential all the different random number generators in Sage (and its components), then you better use sage.misc.prandom, rather than Python's random. Also, for comparison: sage: sage.misc.prandom. sage.misc.prandom.betavariatesage.misc.prandom.paretovariate sage.misc.prandom.choice sage.misc.prandom.randint sage.misc.prandom.current_randstate sage.misc.prandom.random sage.misc.prandom.expovariatesage.misc.prandom.randrange sage.misc.prandom.gammavariate sage.misc.prandom.sample sage.misc.prandom.gauss sage.misc.prandom.shuffle sage.misc.prandom.getrandbitssage.misc.prandom.uniform sage.misc.prandom.lognormvariate sage.misc.prandom.vonmisesvariate sage.misc.prandom.normalvariate sage.misc.prandom.weibullvariate sage: import random sage: random. random.BPF random.division random.random random.LOG4 random.expovariate random.randrange random.NV_MAGICCONSTrandom.gammavariate random.sample random.RECIP_BPFrandom.gaussrandom.seed random.Random random.getrandbits random.setstate random.SG_MAGICCONSTrandom.getstate random.shuffle random.SystemRandom random.jumpaheadrandom.triangular random.TWOPIrandom.lognormvariate random.uniform random.WichmannHill random.normalvariaterandom.vonmisesvariate random.betavariate random.paretovariaterandom.weibullvariate random.choice random.randint > > -- > D. M. Monarres > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: random() and the random module
Just a note: the Sage versions rely on the Python random module. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Unexpected failure on a test with znpoly
On 04/ 4/11 01:01 PM, Bill Hart wrote: Is the problem reproducible? I'll have to check how reproducible it is by building znpoly repeatedly. But it's the first failure I've known in what must be more than 100 compete builds of Sage on this machine. znpoly is only taking 39 s to build and run the short test suite, so if I run it for a day, I can build+test it 2200 times. The more comprehensive test suite takes several minutes. But I've built Sage on this machine perhaps 100 times now, and the buildbot uses it too. So far only one failure. If so, a valgrind log would be useful to debug the problem. Valgrind is not supported on this operating system. It should find the source of any segfault. zn_poly would need to be compiled with the -g option to GCC. It could of course be a compiler bug. Possibly compilation with a lower optimisation level would make it disappear. It could be. Whatever it is, it a rare failure, though just how rare I don't know now. The program is compiled with -O3, so plenty of scope for reducing that. The package compiles without any warnings at all, though the -Wall option is not added. Had parallel builds been enabled in the package, I might have put it down to a race condition, but they are not, so it can't be that. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Fwd: Monte Carlo Methods in Sage Lectures in YouTube PlayList
Lots of videos/screencasts using Sage... -- Forwarded message -- From: Raazesh Sainudiin Date: Mon, Apr 4, 2011 at 12:07 PM Subject: Monte Carlo Methods in Sage Lectures in YouTube PlayList To: William Stein Dear William, Due to the earthquake in Christchurch several courses including my Sage-based course are doing video lectures. I have put wine in Youtube playlist if it can be of use to others in the Sage-learning community: http://www.youtube.com/user/raazeshsainudiin#g/c/4DDB9E61C36E6DE6 My Course URL is: http://www.math.canterbury.ac.nz/~r.sainudiin/courses/STAT221/index.shtml Cheers, Raaz p.s. I find Screenflow much better than iMovie to make screen captures in various conveniently compressed forms. -- Raazesh Sainudiin Lecturer in Statistics Department of Mathematics and Statistics University of Canterbury Private Bag 4800 Christchurch New Zealand Telephone: +64-3-364 2987, Extn 7691 Fascimile: +64-3-364 2587 r.sainud...@math.canterbury.ac.nz www.math.canterbury.ac.nz/~r.sainudiin -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Anyone mind global Jacobi symbol function?
Currently we have legendre_symbol and kronecker_symbol in the global namespace. Anyone mind having jacobi_symbol as an alias for kronecker_symbol but raising an error for 'wrong' input? Thanks, - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Open Source Corner at MathFest
On 4/3/11 11:08 PM, Rob Beezer wrote:
A friend of mine, Nicole Allen, runs the Student Public Interest
Research Group's "Affordable Textbook Campaign." Her job title is
"Textbook Advocate" - how cool is that?
Part of her job is promoting open source textbooks (how much more
affordable can you get?). She is plotting to have a booth at the US
summer math meetings ("Mathfest", Lexington, Kentucky, Aug 4-6 [1])
and is soliciting other organizations to join her in an "Open Source
Corner" that MAA will accommodate if there is interest.
The Sage Foundation has financially sponsored booths before. Speaking
with interested faculty, students and others at these meetings is
always interesting. [2] (With enough warning, I'd do a reorder on
stickers.)
I don't plan to attend these meetings, but if anybody else would like
to get involved, I can get you connected with Nicole. If you know of
other organizations that might want to join in let me know and I can
pass that along, too.
As of right now, I am planning on being at the MathFest meeting. Is
anyone else planning on being there?
Jason
--
Jason Grout
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Unexpected failure on a test with znpoly
Is the problem reproducible? If so, a valgrind log would be useful to debug the problem. It should find the source of any segfault. zn_poly would need to be compiled with the -g option to GCC. It could of course be a compiler bug. Possibly compilation with a lower optimisation level would make it disappear. Bill. On Apr 3, 6:00 am, "Dr. David Kirkby" wrote: > I've built Sage tons of time on OpenSolaris as a 32-bit application, and > rarely > had any problems for the last 6 months or so. In fact, I've built > sage-4.7.alpha3 several times without issue. > > znpoly is a slightly unusual .spkg in Sage, in that it runs a minimal test > suite > irrespective of the setting of SAGE_CHECK. If SAGE_CHECK is set to "yes" then > it > runs a more comprehensive set of tests. > > But today with the sage-4.7.alpha3 I got a totally unexpected failure. > > gcc -g -g -fPIC -O3 -L. > -I/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/include -I./include > -DDEBUG -o test/support-DEBUG.o -c test/support.c > gcc -g -o test/test src/array-DEBUG.o src/invert-DEBUG.o > src/ks_support-DEBUG.o > src/mulmid-DEBUG.o src/mulmid_ks-DEBUG.o src/misc-DEBUG.o > src/mpn_mulmid-DEBUG.o > src/mul-DEBUG.o src/mul_fft-DEBUG.o src/mul_fft_dft-DEBUG.o src/mul_ks-DEBUG.o > src/nuss-DEBUG.o src/pack-DEBUG.o src/pmf-DEBUG.o src/pmfvec_fft-DEBUG.o > src/tuning-DEBUG.o src/zn_mod-DEBUG.o test/test-DEBUG.o test/ref_mul-DEBUG.o > test/invert-test-DEBUG.o test/pmfvec_fft-test-DEBUG.o > test/mulmid_ks-test-DEBUG.o test/mpn_mulmid-test-DEBUG.o > test/mul_fft-test-DEBUG.o test/mul_ks-test-DEBUG.o test/nuss-test-DEBUG.o > test/pack-test-DEBUG.o test/support-DEBUG.o > -L/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/lib -lgmp -lm > test/test -quick all > mpn_smp_basecase()... ok > mpn_smp_kara()... make[2]: *** [check] Segmentation Fault (core dumped) > make[2]: Leaving directory > `/export/home/drkirkby/newdocs/sage-4.7.alpha3/spkg/build/zn_poly-0.9.p5/sr c' > Error running zn_poly's quick test suite (make check). > > real 5m41.143s > user 1m8.034s > sys 0m5.595s > sage: An error occurred while installing zn_poly-0.9.p5 > > After I typed "make again" I see: > > Successfully installed zn_poly-0.9.p5 > > So for some unknown reason, znpoly has failed to pass the self-tests, when > I've > probably built it 100 times before and it passed each time. > > As usual, I checked the system log and see nothing to indicate the system had > a > problem like a memory error, disk error, lack of swap space etc. > > Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Patch submitting procedures
On Apr 4, 1:13 pm, William Stein wrote: > Great idea! Post a ticket. This is now #11121 and awaits review :) -Keshav -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] doc builder
Hi! I am just looking at doc/common/sage_autodoc.py, and I notice that the documentation is obtained by simply taking the __doc__ attribute, if it exists. That is a problem with method decorators that are written in Cython, because __doc__ would always provide the documentation of the decorator, not of the decorated function - even if __doc__ is defined "cdef public str", the attempt to override it has not the expected effect. But there is the sageinspect module. With sage.misc.sageinspect.sage_getdoc or sage.misc.sageinspect._sage_getdoc_unformatted, more is possible: It tries to call a method _sage_doc_ and does not simply rely on __doc__. Question: Is there a clear reason why sage_getdoc should not be used in sage_autodoc.py? Or shall I open a ticket and change it? Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Cython cached method: Why can the name be imported in a sage session, but not in sage/doc/common/builder.py?
On 4 Apr., 08:26, Simon King wrote:
> 1) cdef classes inheriting from Parent or Element can be provided with
> cached methods, even if they do not allow attribute assignment.
To be precise: They can not be defined in the Cython code, but it will
be possible to provide them via cached parent methods or cached
element methods from the category framework. Currently, "cached"
methods inherited from the category do somehow work (i.e., they don't
crash), but they are only cached if the object that inherits allows
attribute assignment.
However, I have a question to the Cython experts: How can one get the
argument names of a Cython function/method if the source code is not
available? sage.misc.sageinspect.sage_getargspec does not seem to work
on Cython input given in an interactive session.
Example:
sage: cython('''cpdef test_funct(x,y): return''')
sage: sage_getargspec(test_funct)
Traceback (most recent call last):
...
TypeError: arg is not a code object
Best regards,
Simon
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: lcalc code quality
On 2 April 2011 18:08, Robert Bradshaw wrote: > I think the key point is that there are several metrics for judging > code. Some judge code by how many compiler warnings it produces, or > how standard-abiding it is. Others judge code by clarity of the > expressed algorithm(s). It's hard for me to see how code that produces loads of compiler warnings about unused variables can offer clarity of the algorithm. If you find a variable called "cutoff" which is not used, one is never sure if the code for the cutoff was overlooked, or whether it was not needed. (There was, perhaps still is, a bit of code in Sage which has an unused variable called "cutoff") > Yet others judge code by whether it works > correctly for their domain, or the sophistication of the algorithm, or > its speed. I understand all those. I feel if the speed is slow, if there's nothing better that's open-source, then I don't have a problem with it. Within reason, functionality that is slow is better than no functionality. > All of us weight these factors differently, and I don't > think anyone would consider any of these criteria bad, but we > shouldn't say code is bad because it doesn't satisfy only our choice > of metric. Agreed. But I agree with Volker's comments he posted a day or so ago about code relying on specific header files or compiler features. Such code may be perfectly acceptable for an individual to use on his or her computer, but its incorporation into software that designed to be portable is not a good idea until such time as either an upstream author or a Sage developer has cleaned it up. The particular software under discussion has been the source of several issues I'm aware of: 1) Passing of an assembler option to hide warnings caused a problem on Solaris. http://trac.sagemath.org/sage_trac/ticket/6609 2) This gcc 4.6 issue http://trac.sagemath.org/sage_trac/ticket/10892 3) A Cygwin issue (still unresolved) giving no results http://trac.sagemath.org/sage_trac/ticket/9165 4) Fails to build on HP-UX (admittedly not a high priority platform) http://trac.sagemath.org/sage_trac/ticket/7178 There are a number of tell-tale signs which should have ensured the code had an overhaul before being merged into software like Sage. Currently the latest gcc (4.6.0) is a bit more fussy than previous versions, so 3 pieces of software in Sage have been broken (Singular, Lcalc and PolyBoRi). Lcalc has a workaround, PolyBoRi has been fixed properly and to the best of my knowledge, the Singular problem has not been resolved. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
