[sage-devel] Re: ECL / Maxima / Fedora 14 issues.
On Oct 29, 6:48 pm, Mike Witt wrote: > > Is there any chance of you making any of these machine which do *not* > > run Fedora 13 available to the build bot? There are 5 machines which > > the buildbot uses which runs Fedora 13, but nothing for Fedora 11, 12 > > or 14. > > Well, the one that runs Fedora 13 is the one that has the worst > problems building sage :-) But, anyway, I would love to do that. > The problems amount to things like all my machines are behind > one dynamic address from Quest. Only one machine is guaranteed > to be connected, and so on. > > I don't suppose there's a way I can initiate the "buildbot" > from my end and have the results go to the right place? > > Once I get time to install Fedora 14, I imagine I could at least > make that system available. I suppose that I should try to > understand how the "buildbot" scheme works. Is there one place > you can point me to that describes it pretty well? If so, I > could probably find an hour or two Saturday or Sunday to see > if I can understand its workings and then give you a > more coherent answer. OK, well I did find the documentation on buildbot.net, and if I'm understanding correctly from my brief scan of some of the manual it appears that the communication is initiated from the build slaves. So, I think that means that my machines could be used. So I have two questions: (1) Do the machines have to be available all the time, or can they just be available some of the time. (2) Would someone be willing set this up for me (or at least provide an example "configuration" that works for sage builds on some linux type box) or will I have to *actually* study the buildbot manual until I can figure out how to do that myself. -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
Re: [sage-devel] Re: parsing trac
On Fri, Oct 29, 2010 at 4:03 PM, Jason Grout wrote: > It seems that Mike Hansen had some pretty cool ideas about how to use that > plugin. There's some code at [1] which handles the digest authentication that xmlrpclib doesn't handle by default. With the result of "SageTracServerProxy", you can do the examples at [2]. --Mike [1] http://sage.math.washington.edu/home/mhansen/sagetrac_xmlrpc.py [2] http://trac-hacks.org/wiki/XmlRpcPlugin -- 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: Fwd: Request to review Sagemath Beginners Guide
On 10/29/10 8:22 PM, William Stein wrote: Hi Sage-Devel, I'm curious if people are getting emails like this... (I don't have anything to do with this PacktPub project. Generally, I think it is best for people to write documentation for Sage that can be distributed with Sage, and is organized using Sphinx, etc.) Yes, I got that email. I said I didn't have time right now to review the book. I agree with both you and David that free docs are best, but having a book by Packt lends credibility to Sage. IIRC, Packt sent out a request for someone to write the book a while back. I've never heard of Craig Finch, though. I wonder who he is. 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
Re: [sage-devel] Regression testing
On Fri, Oct 29, 2010 at 4:29 PM, Dr. David Kirkby wrote: > On 10/29/10 10:10 PM, Robert Bradshaw wrote: >> >> On Tue, Oct 26, 2010 at 12:57 AM, Dr. David Kirkby > >>> 'cksum' is a 32-bit checksum. Actually, if used all three sections of the >>> output >>> >>> 1) Checksum >>> 2) Length >>> 3) Filename >>> >>> I feel that should be sufficiently relieable. The probability of a test >>> having the exact same path, checksum and length, while having changed, >>> would >>> be exceeding close to zero. >> >> True, though I bet I could (maliciously) come up with two docstrings >> that have the same checksum given how weak the algorithm is. I don't >> see any advantage to using a weak checksum given that we have Python >> and aren't doing this on a per-file basis (or, I hope, extracting >> doctests with an external shell script). > > What's possible with malicious input is not really of a concern for a > non-security application. The man page says deliberate deception would be > difficult, though not impossible. > > I agree using a stronger algorithm is fine if Python was used to do all > this. It just struck me that was was being contemplated was very complex. I > was tempted to just hack together a 20 line shell script which parsed > ptestlong.log, though one really wants CPU times, not wall times for this to > be of any use whatsoever unless the machine was in an idle state. I think capturing the timings is easy--probably would take less than a 20 line modification to the doctesting infrastructure. What to capture and how to make it useful from run to run is the hard part. Also, I was talking to Craig Citro about this and he had the interesting idea of creating some kind of a "test object" which would be saved and then could be run into future versions of Sage and re-run in. The idea of saving the tests that are run, and then running the exact same tests (rather than worrying about correlation of files and tests) will make catching regressions much easier. - Robert >>> >>> Yes, that makes a lot of sense, though unless there a lot of tests, it >>> would >>> be easy to miss problems. >> >> Fortunately, there are a lot of tests :). >> >> - Robert > > But if a new set of tests is written for the benchmark, there would not be > all the current doctests to use, so the number might drop. At least that is > what I thought was talked of. The thread has got a bit long, and I've not > been folowing it closely. I think some tests would be written just for benchmarking, but I think that would be in addition to the current doctests--as much room for improvement as there is, there's no need to throw away all that work and coverage. - Robert -- 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: Has the number of doctests fallen ?
On Oct 24, 1:52 am, David Kirkby wrote: > It used to take about 1800 seconds to doctest Sage on my Sun Ultra 27 > which runs OpenSolaris. That has now dropped to about 1600 seconds in > the latest version (4.6.rc0). > > I've not upgraded the hardware, compiler or other software, so I can't > understand why it should now to take less time to doctest Sage. > I think this might be due to #9798 (Accelerate Polyhedron constructor and fix cddlib output ordering) by Volker Braun. I just noticed that toric_variety_library test has dropped to 90s on sage.math, while it used to take twice as long, I think. In this case it is very likely that almost all modules related to toric geometry got a considerable speed up. Note that if #10039 (Make Parma Polyhedra Library a standard library) gets in, we may get another 200s gain, since using PPL as a library compared to cddlib/PALP as system calls speeds up some lengthy computations tenfold instead of "just" twofold (see #10040 for an example). Thank you, Andrey -- 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] Python 2.7 vs 3.2
There was an interesting comment here about the question of Python 2.8 and the smooth upgrade path. Apparently the only Pythonic path is a 3.2 version. http://sayspy.blogspot.com/2010/10/viewing-python-32-as-successor-to.html -- 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] Fwd: Request to review Sagemath Beginners Guide
On 30 October 2010 02:22, William Stein wrote: > Hi Sage-Devel, > I'm curious if people are getting emails like this... > (I don't have anything to do with this PacktPub project. Generally, I think > it is best for people to write documentation for Sage that can be > distributed with Sage, and is organized using Sphinx, etc.) Clearly there is a need for documentation in Sphinx, but books are very useful too. They are many reasons a professionally bound book beats a PDF one can print out for free. The book "Practical Common Lisp" http://www.gigamonkeys.com/book/ is available as a free PDF, but I'd personally rather buy the book than print out 500 pages and try to bind it myself. I think Sage would gain a bit more creditability if there were books on it published from places like Springer or Wiley. Good luck to anyone that has written a book on Sage. 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] ECL / Maxima / Fedora 14 issues.
Is there any chance of you making any of these machine which do *not* run Fedora 13 available to the build bot? There are 5 machines which the buildbot uses which runs Fedora 13, but nothing for Fedora 11, 12 or 14. Well, the one that runs Fedora 13 is the one that has the worst problems building sage :-) But, anyway, I would love to do that. The problems amount to things like all my machines are behind one dynamic address from Quest. Only one machine is guaranteed to be connected, and so on. I don't suppose there's a way I can initiate the "buildbot" from my end and have the results go to the right place? Once I get time to install Fedora 14, I imagine I could at least make that system available. I suppose that I should try to understand how the "buildbot" scheme works. Is there one place you can point me to that describes it pretty well? If so, I could probably find an hour or two Saturday or Sunday to see if I can understand its workings and then give you a more coherent answer. -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
Re: [sage-devel] Fwd: Request to review Sagemath Beginners Guide
Who the heck is this guy? There's no mention of Sage on his blog http://www.shocksolution.com/about/ On Fri, Oct 29, 2010 at 6:22 PM, William Stein wrote: > Hi Sage-Devel, > I'm curious if people are getting emails like this... > (I don't have anything to do with this PacktPub project. Generally, I think > it is best for people to write documentation for Sage that can be > distributed with Sage, and is organized using Sphinx, etc.) > > Forwarded conversation > Subject: Request to review Sagemath Beginners Guide > > > From: Erika Fernandes > Date: Thu, Oct 28, 2010 at 8:07 PM > To: wst...@gmail.com > > > Hi William Stein, > > I am a Development Editor working with Packt Publishing. We are coming out > with a "Sagemath Beginners Guide" book. I am looking for a Technical > Reviewer to provide feedback on the content of the book. I have just read > your excellent article and it would be of great help if you would be willing > to take it up as this is your area of expertise. > Please visit http://www.packtpub.com/author_reviewing_for_packt for more > details on reviewing. > > When people like yourself, work for us as technical reviewers, we can be > sure that the publishing content will be of the highest quality. > > I should point out that there is no payment for reviewing, instead you will > receive full credit in the book (including a bio where you can include a > link to your website or blog, or write anything about yourself) and 2 free > books-one copy of the book you review and a book of your choice from our > catalog. > > Please let me know if this interests you, so that I can give you more > details on technical reviewing and the book. > > Thanks, > Erika Fernandes > Development Editor | Packt Publishing | www.PacktPub.com > -- > From: William Stein > Date: Thu, Oct 28, 2010 at 8:26 PM > To: Erika Fernandes > > > Who are the authors of the book? > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > From: Erika Fernandes > Date: Fri, Oct 29, 2010 at 2:40 AM > To: wst...@gmail.com > > > Hi William Stein, > > The author of this book is Craig Finch. > > > > -- > 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 > -- 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: Request to review Sagemath Beginners Guide
Hi Sage-Devel, I'm curious if people are getting emails like this... (I don't have anything to do with this PacktPub project. Generally, I think it is best for people to write documentation for Sage that can be distributed with Sage, and is organized using Sphinx, etc.) Forwarded conversation Subject: Request to review Sagemath Beginners Guide From: *Erika Fernandes* Date: Thu, Oct 28, 2010 at 8:07 PM To: wst...@gmail.com Hi William Stein, I am a Development Editor working with Packt Publishing. We are coming out with a "Sagemath Beginners Guide" book. I am looking for a Technical Reviewer to provide feedback on the content of the book. I have just read your excellent article and it would be of great help if you would be willing to take it up as this is your area of expertise. Please visit http://www.packtpub.com/author_reviewing_for_packt for more details on reviewing. When people like yourself, work for us as technical reviewers, we can be sure that the publishing content will be of the highest quality. I should point out that there is no payment for reviewing, instead you will receive full credit in the book (including a bio where you can include a link to your website or blog, or write anything about yourself) and 2 free books-one copy of the book you review and a book of your choice from our catalog. Please let me know if this interests you, so that I can give you more details on technical reviewing and the book. Thanks, Erika Fernandes Development Editor | Packt Publishing | www.PacktPub.com -- From: *William Stein* Date: Thu, Oct 28, 2010 at 8:26 PM To: Erika Fernandes Who are the authors of the book? -- William Stein Professor of Mathematics University of Washington http://wstein.org -- From: *Erika Fernandes* Date: Fri, Oct 29, 2010 at 2:40 AM To: wst...@gmail.com Hi William Stein, The author of this book is Craig Finch. -- 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] Re: Spoof: Sage Misuses
On 29 October 2010 16:48, rjf wrote: > 3. The demand specifically for Mathematica programmers may reflect > the fact that good recruiters are trying to find > smart people who can pass their entrance exam, > and assume that any competent person can learn to limp along in > Mathematica fast, and become more expert as needed. Is there any reason to suggest that would be any different for MATLAB? I personally believe that Mathematica is the harder of the two systems to get to grips with, though as with any non-trivial program, the learning curves are a bit steep, though I'd say Mathematica's is steeper. There are plenty of jobs specifically requiring MATLAB skills, but not that many mentioning Mathematica. The only conclusion I can logically come to is that Mathematica is not widely used in industry, since if it was, there would be more jobs mentioning Mathematica. 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] ECL / Maxima / Fedora 14 issues.
On 10/29/10 07:20 PM, Mike Witt wrote: Is there any chance that Fedora 14 won't be supported? It can't be fully supported until we have the hardware/software set up to test it. I have one FC11 machine, one FC12, and one FC13. FC12 has had no problem with recent Sage builds. FC11 has had minor problems. Even though sage is supported on Fedora 13, *my* fc13 machine (admittedly a rather underpowered one) promptly ceased being able to build ATLAS when I upgraded to fc13. Hence, I've been hesitant to upgrade either of the other machines to fc13. Is there any chance of you making any of these machine which do *not* run Fedora 13 available to the build bot? There are 5 machines which the buildbot uses which runs Fedora 13, but nothing for Fedora 11, 12 or 14. IMHO it would be good if we could support the latest and one or preferably two older versions of an OS. I was hoping things would be better when FC14 came out. Perhaps this is a vain hope? -Mike I'm a bit unimpressed with these backwards incompatible changes. Getting code running on Solaris can be a pain, as a lot of code written is not portable. But once it does work, it stays working. It would be extremely unlikely for an OS upgrade to stop a binary working, and if it did, Sun would have fixed the bug. With Linux, it just seems the norm that when a new release comes out, software that used to work stops functioning. In the last week I've seen tickets for OpenSUSE, ArchLinux and Fedora, all where Sage built on older releases, but does not on newer ones. 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: ECL - test suite and spkg-check file
On 10/30/10 12:57 AM, Volker Braun wrote: I'm definitely in favor of adding ecl's test suite. Assuming that ecl actually passes its self-tests ;) Volker Well, even if it does not, this will not stop Sage building, as the test suite would only be run when SAGE_CHECK=yes. It's 1 AM here, so I'm not going to do anything for some hours at least, but if others feel like us, then I'll add the test suite to the package, and write teh spkg-check file. Dave On Oct 30, 12:37 am, "Dr. David Kirkby" wrote: There's no spkg-check file for ECL, so we can't run ECL's self-tests. In order to do this, we would need to add the tests, which are in a sepparate file (1.7 MB). I'd propose that we add 1) Add the ECL test code 2) Add an spkg-check file so ECL's self-tests can run if SAGE_CHECK=yes. But of course it would add 1.7 MB to the ECL package. There is a ticket to upgrade both Maxima and ECL open now http://trac.sagemath.org/sage_trac/ticket/8731 Adding the self-tests into the package would be quite easy. Then we could run 'make check' from spkg-install. Comments? 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: ECL - test suite and spkg-check file
I'm definitely in favor of adding ecl's test suite. Assuming that ecl actually passes its self-tests ;) Volker On Oct 30, 12:37 am, "Dr. David Kirkby" wrote: > There's no spkg-check file for ECL, so we can't run ECL's self-tests. In order > to do this, we would need to add the tests, which are in a sepparate file > (1.7 MB). > > I'd propose that we add > > 1) Add the ECL test code > 2) Add an spkg-check file so ECL's self-tests can run if SAGE_CHECK=yes. > > But of course it would add 1.7 MB to the ECL package. > > There is a ticket to upgrade both Maxima and ECL open now > > http://trac.sagemath.org/sage_trac/ticket/8731 > > Adding the self-tests into the package would be quite easy. Then we could run > 'make check' from spkg-install. > > Comments? > > 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] ECL - test suite and spkg-check file
There's no spkg-check file for ECL, so we can't run ECL's self-tests. In order to do this, we would need to add the tests, which are in a sepparate file (1.7 MB). I'd propose that we add 1) Add the ECL test code 2) Add an spkg-check file so ECL's self-tests can run if SAGE_CHECK=yes. But of course it would add 1.7 MB to the ECL package. There is a ticket to upgrade both Maxima and ECL open now http://trac.sagemath.org/sage_trac/ticket/8731 Adding the self-tests into the package would be quite easy. Then we could run 'make check' from spkg-install. Comments? 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] Regression testing
On 10/29/10 10:10 PM, Robert Bradshaw wrote: On Tue, Oct 26, 2010 at 12:57 AM, Dr. David Kirkby 'cksum' is a 32-bit checksum. Actually, if used all three sections of the output 1) Checksum 2) Length 3) Filename I feel that should be sufficiently relieable. The probability of a test having the exact same path, checksum and length, while having changed, would be exceeding close to zero. True, though I bet I could (maliciously) come up with two docstrings that have the same checksum given how weak the algorithm is. I don't see any advantage to using a weak checksum given that we have Python and aren't doing this on a per-file basis (or, I hope, extracting doctests with an external shell script). What's possible with malicious input is not really of a concern for a non-security application. The man page says deliberate deception would be difficult, though not impossible. I agree using a stronger algorithm is fine if Python was used to do all this. It just struck me that was was being contemplated was very complex. I was tempted to just hack together a 20 line shell script which parsed ptestlong.log, though one really wants CPU times, not wall times for this to be of any use whatsoever unless the machine was in an idle state. Also, I was talking to Craig Citro about this and he had the interesting idea of creating some kind of a "test object" which would be saved and then could be run into future versions of Sage and re-run in. The idea of saving the tests that are run, and then running the exact same tests (rather than worrying about correlation of files and tests) will make catching regressions much easier. - Robert Yes, that makes a lot of sense, though unless there a lot of tests, it would be easy to miss problems. Fortunately, there are a lot of tests :). - Robert But if a new set of tests is written for the benchmark, there would not be all the current doctests to use, so the number might drop. At least that is what I thought was talked of. The thread has got a bit long, and I've not been folowing it closely. 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: parsing trac
On 10/29/10 8:33 AM, Martin Albrecht wrote: Hi there, in light of the recent discussion on that our Trac based system shows its age compared to more awesome technologies I figured I might try to automate a few more steps of my own Trac interaction. For me almost the most annoying thing is to 1) export the patch 2) upload the patch (make sure to click the overwrite button) 3) add myself as an author (or reviewer if it's a reviewer patch) 4) toggle the needs_review state Those steps could easily be automated by adding a function to hg_sage called for instance push_patch(). For now I'm relying on parsing the HTML output to get stuff like the current list of authors etc. which seems to be what everybody does (sage-apply-ticket does the same). Is there a better way of doing this (getting information about a patch), e.g. is there a way to make Trac spit out some machine readable format which is more easily parsed? We could use that to implement a class TracTicket which automatically fetches all the information and makes it accessible in a convenient fashion. Surely the xmlrpc interface, or something like that, would be more natural than parsing the html: http://trac-hacks.org/wiki/XmlRpcPlugin It seems that Mike Hansen had some pretty cool ideas about how to use that plugin. Or maybe there's another plugin that makes things more natural: http://trac-hacks.org/ Maybe just accessing the trac database directly might be less work and more consistent than parsing the html. 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] Output format for find_fit and solve
I want to propose the following changes to the output format of find_fit
and solve:
for find_fit the current output format is a list of equations:
sage: data = [(i, 1.2 * sin(0.5*i-0.2) + 0.1 * normalvariate(0, 1)) for
i in xsrange(0, 4*pi, 0.2)]
sage: var('a, b, c, x')
sage: model(x) = a * sin(b * x - c)
sage: find_fit(data, model)
[a == 1.2204167610363676, b == 0.50171964598627838, c ==0.22401763827376933]
or a dictionary:
sage: find_fit(data,model,solution_dict=True)
{c: 0.22401763827376933, b: 0.50171964598627838, a: 1.2204167610363676}
I'd like to get an expression where the values found for the parameters
are put in the model given to find_fit:
sage: find_fit(data, model)
1.2204167610363676*sin(0.50171964598627838 *x -0.22401763827376933 )
For solve the current output format depends on the input:
sage: var('x y')
sage: eq1=x+4==0
sage: eq2=x^2+4*x+2==0
sage: sys1=x+y==1
sage: sys2=x-2*y==-2
sage: solve(eq1,x)
[x == -4]
A list containing solutions (even when there is only one solution).
sage: solve(eq2,x)
[x == -sqrt(2) - 2, x == sqrt(2) - 2]
A list containing solutions when there is more than one solution
solve([sys1,sys2],x,y)
[[x == 0, y == 1]]
A list containing a list containing solutions (this is the worst)
The format I would like to see is:
sage: solve(eq1,x)
x == -4
A single equation
sage: solve(eq2,x)
[x == -sqrt(2) - 2, x == sqrt(2) - 2]
This one is fine
solve([sys1,sys2],x,y)
[x == 0, y == 1]
Just a list of solutions. It is harder to work with the solutions if
they are inside another list.
I would like all of this changes to become standard outputs, although I
imagine that that would produce some backwards compatibility issues.
thanks!
Oscar
--
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] Regression testing
On Tue, Oct 26, 2010 at 12:57 AM, Dr. David Kirkby
wrote:
> On 10/25/10 07:06 PM, Robert Bradshaw wrote:
>>
>> On Mon, Oct 25, 2010 at 8:19 AM, David Kirkby
>> wrote:
>>>
>>> On 21 October 2010 01:33, David Roe wrote:
There are a number of tickets in trac about performance regressions in
Sage. I'm sure there are far more performance regressions which we
don't
know about because nobody noticed.
>>>
>>>
>>> I agree, and I've seen some comments from William that writing code
>>> one way or another can change things by a factor of 100.
>>>
As someone writing library code, it's generally not obvious that one is
about to introduce a performance regression (otherwise you'd probably
not do
it).
>>>
>>> Agreed.
>>>
Consequently, I've been thinking recently about how to detect
performance
regressions automatically. There are really two parts to the problem:
gathering timing data on the Sage library, and analyzing that data to
determine if regression have occurred (and how serious they are).
Data gathering:
One could modify local/bin/sage-doctest to allow the option of changing
each
doctest by wrapping it in a "timeit()" call. This would then generate a
timing datum for each doctest line.
* these timings vary from run to run (presumably due to differing levels
of
load on the machine). I don't know how to account for this, but usually
it's a fairly small effect (on the order of 10% error).
>>>
>>> They would differ by a lot more than 10%. One of my machines is a Sage
>>> buildbot client. If that is building Sage, and I'm not, Sage will take
>>> about and hour to build and test. If I'm building Sage at the same or
>>> similar time, or will increase that by a factor of at least two.
>>>
>>> What is needed is to measure CPU time used. That should be relatively
>>> stable and not depend too much on system load, though even there I
>>> would not be surprised by changes of +/- 10%.
>>
>> Yes, for sure, though it's probably worth having both. Of course when
>> we move from a pexpect interface to doing something natively that
>> would make the CPU time go up because the real work is no longer
>> hidden in a parallel process.
>>
* if you're testing against a previous version of sage, the doctest
structure will have changed because people wrote more doctests. And
doctest
lines depend on each other: you define variables that are used in later
lines. So inserting a line could make timings of later lines
incomparable
to the exact same line without the inserted line. We might be able to
parse
the lines and check that various objects are actually the same (across
different versions of sage, so this would require either a
version-invariant
hash or saving in one version, loading in the other and comparing. And
you
would have to do that for each variable that occurs in the line), but
that
seems to be getting too complicated...
>>>
>>> Getting a checksum of each doctest would be easy. I suggest we use:
>>>
>>> $ cksum sometest.py | awk '{print $1}'
>>>
>>> because that will be totally portable across all platforms. 'cksum' is
>>> 32-bit checksum that's part of the POSIX standard and the algorithm is
>>> defined. So there's no worry about whether one has an md5 program, and
>>> if so what its called.
>>
>> To be very useful, I think we need to be more granular than having
>> per-file tests. Just think about the number of files that get touched,
>> even a little bit, each release...
>
> I was not aware of that.
>
>> Full doctest blocks should be
>> independent (though of course when looking at a doctest a line-by-line
>> time breakdown could be helpful.). It shouldn't be too hard to add
>> hooks into the unit test framework itself. With 1.5K test files and
>> several dozen doctests per file, changing from version to version, I
>> could easily see the birthday paradox being a problem with cksum (even
>> if it weren't weak), but from python we have md5 and sha1.
>
> 'cksum' is a 32-bit checksum. Actually, if used all three sections of the
> output
>
> 1) Checksum
> 2) Length
> 3) Filename
>
> I feel that should be sufficiently relieable. The probability of a test
> having the exact same path, checksum and length, while having changed, would
> be exceeding close to zero.
True, though I bet I could (maliciously) come up with two docstrings
that have the same checksum given how weak the algorithm is. I don't
see any advantage to using a weak checksum given that we have Python
and aren't doing this on a per-file basis (or, I hope, extracting
doctests with an external shell script).
>> Also, I was talking to Craig Citro about this and he had the
>> interesting idea of creating some kind of a "test object" which would
>> be saved and then could be run into future versions of Sage and re-run
>> in. The idea of saving the tests
Re: [sage-devel] ECL / Maxima / Fedora 14 issues.
Is there any chance that Fedora 14 won't be supported? I have one FC11 machine, one FC12, and one FC13. FC12 has had no problem with recent Sage builds. FC11 has had minor problems. Even though sage is supported on Fedora 13, *my* fc13 machine (admittedly a rather underpowered one) promptly ceased being able to build ATLAS when I upgraded to fc13. Hence, I've been hesitant to upgrade either of the other machines to fc13. I was hoping things would be better when FC14 came out. Perhaps this is a vain hope? -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
Re: [sage-devel] parsing trac
On Fri, Oct 29, 2010 at 8:25 AM, Jeroen Demeyer wrote: > On 2010-10-29 15:33, Martin Albrecht wrote: >> Is there a better way of doing this (getting information about >> a patch), e.g. is there a way to make Trac spit out some machine readable >> format which is more easily parsed? > > I did this, see > http://sage.math.washington.edu/home/jdemeyer/merger/parseticket.c I've got http://code.google.com/p/sage-buildbot/source/browse/ . It doesn't push yet, but it pulls and parses stuff from Sage and creates a clone (trying to be minimally disruptive if you have a clone of that name, for easy ticket editing). It also stores test results in a db, but doesn't serve them yet (I'm imaging an iframe on the trac site with a green/yellow/red bubble and some status info with a link for more. - Robert -- 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: Spoof: Sage Misuses
regarding jobs, programming, etc, Kirby does not reveal all that I conveyed to him. 1. Monster.com has fewer jobs than indeed.com Indeed.com now has 223 jobs listed, estimated salaries... * $40,000+ (201) * $60,000+ (152) * $80,000+ (94) * $100,000+ (39) * $120,000+ (13) Python has 21,443 jobs listed Salary Estimate * $50,000+ (18936) * $70,000+ (13761) * $90,000+ (7429) * $110,000+ (3008) * $130,000+ (1308) This ratio of 100:1 is similar to the monster.com ratio, last I looked. I don't understand why the different tiers in the salary ranking. 2. If you want a job in science and technology, you might prefer a job in which you were doing "physics" or "bioengineering" or "artificial intelligence research" or even "video game design" etc. In which programming is part of the job, but you will learn what you need to do vis a vis programming in some orientation period. You might also prefer being hired by a company that views you that way. e.g. compare "auto mechanic, some experience but will train"vs. "auto mechanic, must have 2 years experience changing oil on 2007 Ford F-150 trucks". A job description that emphasizes previous high levels of programming experience in a particular language dialect is generally describing a bad situation. If the most important qualification is N years of programming in language X, then when that language is dropped, you will be replaced by someone "skilled" in language Y. 3. The demand specifically for Mathematica programmers may reflect the fact that good recruiters are trying to find smart people who can pass their entrance exam, and assume that any competent person can learn to limp along in Mathematica fast, and become more expert as needed. -- 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] parsing trac
On 2010-10-29 15:33, Martin Albrecht wrote: > Is there a better way of doing this (getting information about > a patch), e.g. is there a way to make Trac spit out some machine readable > format which is more easily parsed? I did this, see http://sage.math.washington.edu/home/jdemeyer/merger/parseticket.c -- 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] parsing trac
Are you in danger on reinventing the wheel? John On Fri, Oct 29, 2010 at 2:33 PM, Martin Albrecht wrote: > Hi there, > > in light of the recent discussion on that our Trac based system shows its age > compared to more awesome technologies I figured I might try to automate a few > more steps of my own Trac interaction. > > For me almost the most annoying thing is to > 1) export the patch > 2) upload the patch (make sure to click the overwrite button) > 3) add myself as an author (or reviewer if it's a reviewer patch) > 4) toggle the needs_review state > > Those steps could easily be automated by adding a function to hg_sage called > for instance push_patch(). > > For now I'm relying on parsing the HTML output to get stuff like the current > list of authors etc. which seems to be what everybody does (sage-apply-ticket > does the same). Is there a better way of doing this (getting information about > a patch), e.g. is there a way to make Trac spit out some machine readable > format which is more easily parsed? We could use that to implement a class > TracTicket which automatically fetches all the information and makes it > accessible in a convenient fashion. > > Cheers, > Martin > > -- > name: Martin Albrecht > _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF > _www: http://martinralbrecht.wordpress.com/ > _jab: martinralbre...@jabber.ccc.de > > -- > 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
[sage-devel] Re: ECL / Maxima / Fedora 14 issues.
I have made a new ticket at http://trac.sagemath.org/sage_trac/ticket/10187 to update ecl and maxima simultaneously, as they depend on each other. Updated spgks are there. Doctests for the now-smarter maxima still need to be sorted out. Fedora 14 also disallows executable stack libraries by default now, which breaks mpir. The necessary changes are pretty minimal since mpir does not need an executable stack. Ticket with updated mpir spgk is here: http://trac.sagemath.org/sage_trac/ticket/10188 On Oct 29, 6:18 am, "Dr. David Kirkby" wrote: > Apparently the version of ECL in Sage will not build on Fedora 14 which is > coming out on the 2nd November. > > I created a trac ticket for this. > > http://trac.sagemath.org/sage_trac/ticket/10185 > > Note however that the latest ECL is 10.4.1, which apparently does build on > Fedora 14, since a package I created long ago on 10.4.1 does build. > > But when I created a 10.4.1 package some time ago, it would not work with the > Maxima in Sage. > > Currently > > * Fedora 14 is not out > * Only Fedora 13 is supported in Sage > * We don't have the latest Maxima > * We don't have the latest ECL > * At least a few months ago, there were issues with updating versions of ECL > and Maxima - see for example > > http://trac.sagemath.org/sage_trac/ticket/9264 > > So it looks like there could be a big can of works opened if to try to get > Sage > working on Fedora 14. > > I'm personally not going to try to resolve these issues, but I thought I'd > bring > them up on sage-devel. > > http://trac.sagemath.org/sage_trac/ticket/9840 > > is an ECL issue which is really annoying me, but it is a very difficult one to > solve. > > 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] parsing trac
Hi there, in light of the recent discussion on that our Trac based system shows its age compared to more awesome technologies I figured I might try to automate a few more steps of my own Trac interaction. For me almost the most annoying thing is to 1) export the patch 2) upload the patch (make sure to click the overwrite button) 3) add myself as an author (or reviewer if it's a reviewer patch) 4) toggle the needs_review state Those steps could easily be automated by adding a function to hg_sage called for instance push_patch(). For now I'm relying on parsing the HTML output to get stuff like the current list of authors etc. which seems to be what everybody does (sage-apply-ticket does the same). Is there a better way of doing this (getting information about a patch), e.g. is there a way to make Trac spit out some machine readable format which is more easily parsed? We could use that to implement a class TracTicket which automatically fetches all the information and makes it accessible in a convenient fashion. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- 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: Spoof: Sage Misuses
On 10/29/10 01:50 PM, kcrisman wrote: I'm of the opinion that outside academia, there is not a lot of call for Mathematica. I think that in physics Mma is used fairly heavily, at least in certain circles. I don't know how much of that is outside academia, presumably a fair amount. - kcrisman I think it if was used outside academia a lot, there would be more jobs requiring Mathematica skills - would you not agree? I've seen a pie chart from Wolfram Research, where they indicated how much the takeup was in particular industries. Finance was the largest sector, which seems to correlate with my job hunts when I have searched for the term. Here's a search today. http://jobsearch.monster.com/PowerSearch.aspx?q=Mathematica&tm=60 Of those wanting Mathematica, they are always and/or MATLAB. I'm personally yet to be convinced there is much demand for Mathematica outside academia. 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: Spoof: Sage Misuses
> I'm of the opinion that outside academia, there is not a lot of call for > Mathematica. > I think that in physics Mma is used fairly heavily, at least in certain circles. I don't know how much of that is outside academia, presumably a fair amount. - 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: Adding a new type
Hi Victor! On 28 Okt., 18:05, VictorMiller wrote: > 3) Noncommutative polynomials and power series: if X is a finite set, > and M is the free monoid on X (which is already in sage): Few weeks ago I wrapped the functionality provided by GAP into Sage. Advantages: 1) GAP also provides non-associative and non-unital free magmas resp. free algebras. So far, Sage's free algebras are associative and unital. 2) Arithmetic would be a *lot* faster. But currently I have to stop work (busy with a relocation). I expect that I can resume work in one week or so. Cheers, 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: Review wranglers
Hi Jason, hi Mike, On Fri, Oct 22, 2010 at 03:26:09PM -0400, Jason Bandlow wrote: > On 10/22/2010 12:20 PM, Robert Bradshaw wrote: > > Given the difficulty of finding reviewers, are you arguing we > > shouldn't try to make things even easier? Yes, it's not to bad ([copy > > the url, qimport, qpush] * n, build, test, run doctests, qpop, ...), > > but could be a lot better. Oh, and by "test" I mean not doctests, but > > interactively test, where it's more of a pain to context switch and > > wait for the build to complete. I'd rather be reading the code and say > > "hmm... I wonder if this works..." and just try it out. > > This has annoyed me on more than one occasion. Can any trac gurus speak > to the possibility of adding two fields to trac tickets? > > 1) Patches to be applied for the current ticket > 2) Tickets on which this patch depends +1 as well! In fact, Mike H. promised me to setup the appropriate trac options for this (together with the cool "dependency graph" feature) last spring. So, let's all say a big *please* to Mike! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- 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] 70M .cache/common-lisp
I have been hit by this too. For the same reason: my work desktop has a networked (and backed up) home dir with limited space, but the local disk has lots of space -- so I make ~/.cache a link to a dir on the local disk and stopped getting warnings about my disk quota being exceeded. I'm sure you can delete all those files, but it is more convenient not to have to remeber to do so. mas...@host-56-150%df .cache FilesystemSize Used Avail Use% Mounted on /dev/sda4 124G 42G 76G 36% /local mas...@host-56-150%du -sh .cache/* 2.7M.cache/album-art 1.4M.cache/banshee-1 572M.cache/common-lisp 8.0K.cache/gedit so there's half a gigabyte of junk in there (and my quota is only 5G so it matters that this on now on a local disk!) John On Fri, Oct 29, 2010 at 11:45 AM, Jan Groenewald wrote: > Hi > > We had students learn to build and modify sage > on the large local "scratch space" on each PC, not on > their networked NFS home directories, which has more > limited space. > > Each student had a ~/.cache/common-lisp which was > 70M in size. Perhaps maxima compilation did this? > Perhaps it can be deleted after a succesful compile? > > 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
[sage-devel] 70M .cache/common-lisp
Hi We had students learn to build and modify sage on the large local "scratch space" on each PC, not on their networked NFS home directories, which has more limited space. Each student had a ~/.cache/common-lisp which was 70M in size. Perhaps maxima compilation did this? Perhaps it can be deleted after a succesful compile? 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
Re: [sage-devel] Spoof: Sage Misuses
On 10/29/10 05:54 AM, Minh Nguyen wrote: Hi David, On Fri, Oct 29, 2010 at 2:20 PM, Dr. David Kirkby wrote: If you want to put students off of using Mathematica, I can suggest a very simple way. Suggest they look on job sites like phdjobs, monstir.com, and search for the number of jobs requiring Mathematica skills. Then do the same for MATLAB and Python. Basically you will find 100's of jobs requiring MATLAB and Python skills, but very few for Mathematica. (Of course, the vast majority of the Python jobs are not scientific, so the comparison with Python is less fair, but a comparison with MATLAB is IMHO very fair.) Some numerical computation jobs I saw about a year ago (in Australia), but not advertised online, required the applicants to have a working knowledge of *Octave*, the Matlab clone. I must admit I've not looked for Octave, though I suspect if you know MATLAB, an employer would probably give you careful consideration for a job where they use Octave. Richard Fatemen was claiming the other day on sci.math.symbolic that Lisp was popular, and gives this site showing it ranked #13 in computer languages http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html&usg=AFQjCNEREt_OLAWOBo2-7ST7ALC9UUfDWg I did a comparison on monstir.com of the jobs for the jobs for several programming languages. Unfortunately for some there are over 1000 jobs and so the exact number is unknown. But this is what I found. "C programming language" > 1000 C++ > 1000 Python > 1000 PHP > 1000 C# > 1000 Javascript > 1000 "r statistics" - 671 matlab 657 Labview 288 SPSS 282 Objective C 122 Fortran 100 Pascal 81 Delphi 74 Mathematica 27 lisp - 10 HP Vee 3 Maxima 0 Macsyma 0 This shows 24 times as many jobs for MATLAB as Mathematica. Strange, but R is even more popular than MATLAB, though only by a statistically insignificant amount. I'm of the opinion that outside academia, there is not a lot of call for Mathematica. That said, I'm personally very impressed with Mathematica as a tool. 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
