Re: [sage-devel] Re: search_methods() to search the methods of an object
On Tue, 19 Oct 2010 at 09:43PM -0700, Nick Alexander wrote: > If you used emacs sage-mode, tab complete would bring up a buffer of > completions for X., which you could then interactively search > (and regexp search), or run M-x occur to find all occurences, etc. In > my opinion, this is more flexible and powerful. I do use sage-mode, though not in any sort of power-user way. For some reason, switching to the completion buffer and searching there usually strikes me as a bit bothersome -- I have to C-x o over to the buffer, do the search, blah blah -- but you're right, it is a flexible and powerful way to work. Looks like I need to learn me some more emacs... > In my haste to plug sage-mode, I forgot this: > > sage: X.*foo*? > ... > all methods that match 'foo'. > > Only in IPython (and therefore sage-mode), of course. Now that you mention it, I have seen people mention this before, and it does exactly what I want. So forget about my "search_methods" business. I need to learn more IPython too... Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] Re: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On Tue, 19 Oct 2010 09:09 -0700 kcrisman wrote: > Maybe it's time to relieve the strain on sagenb by publicizing more of > the other 'semi-secret' servers like David mentions. But that would be > up to the people in charge of them. The two servers running at http://sagenb.kaist.ac.kr/ are usually pretty idle: dr...@sagenb:~$ w 13:47:13 up 41 days, 5:28, 2 users, load average: 0.22, 0.12, 0.09 That's an 8-core machine, and I would be happy to report to my department head that it's used often. If anyone would like a bunch of accounts, let me know. Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] Re: search_methods() to search the methods of an object
> How about a function, somewhat like search_doc, search_def, and friends, > that accepts an object and a string, and returns methods that match that > string? Would you find that useful? In my haste to plug sage-mode, I forgot this: sage: X.*foo*? ... all methods that match 'foo'. Only in IPython (and therefore sage-mode), of course. Nick -- 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: search_methods() to search the methods of an object
> How about a function, somewhat like search_doc, search_def, and friends, > that accepts an object and a string, and returns methods that match that > string? Would you find that useful? I think this is a good idea, but can't resist... > Often, I find myself doing > > X.a (look through "a" methods...) > X.b (look through "b" methods...) > > and so on, through the alphabet. This is annoying. I don't like things > that are annoying. If you used emacs sage-mode, tab complete would bring up a buffer of completions for X., which you could then interactively search (and regexp search), or run M-x occur to find all occurences, etc. In my opinion, this is more flexible and powerful. Nick -- 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] search_methods() to search the methods of an object
Here's something that happens to me: I have an object X that has a *lot* of methods -- matrices and graphs, often -- and I'm wondering if X has a certain method. Often, I find myself doing X.a (look through "a" methods...) X.b (look through "b" methods...) and so on, through the alphabet. This is annoying. I don't like things that are annoying. How about a function, somewhat like search_doc, search_def, and friends, that accepts an object and a string, and returns methods that match that string? Would you find that useful? Here's what I just wrote. Try dropping this into sage/misc/sagedoc.py, and adding search_methods to all.py in that directory: def search_methods(x, s): r""" Given an object x and a string s, this returns a list of methods of x that contain s. A better version of this would have an option to include or exclude methods that begin with an underscore, do proper regexps, etc. """ return [m for m in dir(x) if s in m] Then you get: sage: m = matrix(2, [1,2,3,4]) sage: search_methods(m, 'kernel') ['_decomposition_using_kernels', '_kernel_matrix_using_padic_algorithm', '_kernel_matrix_using_pari', '_rational_kernel_iml', '_right_kernel_matrix', '_right_kernel_trivial', 'integer_kernel', 'kernel', 'kernel_matrix', 'kernel_on', 'left_kernel', 'right_kernel'] sage: g = graphs.PetersenGraph() sage: search_methods(g, 'loop') ['allow_loops', 'allows_loops', 'has_loops', 'loop_edges', 'loop_vertices', 'loops', 'number_of_loops', 'remove_loops'] Thoughts? Should I open a ticket for this? Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
Re: [sage-devel] Re: bug wranglers
On 10/19/10 05:06 PM, kcrisman wrote: I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's not clear to me that without a specific time and place to do so, that it would be particularly effective to spend 20-50 hours reading books about this. I don't have much experience to say whether you are right or wrong. I do *not* have a software background. I have never done any sort of computer science degree. However, I had had to write code which others will use, and it became clear to me that on a large project one needs to do a bit more than just writing the code. Based on my experience, I feel that 20-50 hours reading about what are good software engineering practices would be useful. Those are just as relevant if you code in C, assembler, Python or foobar. Software seems to be one of those things that is hard to really learn how to do without actually doing it. My main point was not about the code one writes. Clearly if you write in Python you should know about Python, but that's another matter altogether. I tend to agree that one of of the best ways to learn a language, is to use it. Things that I believe would be good for Sage, and one could get some useful understanding in 20-50 hours from a software engineering book would be: * An understanding of how software projects should be managed. This is especially so for William of course, but in general I think that's useful to know for all of us. To a certain extent, some trac tickets have to be "managed". * An understanding of why bugs should be fixed as early as possible. * Understanding the different sorts of tests that software developers use - black box testing, white box testing etc. * Automated testing tools. * Understanding ways to estimate the quality of code. At the moment there is no analysis of defect rates in Sage. * The life-cycle of software. Analysis -> Design -> Code -> Test -> Maintenence. This applies to Sage as a whole, but also to individual parts of Sage. * An understanding of why software wears out. What can we do to reduce the rate of wearout? 10-20 hours spent trying to do some Sage development, but with a couple quality software engineers looking over your shoulder the whole time, might do it. That's an entirely different thing - I'm not talking about that. Any course on software engineering is not likely to have you writing code with someone looking over your shoulder. The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. To be sure, this is a design decision of sorts, and one at odds with your books, perhaps. But unless we also can operate under the implicit assumptions of them (which probably include things like actual employers, or perhaps a pool of developers who all have similar skill sets - neither of which is the case here, in a project which is monstrously diverse in terms of skill needs and obviously very non- hierarchical), I don't see how it's feasible to implement your ideas on this, other than the reminders of good practice you give in public fora such as this and on Trac tickets. Which I think that is having a positive impact, incidentally! :) - kcrisman The fact people have different skill sets, the fact we are not employed, the fact there is essentially non-hierarchical, does not really change things too much. Some aspects obviously do, as you can't demand people do what you want when you don't pay them. But hopefully people more people would do things better if they were aware of good practices. 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: organized ticket reports page
Nice! Unfortunately the top link for "View Tickets" doesn't point there, although the "View Ticket Lists" one in the main page does. Can there be a "My Tickets (active, by component)" one as well? Hopefully this will help the Trac become more organized. Maybe there could also be a "New Tickets (last week) (last month)" as well, apropos of the Bug Squashers Team thread on sage-devel. Totally on another topic, but related, is anyone (Harald? David J.?) going to figure out what to do with the web interface to the Google groups now that they're "retiring" the welcome messages? Those were very useful for people wanting to click through to the other lists, as well as wanting to know what a particular list was about. We may need to put more details about their purposes on the regular Sage page that sends people to them. - kcrisman On Oct 19, 7:38 pm, Jason Grout wrote: > I made a page that lists the ticket reports in a more organized fashion: > > http://trac.sagemath.org/sage_trac/wiki/TicketReports > > Enjoy! > > Jason -- 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] organized ticket reports page
I made a page that lists the ticket reports in a more organized fashion: http://trac.sagemath.org/sage_trac/wiki/TicketReports Enjoy! Jason -- 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: Make Parma Polyhedra Library a standard spkg
Gfan does a lot more than compute the Groebner fan. My main use for it is computing tropical prevarieties. Anders Jensen keeps improving gfan, and in fact our interface to it doesn't wrap all the current functionality. I think it would be quite a job to replace it. -Marshall On Oct 19, 11:53 am, Volker Braun wrote: > gfan definitely depends on cddlib. > > Unless it is somehow broken I would keep sage.geometry.groebner_fan > and the gfan spkg for now. In the long term we should rewrite > sage.geometry.groebner_fan to work with the new Fan class from the > toric geometry stuff. And I think it would be easy enough to take > Singular's groebner fan code (which uses polymake internally) and > replace its use of cddlib and TOPCOM with Sage's Cone/Fan and > triangulation code. Then we wouldn't need gfan any more... -- 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: Make Parma Polyhedra Library a standard spkg
I strongly object to removing gfan. -Marshall On Oct 19, 9:53 am, William Stein wrote: > On Tue, Oct 19, 2010 at 6:35 AM, mhampton wrote: > > I support replacing cddlib with PPL for the default computation of > > exact polyhedra. > > Does gfan depend on cddlib? If we remove cddlib, would we then also have to > remove gfan? From deps: > > $(INST)/$(GFAN): $(BASE) $(INST)/$(MPIR) $(INST)/$(CDDLIB) > $(INSTALL) "$(SAGE_SPKG) $(GFAN) 2>&1" "tee -a > $(SAGE_LOGS)/$(GFAN).log" > > I would personally be fine with removing gfan, unless some people strongly > object. > > > > > > > Eventually I would really like to see lrs as a standard component as > > well, because: > > 1) It is small and compiles on all our supported platforms. > > 2) David Avis has always been very responsive to any emails about lrs. > > 3) It uses a very different algorithm from PPL; sometimes it performs > > much better, and always with relatively little memory use. > > 4) It has been an optional package for a couple of years now, with no > > known problems. > > > PPL can be the default, ideally with lrs as an optional backend. > > > For numerical polytopes we should keep cddlib for now. Qhull might be > > the better long-term choice for numerical polytopes, since it was > > written from the beginning with that in mind. For now I am working on > > Qhull as an optional package (but its not very high on my priority > > list). > > > -Marshall > > > On Oct 18, 7:13 am, Volker Braun wrote: > > > === Introduction === > > > > I would like to have the Parma Polyhedra Library (PPL) included > > > as a standard spkg. My goal is to rewrite as much of the > > > sage.geometry.* modules on top of a Cython PPL wrapper as opposed > > > to piping ASCII to/from cddlib. Some of the reasons are: > > > > * PPL is already faster by itself, and having a Cython wrapper reduces > > > overhead. I'm seeing about 20x speedup on medium-sized problems. > > > > * PPL is the only polyhedral computation toolkit that is from the > > > ground up designed to be used as a shared library.(1) > > > > * PPL is mature, well tested, has an active development including bug > > > tracker and mailing list. It is used in a variety of other projects, > > > including gcc's Graphite loop optimizer. It has been tested on > > > Linux, FreeBSD, OpenBSD, Solaris, IRIX64, Mac OS X, Cygwin, DEC > > > OSF/1. > > > > cddlib was the first really useful software package back in the day > > > and it was hugely influential for many subsequent codes. But nowadays > > > there are alternatives that combine the same algorithms with better > > > implementations and software development practices.(2) > > > > Note that I'm not proposing to remove cddlib entirely. It is still a > > > requirement for gfan and the only program to do polyhedral > > > computations over floating point numbers.(3) > > > > === Work Plan === > > > > I have written a PPL spkg and a Cython (C++) wrapper that should cover > > > all functions necessary for dealing with polyhedra in Sage. You can > > > find it here: > > > >http://trac.sagemath.org/sage_trac/ticket/10039 > > > > Using this wrapper, I patched sage.geometry.cone: > > > >http://trac.sagemath.org/sage_trac/ticket/10140 > > > > I think that the PPL spkg and the Cython wrapper is ready for > > > inclusion in the next Sage release (4.6.1?). In the subsequent release > > > we can then rebase sage.geometry modules on top of the wrapper. > > > > Right now I would like to invite any comments on this plan! > > > > === Notes === > > > > (1) cddlib also comes with a shared library. But its poorly documented > > > and, according to valgrind, leaks memory. Other toolkits like lrs and > > > qhull don't build shared libraries but have minimal instructions for > > > statically linking with parts of their code. > > > > (2) In particular, cddlib has no bug tracker, no new release in the > > > last 5 years, and segfaults on some of its own testsuite. > > > > (3) Though in a numerically unstable way, see Trac #10046, #10037. > > > -- > > 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 Washingtonhttp://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: Make Parma Polyhedra Library a standard spkg
For reference I've put the buildlog here:
http://www.stp.dias.ie/~vbraun/Sage/spkg/ppl-buildlog.txt
There are two related bogus "may be used uninitialized" warnings,
thats all. Actually the warnings look more like a gcc bug, I think it
should have been able to figure out that the variable does get
initialized in the switch{} statement.
The doxygen-documentation also includes the sources, so its easy to
see the cross-referenced implementation:
https://www.cs.unipr.it/ppl/Documentation/devref/ppl-devref-0.11-html/
In my opinion it is very consistent C++ code and generally easy to
follow with lots of useful comments.
When I compiled it on OpenSolaris I used gcc+sun linker. Since the PPL
buildsystem is using libtool there is some hope that either linker
would work, but then I haven't tried.
--
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: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On 19 October 2010 17:55, Jeroen Demeyer wrote: > On 2010-10-19 18:35, Roman Pearce wrote: >> On Oct 19, 9:09 am, kcrisman wrote: >>> Yes, let's keep in mind that notebook servers with fewer users are >>> usually very snappy and a great resource. It's not CPU power, but >>> number of simultaneous users, I think. >> >> That suggests the bottleneck is disk I/O. > Not even that is the bottleneck. > > I have no idea of how the notebook is implemented, but I think that's > really where the problem lies. Probably that code is not written with a > large number of users (even non-simultaneous) in mind. Because a > *second* notebook on the same physical server is much faster than the first. > > Jeroen. I think I know the answer to this one, but I will ask anyway. Is there a document which documents the design and implementation of the notebook? And yes, I am aware the most accurate document is the source code! As a second question, has anyone ever written any code which simulates real users randomly logging in, and doing "normal" things? (Code like this is written to test web servers - see for example http://curl-loader.sourceforge.net/) 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
Re: [sage-devel] Make Parma Polyhedra Library a standard spkg
On 18 October 2010 13:13, Volker Braun wrote: > === Introduction === > > I would like to have the Parma Polyhedra Library (PPL) included > as a standard spkg. My goal is to rewrite as much of the > sage.geometry.* modules on top of a Cython PPL wrapper as opposed > to piping ASCII to/from cddlib. Some of the reasons are: > > * PPL is already faster by itself, and having a Cython wrapper reduces > overhead. I'm seeing about 20x speedup on medium-sized problems. > > * PPL is the only polyhedral computation toolkit that is from the > ground up designed to be used as a shared library.(1) > > * PPL is mature, well tested, has an active development including bug > tracker and mailing list. It is used in a variety of other projects, > including gcc's Graphite loop optimizer. It has been tested on > Linux, FreeBSD, OpenBSD, Solaris, IRIX64, Mac OS X, Cygwin, DEC > OSF/1. >From what you say there, it suggests the code is good quality. But I would suggest an audit is performed and this evaluated. It would be good to avoid code like that of Sympow and some other packages which are very dubious. But my gut feeling is if someone has tested their code on those wide range of platforms, they have probably done a decent job of writing it. But I feel this should be ascertained. Potentially they could assume the use of the GNU linker, which is not good on Solaris. Does the code generate lots of compiler warnings? 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
Re: [sage-devel] Re: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On 2010-10-19 18:35, Roman Pearce wrote: > On Oct 19, 9:09 am, kcrisman wrote: >> Yes, let's keep in mind that notebook servers with fewer users are >> usually very snappy and a great resource. It's not CPU power, but >> number of simultaneous users, I think. > > That suggests the bottleneck is disk I/O. Not even that is the bottleneck. I have no idea of how the notebook is implemented, but I think that's really where the problem lies. Probably that code is not written with a large number of users (even non-simultaneous) in mind. Because a *second* notebook on the same physical server is much faster than the first. Jeroen. -- 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: Make Parma Polyhedra Library a standard spkg
gfan definitely depends on cddlib. Unless it is somehow broken I would keep sage.geometry.groebner_fan and the gfan spkg for now. In the long term we should rewrite sage.geometry.groebner_fan to work with the new Fan class from the toric geometry stuff. And I think it would be easy enough to take Singular's groebner fan code (which uses polymake internally) and replace its use of cddlib and TOPCOM with Sage's Cone/Fan and triangulation code. Then we wouldn't need gfan any more... -- 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: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On Oct 19, 9:09 am, kcrisman wrote: > Yes, let's keep in mind that notebook servers with fewer users are > usually very snappy and a great resource. It's not CPU power, but > number of simultaneous users, I think. That suggests the bottleneck is disk I/O. Sage is quite large, so it's not a surprise. Anything you to slim down the software will make it "snappier" under load, and this is actually true at all levels of the memory hierarchy. Since Sage tries to be inclusive, you might try just slimming down the average case. How many libraries really need to be loaded at startup, etc? This is usually difficult to do. But for public servers it's unavoidable, and for software that runs in a "cloud", bloat = $$$. -- 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: Make Parma Polyhedra Library a standard spkg
On Oct 19, 3:37 pm, Andrey Novoseltsev wrote: > By the way - does PPL use any random numbers like cddlib? I'm pretty sure that it does not randomize the output; certainly grep doesn't find any references to rand(). And there is absolutely no reason to call a pseudo random number generator for the polyhedral algorithms in the first place. -- 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: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On Oct 19, 11:31 am, Jeroen Demeyer wrote: > On 2010-10-19 17:25, Tom Boothby wrote: > > >> Is it really true that the public access servers are often bogged down > >> with lots of users? > > > Yes. Everybody that I talk to is very disappointed with the public > > notebook. > > I totally agree (I'm just coming back from an exercice class where > students tried to usewww.sagenb.organd it was essentially unusable). > However, I think it's more a matter of implementation of the notebook > rather than a problem of CPU power. Yes, let's keep in mind that notebook servers with fewer users are usually very snappy and a great resource. It's not CPU power, but number of simultaneous users, I think. Maybe it's time to relieve the strain on sagenb by publicizing more of the other 'semi-secret' servers like David mentions. But that would be up to the people in charge of them. - 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: bug wranglers
> I was not suggesting anyone spend 10,000 hours studying the subject of > software engeering. I'm not suggesting people need to be experts. But > perhaps spending 20-50 hours on it is not unreasonable. I don't know > about you, but I've probably devoted 1000 hours to working on Sage, so > 20-50 is a small percentage. I think 20-50 hours would be for you > too. It's not clear to me that without a specific time and place to do so, that it would be particularly effective to spend 20-50 hours reading books about this. Software seems to be one of those things that is hard to really learn how to do without actually doing it. 10-20 hours spent trying to do some Sage development, but with a couple quality software engineers looking over your shoulder the whole time, might do it. The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. > "I personally have been burned enough times now by obvious bugs that > have shown up when I try to demonstrate what > I'm doing in sage, that I hesitate now to shares things readily." This probably depends a lot on what mathematics you are doing with Sage, of course. > Currently one person with poor Python skills can review the work of > another with poor Python skills, and the code get committed to Sage. > There's little filtering. Condensed version of much longer response I started with: I often find that people who contact us (and even contact me personally) about this are more likely to not want to contribute *anything*, even very minor bugfixes or documentation improvements, because they are not confident in their skills. Most people who feel confident enough to review are confident enough to point out things that look bad, and those who don't still will often point out something wrong/suboptimal. What happens more often, I think, is that someone with decent/good Python skills is tired or lackadaisical and reviews something they want to get in without spending the 1+ hours it takes to really test edge cases and so forth of a patch also written by someone with decent/ good Python skills who is tired or lackadaisical... etc. Since such a person also contributes and reviews in quality ways most of the time, it's much harder to filter for that. Finally, I think that MANY of the new bugs in Sage are *not* a result of someone destroying old code, but rather of a bug appearing where before there was no functionality! I think that to most Sage developers, it is better to have 99 out of 100 cases give the right answer, and have it tested out and hopefully fix the bug soon that surely is there, than to have a NotImplementedError for years and years. Stagnation is the way to not attract the new developers we would need (for time's sake) to improve our software engineering practice, indeed. To be sure, this is a design decision of sorts, and one at odds with your books, perhaps. But unless we also can operate under the implicit assumptions of them (which probably include things like actual employers, or perhaps a pool of developers who all have similar skill sets - neither of which is the case here, in a project which is monstrously diverse in terms of skill needs and obviously very non- hierarchical), I don't see how it's feasible to implement your ideas on this, other than the reminders of good practice you give in public fora such as this and on Trac tickets. Which I think that is having a positive impact, incidentally! :) - 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
Re: [sage-devel] Re: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On 2010-10-19 17:25, Tom Boothby wrote: >> Is it really true that the public access servers are often bogged down >> with lots of users? > > Yes. Everybody that I talk to is very disappointed with the public notebook. I totally agree (I'm just coming back from an exercice class where students tried to use www.sagenb.org and it was essentially unusable). However, I think it's more a matter of implementation of the notebook rather than a problem of CPU power. Jeroen. -- 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: Wolfram Alpha low bandwidth portal into Sage to attract new users?
> Is it really true that the public access servers are often bogged down > with lots of users? Yes. Everybody that I talk to is very disappointed with the public notebook. -- 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: Wolfram Alpha low bandwidth portal into Sage to attract new users?
On 18 Oct, 15:38, Chris Seberino wrote: > Wolfram Alpha is a low bandwidth portal into Mathematica that doesn't > provide the full notebook interface. It's not in Wolfram Research's interst to make the full power of Mathematica available to anyone for free. If they did, their sales of Mathematica would drop dramatically. > Does something like this exist for Sage? It seems it would be > valuable marketing wise because it is even easier to try that than the > freely available notebook interfaces. The free public notebook > servers are often bogged down with lots of users. Is it really true that the public access servers are often bogged down with lots of users? Try http://t2nb.math.washington.edu:8000/ it's not very fast, but is not bogged down with many users either. I can't imagine there would be much enthusiasm for maintaining a cut- down version of the notebook by Sage developers. > I'm guessing Wolfram Alpha interface would be able to support more > users? > > cs I don't know, but I suspect Wolfram Alpha is designed properly and will be able to support more users by adding computational power to it. The amount of CPU time that a computation can use is limited, so I doubt there is any need to split a computation across several systems for increased performance. So servers don't need to communicate with each other. Adding the power to handle more users with Wolfram Alpha would appear to me to be quite trivial, but I don't know for sure. Dave 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
Re: [sage-devel] Re: bug wranglers
On Tue, Oct 19, 2010 at 8:09 AM, Dr David Kirkby wrote: > If that crashes Sage, and stops lots of people working on a > Sage server, I think that's pretty serious, though not as bad as > incorrect results. It only crashes that one user's session. Each worksheet is run in a different process. --Mike -- 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: bug wranglers
On 18 Oct, 21:33, Robert Bradshaw wrote: > On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby > On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby > > sage: seed(1,2) > > sage: seed(100,34) > > sage: seed(1,2,3,4,5,6,7) > > > will all crash Sage with an "Unhandled SIGSEGV". Plenty more sets of invalid > > input to other commands will hang Sage, so the only answer is to kill the > > process. > > Though in an ideal world, this kind of thing wouldn't crash Sage, I'm > more worried about the kinds of bugs where valid input causes a > segfault, or, much worse, an incorrect answer. Obviously getting incorrect results is the worst possible case bug - especially if the results look believable. If you try to factorise an integer and get a Bessel function as an answer, it is obviously wrong. Some results look reasonable and so are very bad news. I'd also agree getting crashes with valid input is bad, but its a fact of life people do enter invalid input. Sometimes how one uses a function is not very obvious, so using invalid input is going to happen. If that crashes Sage, and stops lots of people working on a Sage server, I think that's pretty serious, though not as bad as incorrect results. > > I think the main problem is ignorance. Good software engineering techniques > > do not form part of mathematics degrees, so most Sage developers are totally > > ignorant of the issues. Then those motivated to find more information soon > > hit the fact that books on this topic are not cheap. I have an 18-year old > > copy of this book, which despite the complaints the 7th edition is out of > > date, I think much of the material would be useful to Sage developers. > > >http://www.amazon.com/Software-Engineering-Practitioners-Approach-Int... > > > There's also plenty of books on software testing. > > >http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&;... > > > Perhaps when William assembles the team in Seattle, he could find the money > > to buy each person a book on software testing. Buy each person a different > > book, then hopefully Sage developers will able to independently review the > > material. Perhaps they each write a Wiki page on what they though was the > > most important things they learned from the book. > > I would submit that practicing good software engineering techniques is > more than a matter of finding the money (and especially time) to read > a good book on it--we all have different priorities on what we can > afford to spend "10,000 hours" on. (Note, I'm not saying it wouldn't > be useful for all of us to learn these things, just that I don't > expect working mathematicians to all find enough time on the side to > become expert software developers as well). > - Robert IMHO, if Sage is every to become a viable alternative to Maple, Mathematica or MATLAB, then practicing good software engineering is an absolute *must* - not an option. (I purposely excluded Magma from that list, as I know nothing about that tool). If you believe that levels of quality equal to those three commercial packages can be achieved without such skills, then we will have to agree to differ. Of course, for some users Sage is no doubt already the best of these packages, but it is unlikely to be so for a mass audience without major changes. I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's a fact of life that you often have to learn new skills. 20-50 hours would not mean taking a week off of work, but reading a book on a train to work, or at night instead of a bit of TV. Expecting a new developer to spend such time would be unreasonable, but then their contributions should in my opinion come under closer scrutiny from those with better knowledge. Mike Witt said above, with reference to the Sage bugs: "I personally have been burned enough times now by obvious bugs that have shown up when I try to demonstrate what I'm doing in sage, that I hesitate now to shares things readily." It's clear to me (and perhaps Mike) the current methodology is not working. I certainly would not hesitate to show people things with MATLAB or Mathematica. If one of these tools did crash, I would not have egg on my face. But with Sage I would. Currently one person with poor Python skills can review the work of another with poor Python skills, and the code get committed to Sage. There's little filtering. I know Kcrisman has said +1 to your comments, so I'd say I'd have to disagree with him too. > On a more practical note, I think it may help things if we actually > used the priority field. Certainly > Blocker: 14 > Critical: 68 > Major: 1609 > Minor: 516 > Trivial: 26 Of course most are "Major" as that is the default. Many
[sage-devel] Re: Make Parma Polyhedra Library a standard spkg
On Oct 19, 8:53 am, William Stein wrote: > Does gfan depend on cddlib? If we remove cddlib, would we then also have to > remove gfan? From deps: I'd rather leave cddlib for polyhedra over RDF until there is an alternative. -- 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: Make Parma Polyhedra Library a standard spkg
On Tue, Oct 19, 2010 at 6:35 AM, mhampton wrote: > I support replacing cddlib with PPL for the default computation of > exact polyhedra. > Does gfan depend on cddlib? If we remove cddlib, would we then also have to remove gfan? From deps: $(INST)/$(GFAN): $(BASE) $(INST)/$(MPIR) $(INST)/$(CDDLIB) $(INSTALL) "$(SAGE_SPKG) $(GFAN) 2>&1" "tee -a $(SAGE_LOGS)/$(GFAN).log" I would personally be fine with removing gfan, unless some people strongly object. > > Eventually I would really like to see lrs as a standard component as > well, because: > 1) It is small and compiles on all our supported platforms. > 2) David Avis has always been very responsive to any emails about lrs. > 3) It uses a very different algorithm from PPL; sometimes it performs > much better, and always with relatively little memory use. > 4) It has been an optional package for a couple of years now, with no > known problems. > > PPL can be the default, ideally with lrs as an optional backend. > > For numerical polytopes we should keep cddlib for now. Qhull might be > the better long-term choice for numerical polytopes, since it was > written from the beginning with that in mind. For now I am working on > Qhull as an optional package (but its not very high on my priority > list). > > -Marshall > > > On Oct 18, 7:13 am, Volker Braun wrote: > > === Introduction === > > > > I would like to have the Parma Polyhedra Library (PPL) included > > as a standard spkg. My goal is to rewrite as much of the > > sage.geometry.* modules on top of a Cython PPL wrapper as opposed > > to piping ASCII to/from cddlib. Some of the reasons are: > > > > * PPL is already faster by itself, and having a Cython wrapper reduces > > overhead. I'm seeing about 20x speedup on medium-sized problems. > > > > * PPL is the only polyhedral computation toolkit that is from the > > ground up designed to be used as a shared library.(1) > > > > * PPL is mature, well tested, has an active development including bug > > tracker and mailing list. It is used in a variety of other projects, > > including gcc's Graphite loop optimizer. It has been tested on > > Linux, FreeBSD, OpenBSD, Solaris, IRIX64, Mac OS X, Cygwin, DEC > > OSF/1. > > > > cddlib was the first really useful software package back in the day > > and it was hugely influential for many subsequent codes. But nowadays > > there are alternatives that combine the same algorithms with better > > implementations and software development practices.(2) > > > > Note that I'm not proposing to remove cddlib entirely. It is still a > > requirement for gfan and the only program to do polyhedral > > computations over floating point numbers.(3) > > > > === Work Plan === > > > > I have written a PPL spkg and a Cython (C++) wrapper that should cover > > all functions necessary for dealing with polyhedra in Sage. You can > > find it here: > > > > http://trac.sagemath.org/sage_trac/ticket/10039 > > > > Using this wrapper, I patched sage.geometry.cone: > > > > http://trac.sagemath.org/sage_trac/ticket/10140 > > > > I think that the PPL spkg and the Cython wrapper is ready for > > inclusion in the next Sage release (4.6.1?). In the subsequent release > > we can then rebase sage.geometry modules on top of the wrapper. > > > > Right now I would like to invite any comments on this plan! > > > > === Notes === > > > > (1) cddlib also comes with a shared library. But its poorly documented > > and, according to valgrind, leaks memory. Other toolkits like lrs and > > qhull don't build shared libraries but have minimal instructions for > > statically linking with parts of their code. > > > > (2) In particular, cddlib has no bug tracker, no new release in the > > last 5 years, and segfaults on some of its own testsuite. > > > > (3) Though in a numerically unstable way, see Trac #10046, #10037. > > -- > 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: Make Parma Polyhedra Library a standard spkg
On Oct 19, 4:37 am, Volker Braun wrote: > Yes, PALP has some useful toric functionality and I think we should > definitely keep it around. But I think the long-term goal should be to > reduce the reliance of the LatticePolytope class on PALP. In > particular enumerating the lattice points is a problem that pops up > frequently enough that an implementation without the dimension > limitations of PALP would be nice. Did you ever figure out which > algorithm PALP uses? I also looked at the source code but I quickly > gave up... No, I didn't. Although as far as I know I read all available documentation on it. I think that so far I needed lattice points only inside reflexive polytopes in dimension up to 6 and in this case PALP limitations do not show up. I also didn't have any need to do it for sequences of polytopes where next elements are computed based on previous ones, so my work-around (all_points) to eliminate extra system call overheads was sufficient. By the way - does PPL use any random numbers like cddlib? I like referencing polytope vertices/points/facets by their numbers and it will be impossible if the order can change from session to session. I don't care about having some specific order - just a fixed one (except that vertices should be listed in the same way in which they were given by the user, I think). -- 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: Make Parma Polyhedra Library a standard spkg
I support replacing cddlib with PPL for the default computation of exact polyhedra. Eventually I would really like to see lrs as a standard component as well, because: 1) It is small and compiles on all our supported platforms. 2) David Avis has always been very responsive to any emails about lrs. 3) It uses a very different algorithm from PPL; sometimes it performs much better, and always with relatively little memory use. 4) It has been an optional package for a couple of years now, with no known problems. PPL can be the default, ideally with lrs as an optional backend. For numerical polytopes we should keep cddlib for now. Qhull might be the better long-term choice for numerical polytopes, since it was written from the beginning with that in mind. For now I am working on Qhull as an optional package (but its not very high on my priority list). -Marshall On Oct 18, 7:13 am, Volker Braun wrote: > === Introduction === > > I would like to have the Parma Polyhedra Library (PPL) included > as a standard spkg. My goal is to rewrite as much of the > sage.geometry.* modules on top of a Cython PPL wrapper as opposed > to piping ASCII to/from cddlib. Some of the reasons are: > > * PPL is already faster by itself, and having a Cython wrapper reduces > overhead. I'm seeing about 20x speedup on medium-sized problems. > > * PPL is the only polyhedral computation toolkit that is from the > ground up designed to be used as a shared library.(1) > > * PPL is mature, well tested, has an active development including bug > tracker and mailing list. It is used in a variety of other projects, > including gcc's Graphite loop optimizer. It has been tested on > Linux, FreeBSD, OpenBSD, Solaris, IRIX64, Mac OS X, Cygwin, DEC > OSF/1. > > cddlib was the first really useful software package back in the day > and it was hugely influential for many subsequent codes. But nowadays > there are alternatives that combine the same algorithms with better > implementations and software development practices.(2) > > Note that I'm not proposing to remove cddlib entirely. It is still a > requirement for gfan and the only program to do polyhedral > computations over floating point numbers.(3) > > === Work Plan === > > I have written a PPL spkg and a Cython (C++) wrapper that should cover > all functions necessary for dealing with polyhedra in Sage. You can > find it here: > > http://trac.sagemath.org/sage_trac/ticket/10039 > > Using this wrapper, I patched sage.geometry.cone: > > http://trac.sagemath.org/sage_trac/ticket/10140 > > I think that the PPL spkg and the Cython wrapper is ready for > inclusion in the next Sage release (4.6.1?). In the subsequent release > we can then rebase sage.geometry modules on top of the wrapper. > > Right now I would like to invite any comments on this plan! > > === Notes === > > (1) cddlib also comes with a shared library. But its poorly documented > and, according to valgrind, leaks memory. Other toolkits like lrs and > qhull don't build shared libraries but have minimal instructions for > statically linking with parts of their code. > > (2) In particular, cddlib has no bug tracker, no new release in the > last 5 years, and segfaults on some of its own testsuite. > > (3) Though in a numerically unstable way, see Trac #10046, #10037. -- 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: libpari segfault related to 64bit?
Setting SAGE_CHECK=yes just means that after building the pari
library, the self-test routines are also run. It does not affect Sage
after the new spkg is installed.
John
On Tue, Oct 19, 2010 at 1:32 PM, Jan Groenewald wrote:
> Hi
>
> On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wrote:
>> env SAGE_CHECK=yes ./sage -f
>> http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg
>
> This still caused a segfault for me in dmesg while doctests pass.
> Is SAGE_CHECK supposed to give more output? Where?
> Can I have pari give more output? I'm just guessing wildly here:
>
> r...@capepoint:~#cd /usr/local/src/sage-4.5.3/spkg/standard/
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#tar xjf
> pari-2.3.5.p4.spkg
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#cd pari-2.3.5.p4/
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#grep -ri
> "DEBUGLEVEL = " *
> src/src/language/init.c: DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;
> src/src/language/init.c: if (oldval >= 0) { DEBUGLEVEL = oldval; oldval =
> -1; }
> src/src/language/init.c: { oldval = DEBUGLEVEL; DEBUGLEVEL = val; }
> src/src/functions/programming/default: ("debug",small):small:parens
> DEBUGLEVEL = $2
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#sed -i
> 's/DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;/DEBUGFILES = DEBUGLEVEL = DEBUGMEM
> = 9;/' src/src/language/init.c
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#cd ../
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#sage -spkg
> pari-2.3.5.p4
> Creating Sage package pari-2.3.5.p4
> ...
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#env SAGE_CHECK=yes
> sage -f pari-2.3.5.p4.spkg
> Force installing pari-2.3.5.p4.spkg
> ...
> Finished installing pari-2.3.5.p4.spkg
> r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#dmesg|grep segfault|wc
> -l; sage -t devel/sage/sage/interfaces/sage0.py; dmesg|grep segfault
> 0
> sage -t "devel/sage/sage/interfaces/sage0.py"
> [18.2 s]
>
> --
> All tests passed!
> Total time for all tests: 18.2 seconds
> [79234.381854] python[17992]: segfault at 7200ae ip 7f3fce620fa1 sp
> 7fff0a28cbe0 error 4 in libpari-gmp.so.2[7f3fce42c000+2c6000]
>
> Even if it is slow, is there a way to tell pari to write some output
> somewhere?
>
> regards,
> Jan
> --
> .~.
> /V\ Jan Groenewald
> /( )\ www.aims.ac.za
> ^^-^^
>
> --
> 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
>
--
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: libpari segfault related to 64bit?
Hi
On Sun, Oct 17, 2010 at 07:16:58PM +0200, Jeroen Demeyer wrote:
> env SAGE_CHECK=yes ./sage -f
> http://sage.math.washington.edu/home/release/sage-4.6.alpha3/sage-4.6.alpha3/spkg/standard/pari-2.4.3.svn-12577.p7.spkg
This still caused a segfault for me in dmesg while doctests pass.
Is SAGE_CHECK supposed to give more output? Where?
Can I have pari give more output? I'm just guessing wildly here:
r...@capepoint:~#cd /usr/local/src/sage-4.5.3/spkg/standard/
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#tar xjf
pari-2.3.5.p4.spkg
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#cd pari-2.3.5.p4/
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#grep -ri
"DEBUGLEVEL = " *
src/src/language/init.c: DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;
src/src/language/init.c:if (oldval >= 0) { DEBUGLEVEL = oldval; oldval =
-1; }
src/src/language/init.c:{ oldval = DEBUGLEVEL; DEBUGLEVEL = val; }
src/src/functions/programming/default: ("debug",small):small:parens
DEBUGLEVEL = $2
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#sed -i
's/DEBUGFILES = DEBUGLEVEL = DEBUGMEM = 0;/DEBUGFILES = DEBUGLEVEL = DEBUGMEM =
9;/' src/src/language/init.c
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard/pari-2.3.5.p4#cd ../
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#sage -spkg pari-2.3.5.p4
Creating Sage package pari-2.3.5.p4
...
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#env SAGE_CHECK=yes sage
-f pari-2.3.5.p4.spkg
Force installing pari-2.3.5.p4.spkg
...
Finished installing pari-2.3.5.p4.spkg
r...@capepoint:/usr/local/src/sage-4.5.3/spkg/standard#dmesg|grep segfault|wc
-l; sage -t devel/sage/sage/interfaces/sage0.py; dmesg|grep segfault
0
sage -t "devel/sage/sage/interfaces/sage0.py"
[18.2 s]
--
All tests passed!
Total time for all tests: 18.2 seconds
[79234.381854] python[17992]: segfault at 7200ae ip 7f3fce620fa1 sp
7fff0a28cbe0 error 4 in libpari-gmp.so.2[7f3fce42c000+2c6000]
Even if it is slow, is there a way to tell pari to write some output
somewhere?
regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\www.aims.ac.za
^^-^^
--
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: Make Parma Polyhedra Library a standard spkg
On Oct 19, 5:35 am, Andrey Novoseltsev wrote: > As with cddlib, I want to > keep PALP in Sage for computing lattice points inside polytopes as > well as nef partitions, but using PPL as a library for computing > convex hulls and facets will make life much better. Yes, PALP has some useful toric functionality and I think we should definitely keep it around. But I think the long-term goal should be to reduce the reliance of the LatticePolytope class on PALP. In particular, enumerating the lattice points is a problem that pops up frequently enough that an implementation without the dimension limitations of PALP would be nice. Did you ever figure out which algorithm PALP uses? I also looked at the source code but I quickly gave up... -- 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: Make Parma Polyhedra Library a standard spkg
On Oct 19, 5:56 am, Dima Pasechnik wrote: > Are you saying that PPL cannot work with floating point numbers? The short answer is no. The PPL can work with floating point types for some upper-approximations of polyhedral regions. But right now the Cython wrapper only exposes the core functionality for Polyhedra,(1) which always works with gmp/mpir integers.(2) (1) Polyhedra can be both closed (defined by <= inequalities) and "not necessarily closed" (combinations of < and <= inequalities). I don't know any other polyhedral computation code that can do this, certainly not cddlib. (2) Internally all computations are done with mpz_t integers, but point and closure point coordinates can be specified with an overall divisor. So, mathematically, the PPL supports polyhedra over QQ. -- 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
