[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: I doubt this will ever happen. Soon for example we plan to switch to the svn version of pari which absolutely changes lots of things in Sage in non-backward compatible ways, so you cannot use the stable pari release with Sage any more. And given the timeframe the pari devs do releases this does not bode well for stable releases. Well, how long after Sage switches to this version will it be before a stable pari release with these features comes out? If we're talking 3-6 months, this isn't a real problem. If Sage were going with doing regular stable releases, then it would make sense to talk to the pari developers before upgrading to the SVN version and get a commitment from them that they'll do a release with those features within the next 3-6 months. Obviously we have no control over the pari developers so we would not be able to obtain guarantees, but it seems worth trying to obtain them. This is probably a good example of the process I would use if I were managing the stable releases every 3-6 months. When discussion comes up of upgrading an .spkg to an SVN version, we send a quick note to upstream asking if they are likely to do a release with the features we need within the appropriate timescale. Similarly, when we add an ABI-changing patch against an upstream library, we should immediately send it upstream and ask whether they can commit to releasing with that functionality in the next 3 months. Also: NTL releases maybe once a year, often less frequent, so the next time we change something in the interface there won't be a release for some time. While we will upgrade to NTL 5.5 soon I am not sure it will be there in time for Sage 4.0. How often does Sage need to patch a rarely releasing project like NTL? As far as I'm aware, Sage has only had one ABI-changing patch against NTL since I started working on Sage in Debian in November 2007. Victor Shoup is a nice guy, I'm sure that we can convince him to do an extra release every couple years so that Sage can have its every-N-months major stable release work with a released version of NTL. The problem is that some upstream projects release slowly while others are fast and do a point release when we submit a bugfix. One such example is FLINT where I get an instant update when we fix something or complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two weeks for build issues for example). I don't think there is any reasonable way to guarantee that Sage will ship clean upstream every 3 or 6 months. I am happy to try, but I don't want any rule since fixing a bug in Sage takes precedence over packaging concerns for me any day. Sorry. Of course it will be the case that occasionally some upstream is really slow about releasing, and one has to just give up and move on. As Jason Grout points out, even Debian runs SVN versions sometimes when upstream is being really bad about releasing. But on the other side of this coin, I often find that when I contact a Sage upstream about a patch Sage has had against their software for several months that I want merged, they were completely unaware of the patch's existence. Maybe I've been unlucky in my sampling, but I get the sense that Sage development does not currently react to merging a new ABI-changing patch with we should send this upstream ASAP. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: Sure, NTL might not be the best example here, but say matplotlib. We did not update to an svn release to make life harder for you, but because we needed a patch that was upstreamed and not easily rebasable. I think all the issue can and will be sorted out in the near future after 4.0, but the update to pari-svn will happen. Indeed, it is a surprise that it did not already happen and quite a few bits in Debian outside Sage do use the pari library, i.e. clisp has an optional pari module for example. And there is really no way around that since the stable pari release is buggy in many ways and upstream has also recommended to use svn. Indeed, in a recent email Karim Belabas has actually called the stable pari pari stale. I am quite supportive of getting all issues you have resolved, but it seems rather hard to get this fixed. I guess you could have a pari-2.3.4.deb (just like there are two different python.debs AFAIK). For libraries Debian often will have multiple versions that are available at a time in order to help with these transitions. It has been done with programs like pari when necessary -- you just have two versions of the pari package that conflict with each other. Generally something to be avoided if possible. It sounds possible that Pari has internal disagreements about releasing that might justify this sort of thing, but I'd need to learn more. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 10:57 pm, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, mabshoff wrote: I doubt this will ever happen. Soon for example we plan to switch to the svn version of pari which absolutely changes lots of things in Sage in non-backward compatible ways, so you cannot use the stable pari release with Sage any more. And given the timeframe the pari devs do releases this does not bode well for stable releases. Well, how long after Sage switches to this version will it be before a stable pari release with these features comes out? No clue, there are usually several years between stable pari releases and so far I don't think there has been anyone able to change their mind to have something more regular/often. If we're talking 3-6 months, this isn't a real problem. If Sage were going with doing regular stable releases, then it would make sense to talk to the pari developers before upgrading to the SVN version and get a commitment from them that they'll do a release with those features within the next 3-6 months. Obviously we have no control over the pari developers so we would not be able to obtain guarantees, but it seems worth trying to obtain them. Well, we can try. But the whole point is that is someone posts a pari- svn.spkg which fixes bugs in functions Sage does not use and adds functionality that is asked for by people no one will be willing to wait 3 or 6 months to merge that. It might be more feasible to just package Sage before that change and then hope in the next couple months upstream will release. This is probably a good example of the process I would use if I were managing the stable releases every 3-6 months. When discussion comes up of upgrading an .spkg to an SVN version, we send a quick note to upstream asking if they are likely to do a release with the features we need within the appropriate timescale. Similarly, when we add an ABI-changing patch against an upstream library, we should immediately send it upstream and ask whether they can commit to releasing with that functionality in the next 3 months. Also: NTL releases maybe once a year, often less frequent, so the next time we change something in the interface there won't be a release for some time. While we will upgrade to NTL 5.5 soon I am not sure it will be there in time for Sage 4.0. How often does Sage need to patch a rarely releasing project like NTL? As far as I'm aware, Sage has only had one ABI-changing patch against NTL since I started working on Sage in Debian in November 2007. Victor Shoup is a nice guy, I'm sure that we can convince him to do an extra release every couple years so that Sage can have its every-N-months major stable release work with a released version of NTL. Well, you pushed patches upstream that contain GNUisms and I will end up patching it out of the sources again, so I am not too happy about that since upstream way too often does not understand that GNUisms are bad or are totally unaware of the problem in the first place. The problem is that some upstream projects release slowly while others are fast and do a point release when we submit a bugfix. One such example is FLINT where I get an instant update when we fix something or complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two weeks for build issues for example). I don't think there is any reasonable way to guarantee that Sage will ship clean upstream every 3 or 6 months. I am happy to try, but I don't want any rule since fixing a bug in Sage takes precedence over packaging concerns for me any day. Sorry. Of course it will be the case that occasionally some upstream is really slow about releasing, and one has to just give up and move on. As Jason Grout points out, even Debian runs SVN versions sometimes when upstream is being really bad about releasing. But on the other side of this coin, I often find that when I contact a Sage upstream about a patch Sage has had against their software for several months that I want merged, they were completely unaware of the patch's existence. I don't know of any patch but the NTL one where this could be the case. We have contacted Victor Shoup several times to speak or visit a Sage days and he has *never* responded. The author of that patch works at NYU, i.e. the same place as Victor and if he never got around to get the patch merged than I can hardly call that our fault. Another author we have contacted via numerous people as well as multiple times is the cddlib author and he has also *never* responded to us. Maybe I've been unlucky in my sampling, but I get the sense that Sage development does not currently react to merging a new ABI-changing patch with we should send this upstream ASAP. I consider this completely wrong. Can you mention some concrete examples? -Tim Abbott Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send
[sage-devel] Re: [ANN] sage-mode-0.5.3
On 21-Apr-09, at 5:11 PM, Nicolas M. Thiery wrote: Dear Nick, One more feature request for M-x rerun-sage More often than not when I rerun-sage, I am at an ipdb prompt. Currently the soft kill (which is much faster than the hard kill!) does not work in that case. Could the soft kill try to sent twice 'quit' to sage, so as to first quit from ipdb and then from sage? Sure! In sage-build.el, find the line (comint-send-eof) (in defun rerun-sage ()) and repeat it a few times. I've folded this in but won't be cutting a new release until I have some more time or emacs frustrations. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [ANN] sage-mode-0.5.3
Sure! In sage-build.el, find the line (comint-send-eof) (in defun rerun-sage ()) and repeat it a few times. I've folded this in but won't be cutting a new release until I have some more time or emacs frustrations. Curious: this seems to make sage build and rerun hang on my machine. But it works interactively. I imagine I'm not polling for input correctly. Use with caution, sorry. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
mabshoff wrote: On Apr 23, 6:23 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: Hello, SNIP Hi Michael, Hi David, As Sage on Solaris needs a custom tool chain, could a script be provided that builds that tool chain from a full (but fresh) installation of the latest version of Solaris, which is Solaris 10 update 6? Maybe, I don't know if it will happen in time for 4.0. But I have binary packages for the toolchain. In principle something like #!/bin/sh /usr/sfw/bin/wgethttp://www.somewhere.com/gcc-a.b.c.tar.gz /usr/sfw/bin/wgethttp://www.somewhere.com/gmake-e.g.g.tar.gz ... /usr/sfw/bin/gtar xf gcc-a.b.c.tar.gz To say It builds on skynet is not too helpful to people. Well, it is helpful to the people who pay me and it will work on the T2000 we will be hosting the notebook on. Whereas you if you could say Various versions of gcc, make, etc cause problems with Sage, but if you use this script on a fresh full installation of Solaris 10 update 6, you will have all the tools necessary. See http://wiki.sagemath.org/solaris/toolchain for details. As far as I know (but are NOT 100% sure), a full install of Solaris 10 update 6 on SPARC includes * GNU tar (version 1.14) * gcc (version 3.4.3) * wget (version 1.10.2) * GNU make (version 3.80, under the name 'gmake') All those are in /usr/sfw/bin I know, they are too broken to build Sage reliably, especially the linker. We also don't support using g77 as a Fortran compiler at the moment, but we will again in the future. As it is necessary to build a later gcc, then I assume that will be one of the steps in the script. If building gcc needs to be done in two stages (i.e. build version 4.1 from 3.4.2, then use 4.1 to build 4.3), then that too could be scripted. Once someone has a suitable tool chain, they might have some hope of making a useful contribution on the rest of the Solaris issues. OK. Not that for gcc 4.2.2 the gfortran creates completely broken code on Sparc, so the only toolchain I will be using is the one specified above since it is well tested by me. But it's pretty much irrelavent if 4.2.2 creates buggy fortan - I assume you have found at least one version which does not. But the point is, whatever method you use to create a tool chain could be scripted. I doubt that script would be that long either. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage -t and detection of sage library files
Hi! I just upgrade to 3.4.1, and on my machine sage -t is broken for files in subdirectories. For example: -- zephyr-~sage-main/sagesage -t monoids/free_monoid.py sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py File ./free_monoid.py, line 18 from monoids/free_monoid import * ^ SyntaxError: invalid syntax [0.4 s] exit code: 1024 -- The following tests failed: sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py Total time for all tests: 0.4 seconds -- Seems like sage -t misdetects the file as not beeing in sage's source tree and trying to (incorrectly) import it. Anyone else running into the same problem? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
On Apr 24, 2009, at 12:21 AM, Nicolas M. Thiery wrote: Hi! I just upgrade to 3.4.1, and on my machine sage -t is broken for files in subdirectories. For example: -- zephyr-~sage-main/sagesage -t monoids/free_monoid.py sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py File ./free_monoid.py, line 18 from monoids/free_monoid import * ^ SyntaxError: invalid syntax [0.4 s] exit code: 1024 -- The following tests failed: sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py Total time for all tests: 0.4 seconds -- Seems like sage -t misdetects the file as not beeing in sage's source tree and trying to (incorrectly) import it. Anyone else running into the same problem? Yes, I got this too. I thought it was just because I was working in a non-upgraded branch (of an upgraded Sage), but it seems to be more common than that. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Add info on how to get md5 checksum on Solaris
Here's a quick suggestion, which should take less than 1 minute. I note in the Solairs binaries http://sage.math.washington.edu/home/mabshoff/solaris-binaries/ there is a file md5sum.txt There is no file 'md5' or 'md5sum' or anything else on Solaris, so unless someone happens to know how to get the checksum, they might struggle. It is far from obvious! The way to do it, on default install of Solaris, is: /usr/bin/digest -a md5 filename Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 12:19 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: SNIP Hi David, OK. Not that for gcc 4.2.2 the gfortran creates completely broken code on Sparc, so the only toolchain I will be using is the one specified above since it is well tested by me. But it's pretty much irrelavent if 4.2.2 creates buggy fortan No, it isn't. It took me considerable time to determine that certain doctest failures I saw were compiler issues where code was miscompiled. Right now there is only one toolchain that I will support when push comes to shove on Solaris and that is the one I provide. Other people are free to use whatever they want, but the people who pay me to work on Solaris want to use the latest stable gcc release, i.e. I will switch to gcc 4.4.0 soon. Over time hopefully we can get the SFW tools, other gcc releases and eventually Sun's tool suite to work, but given that I have plenty of other things to fix at the moment that just isn't high priority. By the way: That toolchain I use on an US IIIi today blew up with an internal compiler error on a T2000 (specifically gfortran). Since that machine isn't on SkyNet I will see if gcc 4.3.3 or 4.4.0 fixes the problem and otherwise open a ticket with the gcc folks. But it isn't a high priority item since I have to fix a number of bugs before the 4.0 deadline and I don't have any time for detours :). The sparc binary I produced works on that box, so we will be using that until further notice. - I assume you have found at least one version which does not. But the point is, whatever method you use to create a tool chain could be scripted. I doubt that script would be that long either. No it won't take long for a decent version. I have meant to so that for a while, but to get it working reliably and only with the SFW tools in $PATH will take some work. Since I will rebase my toolchain on gcc 4.4.0 in the next couple days I will see what I can do. In general I have posted 3.4.1 32 bit sparc and x86 tarballs that include the toolchain and should just work on any Solaris 10 build at http://www.sagemath.org/bin/solaris/index.html There are also the stand alone toolchains there in case anyone wants to build Sage, but note that the 3.4.1 binaries contain fixes not yet upstream, so build at least on Sparc will fail while Sympow won't work out of the box as is on x86. Let me know how they work in case anyone does play with them. All known problems are listed at http://wiki.sagemath.org/solaris and the issues that do not have tickets yet will get them in the next couple days. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
Not all of Chris's original questions have been answered yet in this thread -- for example, listing of aliases, and making the function (and even more, the class) headings more prominent. I will not mention accents. John 2009/4/24 mabshoff mabsh...@googlemail.com: On Apr 23, 9:34 pm, Jason Grout jason-s...@creativetrax.com wrote: Carl Witty wrote: On Thu, Apr 23, 2009 at 9:19 PM, Jason Grout jason-s...@creativetrax.com wrote: Anyone know where the CSS file is? The color is set in a default.css file, but the only default.css files I see are in _static directories, which sounds like they are automatically generated somehow. It comes (originally) from src/sphinx/static/default.css in the sphinx spkg. (No, I don't know the right way to customize it.) It looks like 0.6 is easy to theme:http://sphinx.pocoo.org/theming.html We are running 0.5.1. The current release is 0.6.1. Is anyone working on an upgrade? Should it be a drop-in replacement? Mike, you mentioned the autodoc in 0.6 will make some other things easier too. Mike mentioned the update to 0.6 should be easy, but he hadn't done it yet. But I think this should be doable in the 4.0 timeframe. Jason Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
This problem has been around for a while. It works ok if you give an absolute pathname. Having said that, I just realised that the testing I have been doing on a clone of 3.4.1 was working fine with a relative pathname. Perhaps it is because Nicolas is working on an upgrade from 3.4.rc0 (as you can see from his path) rather than a fresh 3.4.1? John 2009/4/24 Robert Bradshaw rober...@math.washington.edu: On Apr 24, 2009, at 12:21 AM, Nicolas M. Thiery wrote: Hi! I just upgrade to 3.4.1, and on my machine sage -t is broken for files in subdirectories. For example: -- zephyr-~sage-main/sagesage -t monoids/free_monoid.py sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py File ./free_monoid.py, line 18 from monoids/free_monoid import * ^ SyntaxError: invalid syntax [0.4 s] exit code: 1024 -- The following tests failed: sage -t 3.4.rc0/devel/sage-main/sage/monoids/free_monoid.py Total time for all tests: 0.4 seconds -- Seems like sage -t misdetects the file as not beeing in sage's source tree and trying to (incorrectly) import it. Anyone else running into the same problem? Yes, I got this too. I thought it was just because I was working in a non-upgraded branch (of an upgraded Sage), but it seems to be more common than that. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
On Apr 24, 1:16 am, John Cremona john.crem...@gmail.com wrote: Hi, This problem has been around for a while. It works ok if you give an absolute pathname. Having said that, I just realised that the testing I have been doing on a clone of 3.4.1 was working fine with a relative pathname. Perhaps it is because Nicolas is working on an upgrade from 3.4.rc0 (as you can see from his path) rather than a fresh 3.4.1? John I remember a discussion about the problem, but did not see any fixes in 3.4.1. If someone knows a ticket and/or even better a patch please let us know so we can get this reviewed and fixed. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sage 3.4.2.alpha0 released!
Hello folks, here goes 3.4.2.alpha0. It does not contain all the fixes I wanted, but I merged two large (200kb+) patches (#5610 and #5848) that touched a lot of files and that were in danger of bitrotting. Since I considered it pointless to force people to rebase potentially twice I pulled them both into alpha0. The source, upgrade bits and a sage.math-only binary should be available in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/ From here on the plan is to merge other reviewed patches (in case you are bored, there are about 80 patches to review in trac), fix some more issues and then get out rc0 on Sunday to have 3.4.2.final very early next week. Coverage right now is at 69% and there is a doctest patch for padics that brings that directory to 100% and gives us 2.1% globally, so I definitely want that one merged. Another thing to review and push hard are the pynac tickets and the not yet in trac patch for the symbolics switch. Mike Hansen mentioned he could post something today, so hopefully it will get reviewed until Sunday and merged to give the code a good beating during 3.4.2. If you have any patches in trac please make sure to check if they apply to alpha0 since they will get bounced back if they fail to merge. Cheers, Michael Merged in Sage 3.4.2.alpha0: #4809: Dan Drake, John Palmieri: the installation guide and constructions guide should be CC licensed [Reviewed by John Palmieri, Dan Drake] #5111: Mike Hansen, Bill Page: axiom -- fricas [Reviewed by Carl Witty] #5130: R. Andrew Ohana: create a prime_pi function that doesn't just compute len(prime_range(n) [Reviewed by Carl Witty, William Stein, Michael Abshoff] #5346: John Cremona: Some doctests in schemes/elliptic_curves/ ell_rational_field.py fail with optional database installed [Reviewed by Michael Abshoff] #5567: Wilfried Huss: bug in region_plot [Reviewed by Bill Cauchois] #5595: Robert Bradshaw: minor dependancy checking glitch [Reviewed by Carl Witty] #5610: John Palmieri: LaTeX customization [Reviewed by Robert Bradshaw, Rob Beezer] #5627: Karl-Dieter Crisman: Trivial typo in quadratic_nonresidue [Reviewed by Minh Van Nguyen] #5704: John Cremona: Implementation of finding elliptic curves with prescribed reduction over QQ [Reviewed by Robert Miller] #5751: Dan Bump: cartan_type now a method rather than attribute in weyl_characters.py [Reviewed by Anne Schilling] #5795: Simon King: Improved performance of MPolynomialRing_libsingular.__call__() [Reviewed by Martin Albrecht] #5803: Robert Bradshaw: Upgrade Cython to 0.11.1 [Reviewed by William Stein] #5809: Alex Ghitza: schemes/generic/hypersurface.py is completely broken [Reviewed by John Cremona] #5815: Mitesh Patel, Jason Grout: Disable TinyMCE in the live documentation [Reviewed by Jason Grout, Mitesh Patel] #5821: Robert Bradshaw: preparser incorrectly handles backslash operator inside strings (sometimes) [Reviewed by Carl Witty] #5822: William Stein: cusps -- implement action of the Galois group on cusps for congruence subgroups as on page 12 of Steven's Arithmetic on Modular Curves [Reviewed by John Cremona] #5836: Jason Grout: Make show() immediately show an image in the notebook [Reviewed by William Stein] #5848: John Palmieri: untabify Sage [Reviewed by Rob Beezer, Michael Abshoff] #5851: Chris Wuthrich: Convert 3 more elliptic curves files to ReST and add to reference manual [Reviewed by John Cremona] #5861: Michael Abshoff: Remove cocoa, four_ti_2, reduce and template interfaces since they do not work/are broken [Reviewed by Michael Abshoff] #5863: John Palmieri: remove some files from sage/algebras [Reviewed by William Stein] #5871: William Stein: solaris x86 3.4.1 -- code_bounds.py fails some plot doctests [Reviewed by Michael Abshoff] #5876: John Cremona: Vast speedup in P1List construction [Reviewed by William Stein, Robert Bradshaw] #5886: William Stein: Bug in free module homomorphism creation [Reviewed by Robert Bradshaw] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sage 3.4.1 SSE2 only builds on sage.math and performance
Hello folks, by accident I build my 3.4.2.alpha0 build as an SSE2 only build. So I had a change to play with it a little and check for performance regressions. Here are some basic benchmarks: SSE2 vs. SSE3: * measurable difference for ZZ determinant (~10% slower with SSE2 for 300x300, 400x400, etc) * huge difference (factor *4* slower with SSE2) for RDF matrix matrix multiply (2000x2000, 3000x3000, 4000x4000) * tiniest difference for ZZ matrix matrix mutiply (~1-2% *faster *with* SSE2 over SSE3) Dan Drake reported in IRC that some of the doctests in the matrix directory ran 7% faster with SSE2 instead of SSE3. This rather perplexing result might be due to the SSE2 only Hammer ATLAS being significantly smaller in footprint in the cache (it certainly contains way fewer SSE instructions) and that this results in better cache locality and hence faster code for the matrix directory doctests. Overall these are some interesting developments. While the RDF matrix matrix multiplies did not surprise me one bit the small slowdown or tiny speedup for operations over ZZ (where some code uses multi modular arithmetic and hence ATLAS) is a little puzzling. Thoughts? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 3.4.1 release tour updates
On Apr 22, 11:40 pm, Minh Nguyen nguyenmi...@gmail.com wrote: Hi Michael, Hi Minh, My policy thus far is to list the author(s) of the patch(es). The case you mentioned above was a result of me misreading ticket #5146. This is because for the patch variety_patch.3.patch, I saw the description Updated with some of Martin's comments so I assumed that Martin had some direct input. I tried to be generous in attributing credit. Well, if someone posts a 3 kb reviewer patch for a 250kb patch (#5180 for example) I tend to give a person reviewer credit. In fact, anything marked as reviewer patch should not get author credit. Often enough someone fixes a tiny issue in a patch and just posts the changed original patch of the author - this happens quite often when people use queues. I would prefer if the notes I post for each alpha and rc would match the credit mentioned in the release tour. That way it is easy enough for someone to complain if they shouldn't or didn't get credit and the two different documents would be in sync, i.e. you see on list when I fix things and you should let me know if anyone complained about the release tour. Because I took a look at the changes by David Loeffler I gave Chris Kurth partial author credit for #5180. If you also used the author/reviewer system as I do in the release notes no confusion should arise and you mention all people getting credit on the ticket :) Thoughts? -- Regards Minh Van Nguyen Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] version 3.4 and 3.4.1 fail to run under VMware
I have downloaded the images of versions 3.4 and 3.4.1 to run under VMware, but I get the following error message when I try to run sage: WARNING: This Sage install was built on a machine that supports instructions that are not available on this computer ... The following processor flags were on the build machine but are not on this computer: pni Can someone look into this, please? thanks Lloyd. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Thu, Apr 23, 2009 at 10:03 PM, Jason Grout jason-s...@creativetrax.com wrote: chris wuthrich wrote: ... On a different note, can we change the background color of examples? In Before making color changes, can they please be tested to see what they look like on a printed (B+W) page? If the color-B+W rendering is too faint then the printed version of the tutorial will be unreadable. my opinion, that green is just a bit too strong. It's also hard to read the blue text in strings against the green background. (After playing with it for a while) I propose a soft light yellowish off-white color, like #f4. The syntax highlight colors stand out better, and the whole thing is easier to read. Plus, the barely-yellow color matches nicely with the blue-green of the titlebar, etc. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Thu, 23 Apr 2009 13:43:54 -0700 Ondrej Certik ond...@certik.cz wrote: On Thu, Apr 23, 2009 at 1:17 PM, Tim Lahey tim.la...@gmail.com wrote: On Apr 23, 2009, at 4:07 PM, William Stein wrote: Could you explain how assumptions are so important? Could you We already discussed this many times on this list, just search the archives. Without good assumptions, you cannot implement good integration, good solvers, good simplification, nothing. Of course, things like x+x is easy, but once you have for example Integral(complex expression involving many constants), sometimes you can simplify it, sometimes not and this very much depends on the assumptions for the constants. Or things like integrate(x**n, x). particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are ginac doesn't have any assumptions and so ginac doesn't have any advanced symbolic features. Of course, if the only thing that you are going to use ginac for is the core engine, then it should not matter much. But what I want from a CAS is to be able to do advanced symbolic calculations with symbols, so I need some way to tell it my assumptions about the symbols. Taking everything as complex numbers will not simplify things in many cases. particularly important in symbolic integration, which ginac doesn't do. Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? Because we attach assumptions to symbols, e.g. you define In [2]: x = Symbol(x, positive=True) and then you work with that: In [3]: sqrt(x**2) Out[3]: x In [4]: x = Symbol(x, negative=True) In [5]: sqrt(x**2) Out[5]: -x In [6]: x = Symbol(x) In [7]: sqrt(x**2) Out[7]: ╱ 2 ╲╱ x But this approach is the wrong one, because then the core engine has to take this into account and it slows things down. Our new system will keep the assumptions external, and define methods to work with them, like in mathematica, e.g. refine(). This should simplify the core and then we should be able to speed it up. Note that ginac has a similar mechanism, which it uses for the automatic simplifications it does. I haven't exposed this in the Sage interface. I don't know if Mike has either. Here is a list of the info flags ginac supports (Scroll down for the table): http://www.ginac.de/tutorial/Information-about-expressions.html Pynac has an infinity flag in addition to the ones listed there. I admit that I have no experience with general simplification routines, but I have the feeling that it all boils down to answering is_positive(), is_integer() queries about expressions. The trick is to be able to deduce the answers to these from a few bits of information gathered from the user. I don't know of any open source package which can provide this capability for Sage. I've heard that Reduce with its Redlog package is very powerful in this area. I doubt if it can be used from Sage though. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
2009/4/24 David Joyner wdjoy...@gmail.com: On Thu, Apr 23, 2009 at 10:03 PM, Jason Grout jason-s...@creativetrax.com wrote: chris wuthrich wrote: ... On a different note, can we change the background color of examples? In Before making color changes, can they please be tested to see what they look like on a printed (B+W) page? If the color-B+W rendering is too faint then the printed version of the tutorial will be unreadable. Presumably you mean to only print the pdf versions -- why not make those BW throughout? John my opinion, that green is just a bit too strong. It's also hard to read the blue text in strings against the green background. (After playing with it for a while) I propose a soft light yellowish off-white color, like #f4. The syntax highlight colors stand out better, and the whole thing is easier to read. Plus, the barely-yellow color matches nicely with the blue-green of the titlebar, etc. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: version 3.4 and 3.4.1 fail to run under VMware
On Apr 24, 4:10 am, Lloyd Kilford l.kilf...@gmail.com wrote: Hi Lloyd, I have downloaded the images of versions 3.4 and 3.4.1 to run under VMware, but I get the following error message when I try to run sage: WARNING: This Sage install was built on a machine that supports instructions that are not available on this computer ... The following processor flags were on the build machine but are not on this computer: pni Can someone look into this, please? The problem in general is that your computer does not have SSE3 instructions that were used when building Sage leading to illegal instrucion - aborted errors during the runtime. So we added a check to warn users about it. So far, so good, but Sage 3.4.1 was supposed to fix this by introducing an SSE2 only mode and William told me that he build the Sage in the VMWare image in that mode. I would suspect this is a SNAFU since the env variable that William thought would get used SAGE_SIMD_FLAG is not the correct one, i.e. it is SAGE_SIMD_MODE. So I expect we will rebuild the VMWare image as well as the farm binaries and SkyNet once again right now :( Ironically there is a ticket against 3.4.2 to document this in README.txt - oh well Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
chris wuthrich wrote: * In one of my files i have a line power_series = series. This produces the full docstring of series to appear twice in the documentation, once under series and once under power_series. How can I exclude the alias ? According to http://sphinx.pocoo.org/ext/autodoc.html the autodoc directives .. autoclass:: pAdicLseriesOrdinary :members: series, is_ordinary, is_supersingular might work in Sphinx v0.5 and .. autoclass:: pAdicLseriesOrdinary :exclude-members: power_series in Sphinx v0.6. However, I believe the current version of builder.py does not scan for custom directives when it auto-generates the .rst files. I don't know if it's OK simply to put them in a docstring. Another possibility is to add to builder.py an auto-skip-member() handler that skips certain methods, along the lines of http://groups.google.com/group/sphinx-dev/browse_thread/thread/852fbec28bc4ba15/719dbcf762c9db18?#719dbcf762c9db18 except that it scans the first part of a __doc__ attribute for some phrase. I can't spend any more time on this, however. * The docstrings become much longer now that we have to add additional empty lines. This is not very nice when using foo? or tab- completion in the notebook. Also the `` `` are annoying there. Is it not possible that the printing of the docstring there is simplified ? I think these are subsumed by this ticket: http://trac.sagemath.org/sage_trac/ticket/5653 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: trac ticket width and hgrc tips?
On Wed, 22 Apr 2009 14:42:21 -0700 (PDT)
mabshoff mabsh...@googlemail.com wrote:
On Apr 22, 12:52 pm, Nick Alexander ncalexan...@gmail.com wrote:
To override this in Firefox on Linux, I put
#content.ticket { width: 100% !important; }
Hmm, that seems to be a worthwhile change to me since these days
most people should not be limited by 800x600 displays any more?
Is anyone opposed to this change for some reason?
+1.
Hehe, if Nick likes it I think we are good to go :)
For the record: I changed site-packages/Trac-0.11.3-py2.5.egg/trac/
htdocs/css/ticket.css, but kept the orignial ticket.css as
ticket.css.orig.
On tickets which have a traceback, this screws up my display. The page
width grows to accommodate the longest line in the traceback, forcing me
to scroll right/left to read long lines.
See here for an example:
http://trac.sagemath.org/sage_trac/ticket/1158
Of course, I could just put the modified line back by using Pat's
userContent.css trick.
Cheers,
Burcin
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Error running Sage
Hello,
I have installed Sage as root on iMac/Leopard 10.5.6 from sources
using the normal procedure (tar, make, make test...). Everything looks
ok. Sage was installed on /Applications/sage-3.4/. Using Sage as a
normal user at Terminal:
cd /Applications/sage-3.4
./sage
OK! But... the command sage:maxima('3 + 4') gives several lines of
error. The last line:
TypeError: Unable to start maxima
Everything is ok if I run this command as root. This looks like a
permission problem. Any light ?
Thanks in advance!
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: trac ticket width and hgrc tips?
On Fri, 24 Apr 2009 14:56:51 +0200 Burcin Erocal bur...@erocal.org wrote: On Wed, 22 Apr 2009 14:42:21 -0700 (PDT) mabshoff mabsh...@googlemail.com wrote: For the record: I changed site-packages/Trac-0.11.3-py2.5.egg/trac/ htdocs/css/ticket.css, but kept the orignial ticket.css as ticket.css.orig. On tickets which have a traceback, this screws up my display. The page width grows to accommodate the longest line in the traceback, forcing me to scroll right/left to read long lines. See here for an example: http://trac.sagemath.org/sage_trac/ticket/1158 The problem seems to appear only with preview displays. Sorry for the noise. I still prefer the limited width though. I find text much easier to read when it doesn't span the whole screen. I'll put in Pat's customization to fix this. Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: trac ticket width and hgrc tips?
On Apr 24, 5:56 am, Burcin Erocal bur...@erocal.org wrote: On Wed, 22 Apr 2009 14:42:21 -0700 (PDT) SNIP Hi Burcin, On tickets which have a traceback, this screws up my display. The page width grows to accommodate the longest line in the traceback, forcing me to scroll right/left to read long lines. See here for an example: http://trac.sagemath.org/sage_trac/ticket/1158 Hmm, what browser are you using? Neither with FF 3 nor Safari I am seeing this problem. Of course, I could just put the modified line back by using Pat's userContent.css trick. Well, 100% seems to be overkill for me with a wide screen display, so I would compromise on 1024 pixels :) Cheers, Burcin Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Error running Sage
On Apr 24, 5:43 am, prof paulo.mo...@gmail.com wrote:
Hello,
Hi,
I have installed Sage as root on iMac/Leopard 10.5.6 from sources
using the normal procedure (tar, make, make test...). Everything looks
ok. Sage was installed on /Applications/sage-3.4/. Using Sage as a
normal user at Terminal:
cd /Applications/sage-3.4
./sage
OK! But... the command sage:maxima('3 + 4') gives several lines of
error. The last line:
TypeError: Unable to start maxima
Well, can you post the rest?
Everything is ok if I run this command as root. This looks like a
permission problem. Any light ?
Hmm, have you used Maxima before installing Sage? In that case check
for .maxima folder or something similar in the non-root user home
directory and rename them to get them out of the way. Another thing:
check for files or directories with non-7 bit ASCII names and move
them out of that users directory. It is an odd interaction between
clisp and the LANG env we set in Sage.
If that doesn't fix it I am not sure where to look next.
Can you start clisp, i.e. does !clisp work from Sage?
Thanks in advance!
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Error running Sage
Hi Michael,
Here is the complete procedure/output:
prof:~$ cd /Applications/sage-3.4/
prof:/Applications/sage-3.4$ ./sage
--
| Sage Version 3.4, Release Date: 2009-03-11 |
| Type notebook() for the GUI, and license() for information.|
--
sage: maxima('3+4')
---
TypeError Traceback (most recent call
last)
/Applications/sage-3.4/ipython console in module()
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __call__(self, x, name)
1000 return x
1001 if isinstance(x, basestring):
- 1002 return cls(self, x, name=name)
1003 try:
1004 return self._coerce_from_special_method(x)
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __init__(self, parent, value, is_name, name)
1375 except (TypeError, KeyboardInterrupt,
RuntimeError, ValueError), x:
1376 self._session_number = -1
- 1377 raise TypeError, x
1378 self._session_number = parent._session_number
1379
TypeError: Unable to start maxima
sage:
On Apr 24, 10:10 am, mabshoff mabsh...@googlemail.com wrote:
On Apr 24, 5:43 am, prof wrote:
Hello,
Hi,
I have installed Sage as root on iMac/Leopard 10.5.6 from sources
using the normal procedure (tar, make, make test...). Everything looks
ok. Sage was installed on /Applications/sage-3.4/. Using Sage as a
normal user at Terminal:
cd /Applications/sage-3.4
./sage
OK! But... the command sage:maxima('3 + 4') gives several lines of
error. The last line:
TypeError: Unable to start maxima
Well, can you post the rest?
Everything is ok if I run this command as root. This looks like a
permission problem. Any light ?
Hmm, have you used Maxima before installing Sage? In that case check
No, I have not used Maxima before.
for .maxima folder or something similar in the non-root user home
directory and rename them to get them out of the way. Another thing:
check for files or directories with non-7 bit ASCII names and move
them out of that users directory. It is an odd interaction between
clisp and the LANG env we set in Sage.
If that doesn't fix it I am not sure where to look next.
Can you start clisp, i.e. does !clisp work from Sage?
Thanks in advance!
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] OpenModelica
Hello all, Is there any plan to have OpenModelica integrated in SAGE? Does it make sense to integrate it? Is it even feasible to do that? Thank you. Regards, Pete --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.2.alpha0 released!
Successful build from source and all tests pass on both Suse 32-bit and Ubuntu 64-bit. John 2009/4/24 mabshoff mabsh...@googlemail.com: Hello folks, here goes 3.4.2.alpha0. It does not contain all the fixes I wanted, but I merged two large (200kb+) patches (#5610 and #5848) that touched a lot of files and that were in danger of bitrotting. Since I considered it pointless to force people to rebase potentially twice I pulled them both into alpha0. The source, upgrade bits and a sage.math-only binary should be available in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/ From here on the plan is to merge other reviewed patches (in case you are bored, there are about 80 patches to review in trac), fix some more issues and then get out rc0 on Sunday to have 3.4.2.final very early next week. Coverage right now is at 69% and there is a doctest patch for padics that brings that directory to 100% and gives us 2.1% globally, so I definitely want that one merged. Another thing to review and push hard are the pynac tickets and the not yet in trac patch for the symbolics switch. Mike Hansen mentioned he could post something today, so hopefully it will get reviewed until Sunday and merged to give the code a good beating during 3.4.2. If you have any patches in trac please make sure to check if they apply to alpha0 since they will get bounced back if they fail to merge. Cheers, Michael Merged in Sage 3.4.2.alpha0: #4809: Dan Drake, John Palmieri: the installation guide and constructions guide should be CC licensed [Reviewed by John Palmieri, Dan Drake] #5111: Mike Hansen, Bill Page: axiom -- fricas [Reviewed by Carl Witty] #5130: R. Andrew Ohana: create a prime_pi function that doesn't just compute len(prime_range(n) [Reviewed by Carl Witty, William Stein, Michael Abshoff] #5346: John Cremona: Some doctests in schemes/elliptic_curves/ ell_rational_field.py fail with optional database installed [Reviewed by Michael Abshoff] #5567: Wilfried Huss: bug in region_plot [Reviewed by Bill Cauchois] #5595: Robert Bradshaw: minor dependancy checking glitch [Reviewed by Carl Witty] #5610: John Palmieri: LaTeX customization [Reviewed by Robert Bradshaw, Rob Beezer] #5627: Karl-Dieter Crisman: Trivial typo in quadratic_nonresidue [Reviewed by Minh Van Nguyen] #5704: John Cremona: Implementation of finding elliptic curves with prescribed reduction over QQ [Reviewed by Robert Miller] #5751: Dan Bump: cartan_type now a method rather than attribute in weyl_characters.py [Reviewed by Anne Schilling] #5795: Simon King: Improved performance of MPolynomialRing_libsingular.__call__() [Reviewed by Martin Albrecht] #5803: Robert Bradshaw: Upgrade Cython to 0.11.1 [Reviewed by William Stein] #5809: Alex Ghitza: schemes/generic/hypersurface.py is completely broken [Reviewed by John Cremona] #5815: Mitesh Patel, Jason Grout: Disable TinyMCE in the live documentation [Reviewed by Jason Grout, Mitesh Patel] #5821: Robert Bradshaw: preparser incorrectly handles backslash operator inside strings (sometimes) [Reviewed by Carl Witty] #5822: William Stein: cusps -- implement action of the Galois group on cusps for congruence subgroups as on page 12 of Steven's Arithmetic on Modular Curves [Reviewed by John Cremona] #5836: Jason Grout: Make show() immediately show an image in the notebook [Reviewed by William Stein] #5848: John Palmieri: untabify Sage [Reviewed by Rob Beezer, Michael Abshoff] #5851: Chris Wuthrich: Convert 3 more elliptic curves files to ReST and add to reference manual [Reviewed by John Cremona] #5861: Michael Abshoff: Remove cocoa, four_ti_2, reduce and template interfaces since they do not work/are broken [Reviewed by Michael Abshoff] #5863: John Palmieri: remove some files from sage/algebras [Reviewed by William Stein] #5871: William Stein: solaris x86 3.4.1 -- code_bounds.py fails some plot doctests [Reviewed by Michael Abshoff] #5876: John Cremona: Vast speedup in P1List construction [Reviewed by William Stein, Robert Bradshaw] #5886: William Stein: Bug in free module homomorphism creation [Reviewed by Robert Bradshaw] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Fri, Apr 24, 2009 at 5:36 AM, Pat LeSmithe qed...@gmail.com wrote: chris wuthrich wrote: * In one of my files i have a line power_series = series. This produces the full docstring of series to appear twice in the documentation, once under series and once under power_series. How can I exclude the alias ? According to http://sphinx.pocoo.org/ext/autodoc.html the autodoc directives .. autoclass:: pAdicLseriesOrdinary :members: series, is_ordinary, is_supersingular might work in Sphinx v0.5 and .. autoclass:: pAdicLseriesOrdinary :exclude-members: power_series in Sphinx v0.6. However, I believe the current version of builder.py does not scan for custom directives when it auto-generates the .rst files. I don't know if it's OK simply to put them in a docstring. Another possibility is to add to builder.py an auto-skip-member() handler that skips certain methods, along the lines of http://groups.google.com/group/sphinx-dev/browse_thread/thread/852fbec28bc4ba15/719dbcf762c9db18?#719dbcf762c9db18 except that it scans the first part of a __doc__ attribute for some phrase. Of course, looking at __doc__ for a keyword won't help distinguish power_series from series after power_series = series. I definitely do like the idea of using keywords to the docstrings to control whether they show up in the reference manual, though. (This could override the current decision, which I think is non-underscore methods are included, underscore methods are not.) It seems like the first line of the docstring (on the same line as the triple-quotes) would be a good place for such a keyword: def foo(): rexclude Docs for foo. pass I really want about three different levels of reference manual for a lot of my code. For instance, sage/misc/sage_input.py has one function that's useful to people working from the command line or notebook, one class (with a bunch of methods) that's useful to people writing Sage library code (writing new types, and wanting to support sage_input on those types), and a bunch of classes that are only useful to people (only me, so far) working on sage_input itself. It would be nice to be able to mark these (public, library, and private, perhaps), and then be able to produce three different reference manuals (small, medium, and huge) with different subsets of the documentation. As far as aliases go, it should be possible to automatically detect aliases inside sphinx and produce appropriate documentation (once we decide what the appropriate documentation is). (This would mean patching sphinx, or forking the autodoc extension; hopefully this would be considered a useful feature that would be accepted upstream.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: OpenModelica
On Fri, Apr 24, 2009 at 6:56 AM, pepe balazovic.pe...@gmail.com wrote: Hello all, Is there any plan to have OpenModelica integrated in SAGE? No. Does it make sense to integrate it? Is it even feasible to do that? No, it would be a copyright violation to integrate OpenModelica and Sage in any way. OpenModelica is licensed under a GPL-incompatible license. I found the statement [Comment: note that the OSMC Public License, also its OSMC-GPL mode, is different from and incompatible with GPL. Therefore it is not possible to include any GPL-licensed contribution into OpenModelica.] here http://www.ida.liu.se/labs/pelab/modelica/OpenModelica/Documents/LICENSE.txt Thank you. Regards, Pete -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: f in ZZ[x] mod p gives ZZ[x]
On Fri, Apr 24, 2009 at 9:03 AM, Robert Miller rlmills...@gmail.com wrote: sage: x = polygen(ZZ) sage: f = 2*x^2 sage: f.mod(2)==0 False You should do f.mod? and read the docstring, which says: Return a representative for self modulo the ideal I (or the ideal generated by the elements of I if I is not an ideal.) I believe f itself is a representative for f mod the ideal 2. :-) You're assuming that the mod function does something interesting, but it is in this case just some generic code which does what its definition says, which in this case happens to be nothing. So make it better! :-) William sage: type(f.mod(2)) type 'sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint' Even this doesn't work: sage: R.x = ZZ[] sage: f.mod(2*R)==0 False But last I checked, 2 | 2x^2. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
I agree with all of this -- there are plenty of underscored functions which should be in the ref manual. If nothing else, then the __init__ functions of classes. When restifying files I have made sure that all the EXAMPLES:: from __init__ functions are copied into the class's own docstring since then they do appear in the ref manual. John 2009/4/24 Carl Witty carl.wi...@gmail.com: On Fri, Apr 24, 2009 at 5:36 AM, Pat LeSmithe qed...@gmail.com wrote: chris wuthrich wrote: * In one of my files i have a line power_series = series. This produces the full docstring of series to appear twice in the documentation, once under series and once under power_series. How can I exclude the alias ? According to http://sphinx.pocoo.org/ext/autodoc.html the autodoc directives .. autoclass:: pAdicLseriesOrdinary :members: series, is_ordinary, is_supersingular might work in Sphinx v0.5 and .. autoclass:: pAdicLseriesOrdinary :exclude-members: power_series in Sphinx v0.6. However, I believe the current version of builder.py does not scan for custom directives when it auto-generates the .rst files. I don't know if it's OK simply to put them in a docstring. Another possibility is to add to builder.py an auto-skip-member() handler that skips certain methods, along the lines of http://groups.google.com/group/sphinx-dev/browse_thread/thread/852fbec28bc4ba15/719dbcf762c9db18?#719dbcf762c9db18 except that it scans the first part of a __doc__ attribute for some phrase. Of course, looking at __doc__ for a keyword won't help distinguish power_series from series after power_series = series. I definitely do like the idea of using keywords to the docstrings to control whether they show up in the reference manual, though. (This could override the current decision, which I think is non-underscore methods are included, underscore methods are not.) It seems like the first line of the docstring (on the same line as the triple-quotes) would be a good place for such a keyword: def foo(): rexclude Docs for foo. pass I really want about three different levels of reference manual for a lot of my code. For instance, sage/misc/sage_input.py has one function that's useful to people working from the command line or notebook, one class (with a bunch of methods) that's useful to people writing Sage library code (writing new types, and wanting to support sage_input on those types), and a bunch of classes that are only useful to people (only me, so far) working on sage_input itself. It would be nice to be able to mark these (public, library, and private, perhaps), and then be able to produce three different reference manuals (small, medium, and huge) with different subsets of the documentation. As far as aliases go, it should be possible to automatically detect aliases inside sphinx and produce appropriate documentation (once we decide what the appropriate documentation is). (This would mean patching sphinx, or forking the autodoc extension; hopefully this would be considered a useful feature that would be accepted upstream.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] f in ZZ[x] mod p gives ZZ[x]
sage: x = polygen(ZZ) sage: f = 2*x^2 sage: f.mod(2)==0 False sage: type(f.mod(2)) type 'sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint' Even this doesn't work: sage: R.x = ZZ[] sage: f.mod(2*R)==0 False But last I checked, 2 | 2x^2. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Error running Sage
On Fri, Apr 24, 2009 at 6:30 AM, prof paulo.mo...@gmail.com wrote:
Hi Michael,
Here is the complete procedure/output:
prof:~$ cd /Applications/sage-3.4/
prof:/Applications/sage-3.4$ ./sage
--
| Sage Version 3.4, Release Date: 2009-03-11 |
| Type notebook() for the GUI, and license() for information. |
--
sage: maxima('3+4')
What happens if you type
sage: !maxima
?
William
---
TypeError Traceback (most recent call
last)
/Applications/sage-3.4/ipython console in module()
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __call__(self, x, name)
1000 return x
1001 if isinstance(x, basestring):
- 1002 return cls(self, x, name=name)
1003 try:
1004 return self._coerce_from_special_method(x)
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __init__(self, parent, value, is_name, name)
1375 except (TypeError, KeyboardInterrupt,
RuntimeError, ValueError), x:
1376 self._session_number = -1
- 1377 raise TypeError, x
1378 self._session_number = parent._session_number
1379
TypeError: Unable to start maxima
sage:
On Apr 24, 10:10 am, mabshoff mabsh...@googlemail.com wrote:
On Apr 24, 5:43 am, prof wrote:
Hello,
Hi,
I have installed Sage as root on iMac/Leopard 10.5.6 from sources
using the normal procedure (tar, make, make test...). Everything looks
ok. Sage was installed on /Applications/sage-3.4/. Using Sage as a
normal user at Terminal:
cd /Applications/sage-3.4
./sage
OK! But... the command sage:maxima('3 + 4') gives several lines of
error. The last line:
TypeError: Unable to start maxima
Well, can you post the rest?
Everything is ok if I run this command as root. This looks like a
permission problem. Any light ?
Hmm, have you used Maxima before installing Sage? In that case check
No, I have not used Maxima before.
for .maxima folder or something similar in the non-root user home
directory and rename them to get them out of the way. Another thing:
check for files or directories with non-7 bit ASCII names and move
them out of that users directory. It is an odd interaction between
clisp and the LANG env we set in Sage.
If that doesn't fix it I am not sure where to look next.
Can you start clisp, i.e. does !clisp work from Sage?
Thanks in advance!
Cheers,
Michael
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: version 3.4 and 3.4.1 fail to run under VMware
On Fri, Apr 24, 2009 at 4:28 AM, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 4:10 am, Lloyd Kilford l.kilf...@gmail.com wrote: Hi Lloyd, I have downloaded the images of versions 3.4 and 3.4.1 to run under VMware, but I get the following error message when I try to run sage: WARNING: This Sage install was built on a machine that supports instructions that are not available on this computer ... The following processor flags were on the build machine but are not on this computer: pni Can someone look into this, please? The problem in general is that your computer does not have SSE3 instructions that were used when building Sage leading to illegal instrucion - aborted errors during the runtime. So we added a check to warn users about it. So far, so good, but Sage 3.4.1 was supposed to fix this by introducing an SSE2 only mode and William told me that he build the Sage in the VMWare image in that mode. I would suspect this is a SNAFU since the env variable that William thought would get used SAGE_SIMD_FLAG is not the correct one, i.e. it is SAGE_SIMD_MODE. So I expect we will rebuild the VMWare image as well as the farm binaries and SkyNet once again right now :( Ironically there is a ticket against 3.4.2 to document this in README.txt - oh well ARGH!!! I thought it was SAGE_SIMD_FLAG, because that's definitely what you wrote somewhere on a trac ticket. I guess you changed it. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Apr 24, 9:25 am, John Cremona john.crem...@gmail.com wrote: I agree with all of this -- there are plenty of underscored functions which should be in the ref manual. If nothing else, then the __init__ functions of classes. When restifying files I have made sure that all the EXAMPLES:: from __init__ functions are copied into the class's own docstring since then they do appear in the ref manual. John In case underscored methods are not added to the reference manual any time soon, I've been working on a patch for the developer's guide suggesting exactly what you do: put the bulk of the documentation in the class's docstring, not in the __init__ docstring. See http://trac.sagemath.org/sage_trac/ticket/5588. John --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] pynac slower than sympy?
Hi,
I am puzzled by this:
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information.|
--
sage: var('x,y,z', ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.86 s, sys: 0.00 s, total: 3.86 s
Wall time: 3.86 s
sage:
Exiting SAGE (CPU time 0m3.90s, Wall time 0m26.84s).
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information.|
--
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 0.07 s, sys: 0.02 s, total: 0.09 s
Wall time: 1.23 s
sage:
Exiting SAGE (CPU time 0m0.12s, Wall time 0m9.59s).
Exiting spawned Maxima process.
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information.|
--
sage: from sympy import var, expand
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.23 s, sys: 0.03 s, total: 3.26 s
Wall time: 3.27 s
sage:
Exiting SAGE (CPU time 0m3.36s, Wall time 0m30.75s).
What am I doing wrong? Even pure python sympy is faster than pynac...
I got one student working on a C++ core, so we wanted to benchmark it
on something, but I am really confused by any benchmarks now, as
obviously something stupid is happening above, but I only discovered
that because the timings are so obviously slow. If they were faster, I
wouldn't notice anything and I would happily use those timings as
valid.
Ondrej
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: pynac slower than sympy?
Burcin and Mike -- Please read the below. There is an absolutely
*MASSIVE* performance regression in pynac that Burcin surely caused.
On Fri, Apr 24, 2009 at 10:35 AM, Ondrej Certik ond...@certik.cz wrote:
Hi,
I am puzzled by this:
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z', ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.86 s, sys: 0.00 s, total: 3.86 s
Wall time: 3.86 s
sage:
Exiting SAGE (CPU time 0m3.90s, Wall time 0m26.84s).
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 0.07 s, sys: 0.02 s, total: 0.09 s
Wall time: 1.23 s
sage:
Exiting SAGE (CPU time 0m0.12s, Wall time 0m9.59s).
Exiting spawned Maxima process.
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: from sympy import var, expand
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.23 s, sys: 0.03 s, total: 3.26 s
Wall time: 3.27 s
sage:
Exiting SAGE (CPU time 0m3.36s, Wall time 0m30.75s).
What am I doing wrong? Even pure python sympy is faster than pynac...
(1) You are not using sympy, for one:
sage: var('x,y,z')
(x, y, z)
Your var command doesn't inject x,y,z into the namespace!!
(2) I don't get the same times as you at all. I get pynac being 4
times faster than Maxima and 5.56 times faster than Sympy on
sage.math.
wst...@sage:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information.|
--
sage: var('x,y,z', ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.74 s, sys: 0.00 s, total: 0.74 s
Wall time: 0.75 s
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.09 s, sys: 0.01 s, total: 0.10 s
Wall time: 3.04 s
sage: from sympy import var, expand
sage: x,y,z=var('x,y,z')
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 4.11 s, sys: 0.06 s, total: 4.17 s
Wall time: 4.17 s
These times are all pitiful compared to the time that Singular takes right now:
sage: R.x,y,z = QQ[]
sage: f = (x+y+z+1)^7
sage: time g = f*(f+1)# also does expand
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
There was clearly a *major* performance regression, because in Sage-3.2:
wst...@sage:/disk/scratch/mabshoff-sage-releases/sage-3.2$ ./sage
--
| Sage Version 3.2, Release Date: 2008-11-20 |
| Type notebook() for the GUI, and license() for information.|
--
sage: var('x,y,z',ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.05 s, sys: 0.00 s, total: 0.05 s
Wall time: 0.05 s
I knew something was messed up about symbolics when I tried mhansen's
branch recently. Burcin, what did you do!?
I got one student working on a C++ core, so we wanted to benchmark it
on something, but I am really confused by any benchmarks now, as
obviously something stupid is happening above, but I only discovered
that because the timings are so obviously slow. If they were faster, I
wouldn't notice anything and I would happily use those timings as
valid.
Ondrej
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: f in ZZ[x] mod p gives ZZ[x]
Worse still: sage: x = polygen(QQ) sage: h = 4*x sage: h%3 0 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: is_Integer() function semantics
Thanks for all the helpful suggestions. I did not realize that is_Integer() was deprecated. On Apr 22, 2:00 am, John Cremona john.crem...@gmail.com wrote: This is precisely why we deprecated all the is_*() functions for end-user use: -- | Sage Version 3.4.1.rc4, Release Date: 2009-04-19 | | Type notebook() for the GUI, and license() for information. | -- sage: is_Integer(3/2+1/2) /home/masgaj/.sage/temp/host_56_150/29373/_home_masgaj__sage_init_sage_0.py:1: DeprecationWarning: Using is_Integer from the top level is deprecated since it was designed to be used by developers rather than end users. It most likely does not do what you would expect it to do. If you really need to use it, import it from the module that it is defined in. # -*- coding: utf-8 -*- False sage: (3/2+1/2).is_integral() True The is_*() functions just test the type of an abject (in programming terms): sage: type(3/2+1/2) type 'sage.rings.rational.Rational' and the result of 3/2+1/2 is of type Rational. Mathematically, of course, the same number can be an integer and a rational (and a real and a complex and ...). John 2009/4/22 Robert Bradshaw rober...@math.washington.edu: On Apr 21, 2009, at 10:54 PM, Craig Citro wrote: In module sage.rings.integer is_Integer(3/2+1/2) returns False The expected output should be True as 3/2+1/2 = 2. I was planning to use this function to check if the result of division is a whole number. You could also use the is_integral method of rational numbers: sage: n = 3/2 + 1/2 sage: n.is_integral() True (This function also exists on Integers, so you could even use it in situations where you weren't sure if you had an honest Integer or an integer masquerading as a Rational.) Another option is sage: 3/2 + 1/2 in ZZ True sage: 3/2 + 1/3 in ZZ False - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: f in ZZ[x] mod p gives ZZ[x]
Worse still: sage: x = polygen(QQ) sage: h = 4*x sage: h%3 0 Over QQ[x], isn't 4*x = 3 * (4/3*x) ? Over ZZ, it's fine: sage: x = polygen(ZZ) sage: h = 4*x sage: h%3 x -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pynac slower than sympy?
On Fri, Apr 24, 2009 at 10:52 AM, William Stein wst...@gmail.com wrote:
Burcin and Mike -- Please read the below. There is an absolutely
*MASSIVE* performance regression in pynac that Burcin surely caused.
On Fri, Apr 24, 2009 at 10:35 AM, Ondrej Certik ond...@certik.cz wrote:
Hi,
I am puzzled by this:
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z', ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.86 s, sys: 0.00 s, total: 3.86 s
Wall time: 3.86 s
sage:
Exiting SAGE (CPU time 0m3.90s, Wall time 0m26.84s).
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 0.07 s, sys: 0.02 s, total: 0.09 s
Wall time: 1.23 s
sage:
Exiting SAGE (CPU time 0m0.12s, Wall time 0m9.59s).
Exiting spawned Maxima process.
ond...@raven:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: from sympy import var, expand
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 3.23 s, sys: 0.03 s, total: 3.26 s
Wall time: 3.27 s
sage:
Exiting SAGE (CPU time 0m3.36s, Wall time 0m30.75s).
What am I doing wrong? Even pure python sympy is faster than pynac...
(1) You are not using sympy, for one:
I am pretty sure I am.
sage: var('x,y,z')
(x, y, z)
Your var command doesn't inject x,y,z into the namespace!!
I am pretty sure it is:
sage: from sympy import var, expand
sage: var('x,y,z')
(x, y, z)
sage: type(x)
class 'sympy.core.symbol.Symbol'
(2) I don't get the same times as you at all. I get pynac being 4
times faster than Maxima and 5.56 times faster than Sympy on
sage.math.
I might have screwed something up on my machine. I compiled from
source and I used the systemwide gfortran. Otherwise I did no other
changes.
wst...@sage:~$ sage
--
| Sage Version 3.4.1, Release Date: 2009-04-21 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z', ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.74 s, sys: 0.00 s, total: 0.74 s
Wall time: 0.75 s
sage: var('x,y,z')
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.09 s, sys: 0.01 s, total: 0.10 s
Wall time: 3.04 s
sage: from sympy import var, expand
sage: x,y,z=var('x,y,z')
sage: f = (x+y+z+1)^7
sage: time g = expand(f*(f+1))
CPU times: user 4.11 s, sys: 0.06 s, total: 4.17 s
Wall time: 4.17 s
These times are all pitiful compared to the time that Singular takes right
now:
sage: R.x,y,z = QQ[]
sage: f = (x+y+z+1)^7
sage: time g = f*(f+1) # also does expand
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
There was clearly a *major* performance regression, because in Sage-3.2:
wst...@sage:/disk/scratch/mabshoff-sage-releases/sage-3.2$ ./sage
--
| Sage Version 3.2, Release Date: 2008-11-20 |
| Type notebook() for the GUI, and license() for information. |
--
sage: var('x,y,z',ns=1)
(x, y, z)
sage: f = (x+y+z+1)^7
sage: time g=expand(f*(f+1))
CPU times: user 0.05 s, sys: 0.00 s, total: 0.05 s
Wall time: 0.05 s
I knew something was messed up about symbolics when I tried mhansen's
branch recently. Burcin, what did you do!?
Maybe something with numbers, or something else. In my experience it's
super easy to slow things down if one doesn't pay attention to it.
Ondrej
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Error running Sage
The problem: I have a file with non-7 bit ASCII name. After rename it,
everything is working fine!
Thanks a lot for your time!
On Apr 24, 12:56 pm, William Stein wst...@gmail.com wrote:
On Fri, Apr 24, 2009 at 6:30 AM, prof paulo.mo...@gmail.com wrote:
Hi Michael,
Here is the complete procedure/output:
prof:~$ cd /Applications/sage-3.4/
prof:/Applications/sage-3.4$ ./sage
--
| Sage Version 3.4, Release Date: 2009-03-11 |
| Type notebook() for the GUI, and license() for information. |
--
sage: maxima('3+4')
What happens if you type
sage: !maxima
?
William
---
TypeError Traceback (most recent call
last)
/Applications/sage-3.4/ipython console in module()
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __call__(self, x, name)
1000 return x
1001 if isinstance(x, basestring):
- 1002 return cls(self, x, name=name)
1003 try:
1004 return self._coerce_from_special_method(x)
/Applications/sage-3.4/local/lib/python2.5/site-packages/sage/
interfaces/expect.pyc in __init__(self, parent, value, is_name, name)
1375 except (TypeError, KeyboardInterrupt,
RuntimeError, ValueError), x:
1376 self._session_number = -1
- 1377 raise TypeError, x
1378 self._session_number = parent._session_number
1379
TypeError: Unable to start maxima
sage:
On Apr 24, 10:10 am, mabshoff mabsh...@googlemail.com wrote:
On Apr 24, 5:43 am, prof wrote:
Hello,
Hi,
I have installed Sage as root on iMac/Leopard 10.5.6 from sources
using the normal procedure (tar, make, make test...). Everything looks
ok. Sage was installed on /Applications/sage-3.4/. Using Sage as a
normal user at Terminal:
cd /Applications/sage-3.4
./sage
OK! But... the command sage:maxima('3 + 4') gives several lines of
error. The last line:
TypeError: Unable to start maxima
Well, can you post the rest?
Everything is ok if I run this command as root. This looks like a
permission problem. Any light ?
Hmm, have you used Maxima before installing Sage? In that case check
No, I have not used Maxima before.
for .maxima folder or something similar in the non-root user home
directory and rename them to get them out of the way. Another thing:
check for files or directories with non-7 bit ASCII names and move
them out of that users directory. It is an odd interaction between
clisp and the LANG env we set in Sage.
If that doesn't fix it I am not sure where to look next.
Can you start clisp, i.e. does !clisp work from Sage?
Thanks in advance!
Cheers,
Michael
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: Well, we can try. But the whole point is that is someone posts a pari- svn.spkg which fixes bugs in functions Sage does not use and adds functionality that is asked for by people no one will be willing to wait 3 or 6 months to merge that. It might be more feasible to just package Sage before that change and then hope in the next couple months upstream will release. Right, I'm not suggesting Sage wait 3-6 months to merge exciting new code, but instead that one try to get upstream to agree to do a release with those features prior to the next one fo these stable releases. Well, you pushed patches upstream that contain GNUisms and I will end up patching it out of the sources again, so I am not too happy about that since upstream way too often does not understand that GNUisms are bad or are totally unaware of the problem in the first place. Yes, there were a few early versions of patches to add shared library support written by Francois Bissey and myself that were merged by various upstream library maintainers and did have GNUisms. In more recent work, I've been encouraging upstream library maintainers to use libtool when adding shared library support. NTL is one example of a piece of software that is now doing this. I believe NTL 5.5 supports building a shared library with non-GNU make. If you have any problems with how NTL's shared library support was added, please let me know, as I'm thinking about sending patches replacing the early shared library support that has GNUisms with using libtool. I don't know of any patch but the NTL one where this could be the case. We have contacted Victor Shoup several times to speak or visit a Sage days and he has *never* responded. The author of that patch works at NYU, i.e. the same place as Victor and if he never got around to get the patch merged than I can hardly call that our fault. As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Another author we have contacted via numerous people as well as multiple times is the cddlib author and he has also *never* responded to us. The cddlib maintainer has responded to me three or four times, though generally very slowly. But a Fedora guy was unsuccessful in contacting him and ended up emailing me asking how to reach him. I consider this completely wrong. Can you mention some concrete examples? The ones that caused trouble for me are the NTL patch and the NullspaceMP function added to iml. It sounds like you are planning to work to avoid these types of problems in the future, which is all that's important to me here. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, Jason Grout wrote: Jqueryui can actually be updated to the latest release, which is later than the svn version shipping with Sage, so that shouldn't be a problem. Matplotlib should be releasing a new version Real Soon Now, and then can be upgraded. Currently, we use some features from SVN that are not available in the latest release (arrow drawing stuff). We also ship an SVN version of scipy. Before a couple of months ago, everyone did, though (I think even debian), since it hadn't had a release in a very long time. We should upgrade to the latest release of scipy now, though. If people have time to do these updates before the Sage 4.0 release, I would be grateful. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: f in ZZ[x] mod p gives ZZ[x]
Yeah, I should have mentioned that my point was that maybe h%3 should raise an error over QQ. On Apr 24, 11:00 am, Craig Citro craigci...@gmail.com wrote: Worse still: sage: x = polygen(QQ) sage: h = 4*x sage: h%3 0 Over QQ[x], isn't 4*x = 3 * (4/3*x) ? Over ZZ, it's fine: sage: x = polygen(ZZ) sage: h = 4*x sage: h%3 x -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Fri, Apr 24, 2009 at 8:09 AM, Carl Witty carl.wi...@gmail.com wrote: As far as aliases go, it should be possible to automatically detect aliases inside sphinx and produce appropriate documentation (once we decide what the appropriate documentation is). (This would mean patching sphinx, or forking the autodoc extension; hopefully this would be considered a useful feature that would be accepted upstream.) Yes, this is relatively easy to do since the __name__ of an aliased method is different than the name in the class namespace under which it appears. For example, sage: x.numerical_approx.__name__ 'n' --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: partial success: notebook latex, adding \usepackage, using tikz
On Apr 16, 3:25 pm, John H Palmieri jhpalmier...@gmail.com wrote:
On Apr 16, 2:31 pm, mabshoff mabsh...@googlemail.com wrote:
On Apr 16, 1:41 pm, gerhard ge01...@yahoo.de wrote:
Hi,
This started out in grading notebooks, but does not really belong
there.
-
I am happy to report the functionality to modify
the latex header for notebook output is already present in sage:
sage: import sage.misc.latex as l
sage: l.LATEX_HEADER+='\\def \\pgfsysdriver {pgfsys-dvips.def}\n
\\usepackage{tikz\n
\\usetikzlibrary
{shapes,fit,positioning}\n'
sage: print 'LATEX_HEADER\n', l.LATEX_HEADER
does work as expected.
Yes, but I would not call the above construct elegant, so having
something cleaner and more accessible for the average user would be
nice. John Palmieri posted a patch to trac, so hopefully it will be
reviewed soon.
Well, I *hope* to post a patch to trac soon, but I haven't actually
done it yet.
John
Try this out:
http://trac.sagemath.org/sage_trac/ticket/5791
and see the pictures at
http://sage.math.washington.edu/home/palmieri/misc/foobar.png
http://sage.math.washington.edu/home/palmieri/misc/ext.png
I haven't tried it with tikz, by the way.
John
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Commutative diagrams in notebook
On Apr 14, 11:56 pm, mabshoff mabsh...@googlemail.com wrote:
On Apr 13, 6:51 am, William Stein wst...@gmail.com wrote:
On Mon, Apr 13, 2009 at 3:55 AM, gerhard ge01...@yahoo.de wrote:
just to get back to the original question:
did 'inserting a usepackage{}' command ever get resolved?
No. Somebody should at least create a trac ticket.
I don't think anybody did, so here it
is:http://trac.sagemath.org/sage_trac/ticket/5791
Cheers,
Michael
I have a patch for this now; please try it out.
John
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, Jason Grout wrote: Jqueryui can actually be updated to the latest release, which is later than the svn version shipping with Sage, so that shouldn't be a problem. Matplotlib should be releasing a new version Real Soon Now, and then can be upgraded. Currently, we use some features from SVN that are not available in the latest release (arrow drawing stuff). We also ship an SVN version of scipy. Before a couple of months ago, everyone did, though (I think even debian), since it hadn't had a release in a very long time. We should upgrade to the latest release of scipy now, though. If people have time to do these updates before the Sage 4.0 release, I would be grateful. -Tim Abbott On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Ben --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 11:27 am, Tim Abbott tabb...@mit.edu wrote: Hi Tim, On Thu, 23 Apr 2009, Jason Grout wrote: Jqueryui can actually be updated to the latest release, which is later than the svn version shipping with Sage, so that shouldn't be a problem. Matplotlib should be releasing a new version Real Soon Now, and then can be upgraded. Currently, we use some features from SVN that are not available in the latest release (arrow drawing stuff). We also ship an SVN version of scipy. Before a couple of months ago, everyone did, though (I think even debian), since it hadn't had a release in a very long time. We should upgrade to the latest release of scipy now, though. If people have time to do these updates before the Sage 4.0 release, I would be grateful. Well, the plan is to get everything up to date in or shortly after 4.0. Due to the time you have available it seems prudent to just get fixes in you find while looking at 4.0.x and to do subsequent releases without merging anything that isn't convenient to you. But that should happen quickly. -Tim Abbott Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 2:12 pm, Ben Goodrich goodrich@gmail.com wrote: On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: SNIP Hi Ben, On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Sure. In general anything in Debian stable one day will be woefully out of date by the time the freeze in Debian is over. I think the only viable option to use Sage in Debian is to use it from experimental/testing since any support request for say a year old version of Sage will likely start with the question Can someone reproduce this in the current release. Any patch from our end will only go in the next release unless we decide one day to do support some stable release for a while (and I am honestly not seeing that happening for a while). So having Ubuntu package Sage like in 9.04 and having that distro live for a year (assuming they had packaged something current) seems to be reasonable for the casual user who does not want to live on the bleeding edge of Sage. Ben Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 11:26 am, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, mabshoff wrote: Hi Tim, SNIP Well, you pushed patches upstream that contain GNUisms and I will end up patching it out of the sources again, so I am not too happy about that since upstream way too often does not understand that GNUisms are bad or are totally unaware of the problem in the first place. Yes, there were a few early versions of patches to add shared library support written by Francois Bissey and myself that were merged by various upstream library maintainers and did have GNUisms. In more recent work, I've been encouraging upstream library maintainers to use libtool when adding shared library support. Well, according to http://www.shoup.net/ntl/doc/tour-unix.html#shared If you set SHARED=on, then behind the scenes, the procedure used by the makefile changes a bit. In particular, the magical GNU program libtool is used to deal with all idiosyncracies of shared libraries. You may need to set the configuration variable LIBTOOL, to point to another version of libtool. For example, on Mac OSX, the built-in command called libtool is not actually the GNU libtool program; in this case, you will want to set LIBTOOL=glibtool. On other systems, it may be necssary to downlaod and install a fresh copy of the libtool program (which can be obtained from here). Note that if SHARED=on, then in addition to using the libtool program, the makefile relies on features specific to GNU make. Is that correct or are the GNUisms Victor's fault? NTL is one example of a piece of software that is now doing this. I believe NTL 5.5 supports building a shared library with non-GNU make. If you have any problems with how NTL's shared library support was added, please let me know, as I'm thinking about sending patches replacing the early shared library support that has GNUisms with using libtool. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. I don't know of any patch but the NTL one where this could be the case. We have contacted Victor Shoup several times to speak or visit a Sage days and he has *never* responded. The author of that patch works at NYU, i.e. the same place as Victor and if he never got around to get the patch merged than I can hardly call that our fault. As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Ok. Another author we have contacted via numerous people as well as multiple times is the cddlib author and he has also *never* responded to us. The cddlib maintainer has responded to me three or four times, though generally very slowly. But a Fedora guy was unsuccessful in contacting him and ended up emailing me asking how to reach him. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. I consider this completely wrong. Can you mention some concrete examples? The ones that caused trouble for me are the NTL patch and the NullspaceMP function added to iml. There is a new upstream-ish release of IML whcih should have this code. It sounds like you are planning to work to avoid these types of problems in the future, which is all that's important to me here. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. -Tim Abbott Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 5:20 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 2:12 pm, Ben Goodrich goodrich@gmail.com wrote: On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: SNIP Hi Ben, On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Sure. In general anything in Debian stable one day will be woefully out of date by the time the freeze in Debian is over. I think the only viable option to use Sage in Debian is to use it from experimental/testing since any support request for say a year old version of Sage will likely start with the question Can someone reproduce this in the current release. Any patch from our end will only go in the next release unless we decide one day to do support some stable release for a while (and I am honestly not seeing that happening for a while). So having Ubuntu package Sage like in 9.04 and having that distro live for a year (assuming they had packaged something current) seems to be reasonable for the casual user who does not want to live on the bleeding edge of Sage. Ben Cheers, Michael Right, anyone (mostly servers) using Debian stable or oldstable is not going to be able to keep up with Sage easily. But what I think Tim is saying is that he can't easily get a recent version of Sage into unstable (and subsequently testing) because unstable and especially testing usually have official releases of things Sage depends on. So, I was just suggesting that we could perhaps convince Debian maintainers of Sage dependencies to put pre-release versions into experimental, in addition to the official versions they maintain for unstable / testing. This would be annoying for them but maybe they would do it if we asked nicely. Then, Tim can get Sage 4.x into experimental when it is convenient for him, while Sage 3.0.x stays in unstable and testing until there is a window to sync some relatively recent version of Sage with 100% officially released dependencies. Experimental, more so than unstable, does tend to have pre-releases of packages. Ben --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 2:26 pm, Tim Abbott tabb...@mit.edu wrote: As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Actually, I've been physically at NYU since last July, i.e. almost a year. But Victor has been away on sabbatical, I haven't even met him face-to-face yet. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 2:50 pm, Ben Goodrich goodrich@gmail.com wrote: SNIP Hi Ben, Right, anyone (mostly servers) using Debian stable or oldstable is not going to be able to keep up with Sage easily. Agreed, but I think you misjudge the number of people running Debian stable on non-server scenarios. It is also quite common I believe to run a Sage server on distributions which aren't targeted at the desktop. Half a decade ago when there was no Ubuntu this kind of setup (without Sage obviously) was quite common, but these days with Ubuntu and their normal supported life cycle of a year this is less pressing. But I think there is still a significant number of Debian 4 users out there who are only slowly upgrading to Debian 5. When you analyze the download numbers the most prominent Linux version is the 32 bit Ubuntu binary which did surprise me initially since I assumed people would be running 64 bit linux everywhere. The second most popular download for linux was the 32 bit Debian binary, so there is definitely demand for Sage on Ubuntu as well as Debian. But what I think Tim is saying is that he can't easily get a recent version of Sage into unstable (and subsequently testing) because unstable and especially testing usually have official releases of things Sage depends on. Yes, I understand that. So, I was just suggesting that we could perhaps convince Debian maintainers of Sage dependencies to put pre-release versions into experimental, in addition to the official versions they maintain for unstable / testing. This would be annoying for them but maybe they would do it if we asked nicely. Then, Tim can get Sage 4.x into experimental when it is convenient for him, while Sage 3.0.x stays in unstable and testing until there is a window to sync some relatively recent version of Sage with 100% officially released dependencies. Absolutely. Looking at my time table I don't think 100% of the issues will be resolved in 4.0, but we can work with Tim to get it all sorted out in subsequent bug fix releases 4.0.x before going after the pari- svn update for example. So the following packages need to be sorted out: * numpy to 1.3 * scipy to 0.7 (maybe 0.7.1 if it is out by then) * NTL to 5.5 * jquery * matplotlib (I know they have been talking about doing a release and I believe they have a bugfix for the rare (libpng is size zero issue, but I am unclear when they will release) Is there anything else? Experimental, more so than unstable, does tend to have pre-releases of packages. Ben Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 3:07 pm, David Harvey dmhar...@cims.nyu.edu wrote: On Apr 24, 2:26 pm, Tim Abbott tabb...@mit.edu wrote: Hi David, As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Actually, I've been physically at NYU since last July, i.e. almost a year. But Victor has been away on sabbatical, I haven't even met him face-to-face yet. Yeah, I knew about the sabbatical of Victor and you being at NYU already and I think we talked about this at SD 10. I am not blaming you by any means, I just wanted to point out that it takes a substantial amount of determination and/or luck to get an email back from Victor it seems ;) david Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 3:09 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 2:50 pm, Ben Goodrich goodrich@gmail.com wrote: SNIP So the following packages need to be sorted out: * numpy to 1.3 * scipy to 0.7 (maybe 0.7.1 if it is out by then) * NTL to 5.5 * jquery * matplotlib (I know they have been talking about doing a release and I believe they have a bugfix for the rare (libpng is size zero issue, but I am unclear when they will release) Is there anything else? Oops, forgot to mention IML. I have stuffed all this at http://wiki.sagemath.org/debian/sage-4.0.x-in-experimental and I think any info from Tim I missed or he will discover in the future should be added there. I will add ticket link for existing spkg updates and open tickets for the issues that are not in trac yet. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Fri, 24 Apr 2009, mabshoff wrote: Is that correct or are the GNUisms Victor's fault? I would assume that is correct. I didn't actually write any of the code for NTL 5.5; Victor did all the work there. That said, I thought his intention was to not require GNU make as he mentioned it as one of his goals when discussing with me; I guess that was only important when SHARED=off. Looking at the code there just seems to be one GNUism in the makefile: $(OBJ:.o=.lo). This is probably removable with a bit of work. One could fix the LIBTOOL=glibtool problem by adding a check for OS X to NTL's wizard. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. Work on both of those was early. But I didn't write the patch for polybori that was merged; that was done by the upstream developers using some scons options. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. Sure, I can do that. Just to be super clear, you want me to do this for all such contact, not just cddlib, right? There is a new upstream-ish release of IML whcih should have this code. Yes, I was able to get iml upstream to do a release with the relevant code; it was just a problem for me at the time. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. Right, I should expect to have a sampling bias problem where I only notice when the patches don't end up upstream promptly :) -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 24, 3:30 pm, Tim Abbott tabb...@mit.edu wrote: On Fri, 24 Apr 2009, mabshoff wrote: Hi Tim, Is that correct or are the GNUisms Victor's fault? I would assume that is correct. I didn't actually write any of the code for NTL 5.5; Victor did all the work there. That said, I thought his intention was to not require GNU make as he mentioned it as one of his goals when discussing with me; I guess that was only important when SHARED=off. Looking at the code there just seems to be one GNUism in the makefile: $(OBJ:.o=.lo). This is probably removable with a bit of work. Well, don't worry about it too much. As long as freetype deliberately uses gmake features (and refuses to remove them) Sage cannot be build with a pure BSD-ish make anyway. I just want upstream to be aware of the problem and not add to the problem. One could fix the LIBTOOL=glibtool problem by adding a check for OS X to NTL's wizard. Yeah, I am not sure what Victor is talking about. If you install XCode you will have libtool on OSX. It might be that he is using MacPorts or Fink where things are different. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. Work on both of those was early. But I didn't write the patch for polybori that was merged; that was done by the upstream developers using some scons options. Sure, but if you wouldn't have complained the code would have never been added ;) Seriously: library versioning matters a lot of distribution packaging, but it seriously annoys me and creates problems, i.e. there is a whole set of of FreeBSD fixes in trac now that I will hopefully all merge in 3.4.2.rc0 today that are caused by libtool friends. None of this is your fault, but there are just two different forces at play here and we need to find an equilibrium. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. Sure, I can do that. Just to be super clear, you want me to do this for all such contact, not just cddlib, right? Yes, I would like to be CCed on anything offlist to upstream code in Sage related to Debian packaging. Feel free to use your own judgment, i.e. if you feel uncomfortable for any reason just drop me from the CC. In some cases don't expect a reply, but you can assume I will read every email. There is a new upstream-ish release of IML whcih should have this code. Yes, I was able to get iml upstream to do a release with the relevant code; it was just a problem for me at the time. Ok, last time we sat down with Arne there was a problem with OSX, but I will look into this. It is a non-Debian issue, so if we cannot get Arne to do a release we will just conditionally patch it out in the spkg. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. Right, I should expect to have a sampling bias problem where I only notice when the patches don't end up upstream promptly :) Indeed :) -Tim Abbott Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.2.alpha0 released!
mabshoff wrote: Hello folks, here goes 3.4.2.alpha0. It does not contain all the fixes I wanted, but I merged two large (200kb+) patches (#5610 and #5848) that touched a lot of files and that were in danger of bitrotting. Since I considered it pointless to force people to rebase potentially twice I pulled them both into alpha0. The source, upgrade bits and a sage.math-only binary should be available in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/ On Fedora 9, 32 bit, fresh build: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 413: sage: M.determinant() Expected: 4*x - 6 Got: determinant(sage513) ** 1 items had failures: On retry: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 214: sage: -matrix(SR, 2, range(4)) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/sagedoctest.py, line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1172, in run_one_example compileflags, 1) in test.globs File doctest __main__.example_11[2], line 1, in module -matrix(SR, Integer(2), range(Integer(4)))###line 214: sage: -matrix(SR, 2, range(4)) File matrix0.pyx, line 1497, in sage.matrix.matrix0.Matrix.__repr__ (sage/matrix/matrix0.c:7963) File matrix0.pyx, line 1526, in sage.matrix.matrix0.Matrix.str (sage/matrix/matrix0.c:8252) File matrix0.pyx, line 172, in sage.matrix.matrix0.Matrix.list (sage/matrix/matrix0.c:2839) File matrix_symbolic_dense.pyx, line 349, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense._list (sage/matrix/matrix_symbolic_dense.c:4257) File matrix_symbolic_dense.pyx, line 123, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense.get_unsafe (sage/matrix/matrix_symbolic_dense.c:3011) File /home/jaap/downloads/sage-3.4.2.alpha0/local/lib/python2.5/site-packages/sage/calculus/calculus.py, line 10261, in symbolic_expression_from_maxima_string raise TypeError, unable to make sense of Maxima expression '%s' in Sage%s TypeError: unable to make sense of Maxima expression '(-sage196)[1,1]' in Sage ** 1 items had failures: 1 of 3 in __main__.example_11 ***Test Failed*** 1 failures. For whitespace errors, see the file /home/jaap/downloads/sage-3.4.2.alpha0/tmp/.doctest_matrix_symbolic_dense.py [204.6 s] exit code: 1024 -- The following tests failed: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx Total time for all tests: 204.6 seconds [j...@paix sage-3.4.2.alpha0]$ What is going on here? Can anyone reproduce this? Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.2.alpha0 released!
On Fri, Apr 24, 2009 at 4:00 PM, Jaap Spies j.sp...@hccnet.nl wrote: mabshoff wrote: Hello folks, here goes 3.4.2.alpha0. It does not contain all the fixes I wanted, but I merged two large (200kb+) patches (#5610 and #5848) that touched a lot of files and that were in danger of bitrotting. Since I considered it pointless to force people to rebase potentially twice I pulled them both into alpha0. The source, upgrade bits and a sage.math-only binary should be available in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/ On Fedora 9, 32 bit, fresh build: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 413: sage: M.determinant() Expected: 4*x - 6 Got: determinant(sage513) ** 1 items had failures: On retry: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 214: sage: -matrix(SR, 2, range(4)) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/sagedoctest.py, line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1172, in run_one_example compileflags, 1) in test.globs File doctest __main__.example_11[2], line 1, in module -matrix(SR, Integer(2), range(Integer(4)))###line 214: sage: -matrix(SR, 2, range(4)) File matrix0.pyx, line 1497, in sage.matrix.matrix0.Matrix.__repr__ (sage/matrix/matrix0.c:7963) File matrix0.pyx, line 1526, in sage.matrix.matrix0.Matrix.str (sage/matrix/matrix0.c:8252) File matrix0.pyx, line 172, in sage.matrix.matrix0.Matrix.list (sage/matrix/matrix0.c:2839) File matrix_symbolic_dense.pyx, line 349, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense._list (sage/matrix/matrix_symbolic_dense.c:4257) File matrix_symbolic_dense.pyx, line 123, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense.get_unsafe (sage/matrix/matrix_symbolic_dense.c:3011) File /home/jaap/downloads/sage-3.4.2.alpha0/local/lib/python2.5/site-packages/sage/calculus/calculus.py, line 10261, in symbolic_expression_from_maxima_string raise TypeError, unable to make sense of Maxima expression '%s' in Sage%s TypeError: unable to make sense of Maxima expression '(-sage196)[1,1]' in Sage ** 1 items had failures: 1 of 3 in __main__.example_11 ***Test Failed*** 1 failures. For whitespace errors, see the file /home/jaap/downloads/sage-3.4.2.alpha0/tmp/.doctest_matrix_symbolic_dense.py [204.6 s] exit code: 1024 -- The following tests failed: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx Total time for all tests: 204.6 seconds [j...@paix sage-3.4.2.alpha0]$ What is going on here? Can anyone reproduce this? Can *you* reproduce it repeatedly? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4.2.alpha0 released!
William Stein wrote: [...] Can *you* reproduce it repeatedly? One again: [j...@paix sage-3.4.2.alpha0]$ ./sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 214: sage: -matrix(SR, 2, range(4)) Exception raised: Traceback (most recent call last): File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/sagedoctest.py, line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File /home/jaap/downloads/sage-3.4.2.alpha0/local/bin/ncadoctest.py, line 1172, in run_one_example compileflags, 1) in test.globs File doctest __main__.example_11[2], line 1, in module -matrix(SR, Integer(2), range(Integer(4)))###line 214: sage: -matrix(SR, 2, range(4)) File matrix0.pyx, line 1497, in sage.matrix.matrix0.Matrix.__repr__ (sage/matrix/matrix0.c:7963) File matrix0.pyx, line 1526, in sage.matrix.matrix0.Matrix.str (sage/matrix/matrix0.c:8252) File matrix0.pyx, line 172, in sage.matrix.matrix0.Matrix.list (sage/matrix/matrix0.c:2839) File matrix_symbolic_dense.pyx, line 349, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense._list (sage/matrix/matrix_symbolic_dense.c:4257) File matrix_symbolic_dense.pyx, line 123, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense.get_unsafe (sage/matrix/matrix_symbolic_dense.c:3011) File /home/jaap/downloads/sage-3.4.2.alpha0/local/lib/python2.5/site-packages/sage/calculus/calculus.py, line 10261, in symbolic_expression_from_maxima_string raise TypeError, unable to make sense of Maxima expression '%s' in Sage%s TypeError: unable to make sense of Maxima expression '(-sage196)[1,1]' in Sage ** File /home/jaap/downloads/sage-3.4.2.alpha0/devel/sage/sage/matrix/matrix_symbolic_dense.pyx, line 413: sage: M.determinant() Expected: 4*x - 6 Got: determinant(sage513) ** 2 items had failures: 1 of 3 in __main__.example_11 1 of 9 in __main__.example_18 ***Test Failed*** 2 failures. For whitespace errors, see the file /home/jaap/downloads/sage-3.4.2.alpha0/tmp/.doctest_matrix_symbolic_dense.py [152.4 s] exit code: 1024 -- The following tests failed: sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx Total time for all tests: 152.4 seconds [j...@paix sage-3.4.2.alpha0]$ Jaap William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: f in ZZ[x] mod p gives ZZ[x]
On Fri, Apr 24, 2009 at 11:53 AM, Robert Miller rlmills...@gmail.com wrote: Yeah, I should have mentioned that my point was that maybe h%3 should raise an error over QQ. Over QQ, the number 3 generates the unit ideal, so everything is 0 modulo it :-). William On Apr 24, 11:00 am, Craig Citro craigci...@gmail.com wrote: Worse still: sage: x = polygen(QQ) sage: h = 4*x sage: h%3 0 Over QQ[x], isn't 4*x = 3 * (4/3*x) ? Over ZZ, it's fine: sage: x = polygen(ZZ) sage: h = 4*x sage: h%3 x -cc -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: is_Integer() function semantics
On Fri, Apr 24, 2009 at 10:59 AM, nirmal nrsax...@gmail.com wrote: Thanks for all the helpful suggestions. I did not realize that is_Integer() was deprecated. How could you not notice? If I do is_Integer I get a big DeprecationWarning: sage: is_Integer(3) /Users/wstein/.sage/temp/D_69_91_158_76.dhcp4.washington.edu/15220/_Users_wstein__sage_init_sage_0.py:1: DeprecationWarning: Using is_Integer from the top level is deprecated since it was designed to be used by developers rather than end users. It most likely does not do what you would expect it to do. If you really need to use it, import it from the module that it is defined in. # -*- coding: utf-8 -*- True sage: Does your Sage not do that? William On Apr 22, 2:00 am, John Cremona john.crem...@gmail.com wrote: This is precisely why we deprecated all the is_*() functions for end-user use: -- | Sage Version 3.4.1.rc4, Release Date: 2009-04-19 | | Type notebook() for the GUI, and license() for information. | -- sage: is_Integer(3/2+1/2) /home/masgaj/.sage/temp/host_56_150/29373/_home_masgaj__sage_init_sage_0.py:1: DeprecationWarning: Using is_Integer from the top level is deprecated since it was designed to be used by developers rather than end users. It most likely does not do what you would expect it to do. If you really need to use it, import it from the module that it is defined in. # -*- coding: utf-8 -*- False sage: (3/2+1/2).is_integral() True The is_*() functions just test the type of an abject (in programming terms): sage: type(3/2+1/2) type 'sage.rings.rational.Rational' and the result of 3/2+1/2 is of type Rational. Mathematically, of course, the same number can be an integer and a rational (and a real and a complex and ...). John 2009/4/22 Robert Bradshaw rober...@math.washington.edu: On Apr 21, 2009, at 10:54 PM, Craig Citro wrote: In module sage.rings.integer is_Integer(3/2+1/2) returns False The expected output should be True as 3/2+1/2 = 2. I was planning to use this function to check if the result of division is a whole number. You could also use the is_integral method of rational numbers: sage: n = 3/2 + 1/2 sage: n.is_integral() True (This function also exists on Integers, so you could even use it in situations where you weren't sure if you had an honest Integer or an integer masquerading as a Rational.) Another option is sage: 3/2 + 1/2 in ZZ True sage: 3/2 + 1/3 in ZZ False - Robert -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
On Fri, Apr 24, 2009 at 01:23:25AM -0700, mabshoff wrote: On Apr 24, 1:16 am, John Cremona john.crem...@gmail.com wrote: Hi, This problem has been around for a while. It works ok if you give an absolute pathname. Having said that, I just realised that the testing I have been doing on a clone of 3.4.1 was working fine with a relative pathname. Perhaps it is because Nicolas is working on an upgrade from 3.4.rc0 (as you can see from his path) rather than a fresh 3.4.1? John I remember a discussion about the problem, but did not see any fixes in 3.4.1. If someone knows a ticket and/or even better a patch please let us know so we can get this reviewed and fixed. For information: the patch suggested on #5852 seems to work fine on my machine (macbook pro ubuntu intrepid) Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] load/attach bugs
Hello, I was trying to load some python files and found some weird behaviour of the load/attach commands. I have three test files (a normal file) /home/rado/.sage/test.py (a file with space in the name) /home/rado/.sage/test space.py (a file to take arguments from command line) /home/rado/.sage/ testarg.py In sage prompt: sage: cd /home/rado/.sage sage: load test File 'test' not found ... sage: load test.py Works sage: load test space.py Works (and probably shouldn't so it can enforce quotation marks) sage: load test space.py Works sage: load testarg.py arg1 File 'testarg.py arg1' not found ... attach has the same behaviour, except in the documentation it claims there is a function attached_files(), which also gives an error. sage: attached_files() --- NameError Traceback (most recent call last) /home/rado/.sage/test.py in module() NameError: name 'attached_files' is not defined In sage notebook: load test Works (note that this didn't work in the prompt) load test.py Works load test.py test.py Works Works (note in prompt this command doesn't behave the same) load testarg.py arg1 Error loading /home/rado/.sage/arg1 -- file not found load test space.py runs test Error loading /home/rado/.sage/space.py -- file not found load test space.py runs test Error loading /home/rado/.sage/space.py -- file not found attach test.py attached_files() NameError: name 'attached_files' is not defined -- Hope this shows the inconsistency in the execution of load/attach in prompt and in notebook. What also worries me is that both fail at passing arguments to the scripted called. I feel that that the ipython %run syntax is the best (of course the decision is up to the developers). I found the code for the prompt in ~/sage-3.4/local/lib/python2.5/site- packages/sage/misc/interpreter.py and looked over it. I know enough python to understand the code there, and I can purpose a patch (once its decided how exactly this should work). I don't know where to look for the notebook interpreter code. Rado --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
On Fri, Apr 24, 2009 at 10:06 PM, mabshoff mabsh...@googlemail.com wrote: Gonzalo: Can you please post a proper patch for bugfixes you suggest - I am happt to convert your diff into a proper patch attributed to you, but if you did it would just be easier :) It seems I have some trouble understanding what's a proper patch (b/c I've been observed before on this regard). However, in the case in hand (#5852), there's no hg repo tracking that file, so I fail to see what else you would expect from me... Gonzalo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -t and detection of sage library files
On Apr 24, 6:27 pm, Gonzalo Tornaria torna...@math.utexas.edu wrote: Hi Gonzalo, On Fri, Apr 24, 2009 at 10:06 PM, mabshoff mabsh...@googlemail.com wrote: Gonzalo: Can you please post a proper patch for bugfixes you suggest - I am happt to convert your diff into a proper patch attributed to you, but if you did it would just be easier :) It seems I have some trouble understanding what's a proper patch (b/c I've been observed before on this regard). However, in the case in hand (#5852), there's no hg repo tracking that file, so I fail to see what else you would expect from me... Oops, my bad about the repo. But posting a unified in this particular case would be nice. This is so trivial I can obviously do it locally. Gonzalo Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Fri, Apr 24, 2009 at 1:59 AM, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, Gonzalo Tornaria wrote: would it make sense to have a small sage-source debian package which depends on the (few) build tools required to build debian and which upon installation downloads sage, compiles it, and places it in a (debian specific) standard place in the system? Alternatively, the package actually comes with the full source code (better for places with apt caches or debian mirrors). I recall once upon a time there was a (similar idea) debian package for netscape, which would actually download it from netscape website and install it. I think the reason Netscape was done that way is actually because it wasn't free software, and so Debian wasn't willing to distribute it directly. In fact, Google suggests the Netscape package was just a script that downloaded the binaries from the website and then installed them. Yes, that's correct. It was just a script --- the script was indeed free, so IIRC the package lived in contrib (as a free package which depends on a non-free/out of debian package). I think it would be hard to avoid violating Debian policy with such a package, and even if it did not, I suspect the Debian community would frown on such an arrangement for a piece of software in the main (free software) section of the archive. I'd assume such a package would enter debian in the contrib section (if at all). I fail to see a reason for it to go to non-free. Still, a package in contrib which downloads and compiles sage would be definitely better than no package, and in some cases even better than an outdated package. Disclaimer: I've been using debian for a lng time, and I only track the main section --- so such a package wouldn't reach me if it lives in contrib --- but (a) I still think it'd be useful for some people (b) I'd frown on such a package being in the main section of debian. Gonzalo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: load/attach bugs
On Apr 24, 6:24 pm, Rado rki...@gmail.com wrote: Hello, Hi Rado, I was trying to load some python files and found some weird behaviour of the load/attach commands. I have three test files (a normal file) /home/rado/.sage/test.py (a file with space in the name) /home/rado/.sage/test space.py (a file to take arguments from command line) /home/rado/.sage/ testarg.py In sage prompt: sage: cd /home/rado/.sage sage: load test File 'test' not found ... sage: load test.py Works sage: load test space.py Works (and probably shouldn't so it can enforce quotation marks) No, this was explicitly fixed since it was requested by users. I think if you add spaces to file names you have it coming, but I think it was worth fixing it. sage: load test space.py Works sage: load testarg.py arg1 File 'testarg.py arg1' not found ... Why would that even work? The attach doctstring says: USAGE: ``attach file1 file2 ...`` - space-separated list of .py, .spyx, and .sage files. So arg1 is not going to get passed as an argument. The error message should probably be specific and tell you that arg1 cannot be found. I am also not sure of the fix that allowed spaces in filenames does not break the attach command for multiple files. SNIP Hope this shows the inconsistency in the execution of load/attach in prompt and in notebook. What also worries me is that both fail at passing arguments to the scripted called. I feel that that the ipython %run syntax is the best (of course the decision is up to the developers). I found the code for the prompt in ~/sage-3.4/local/lib/python2.5/site- packages/sage/misc/interpreter.py and looked over it. I know enough python to understand the code there, and I can purpose a patch (once its decided how exactly this should work). The code you want to edit is in $SAGE_ROOT/devel/sage/sage. Once you have done changes you need to exit Sage, run sage -b and restart Sage to have the changes go live. (you can also run ./sage -br to build any changes and then start Sage). The files in devel/sage are in a mercurial repo, if you need some more pointers here let us know. I don't know where to look for the notebook interpreter code. I have no clue, but I would expect it to use the same code as the Sage command line interface. Rado Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: load/attach bugs
(a file to take arguments from command line) /home/rado/.sage/ testarg.py This is not what load/attach were intended for (and why do you expect it to work?), but it's not a terrible idea. Certainly attach should never support passing arguments, that's just perverse. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: load/attach bugs
I think I worded myself badly in the previous post. I see now that its a design decision to use this syntax USAGE: ``attach file1 file2 ...`` - space-separated list of .py, .spyx, and .sage files. instead of ``attach file1 arguments`` (this is the ipython syntax). You are right obviously, only one of those can work, so forget about the argument passing. Here is a more concise version of the problems I see (unless i am doing something wrong): 1)``load home/rado/.sage/test space.py `` doesn't work in a notebook, works in prompt 2)``load test1.py test2.py`` doesn't work in prompt, works in notebook I can fix 2) at $SAGE_ROOT/devel/sage/sage/misc/interpreter.py but actually I need a fix for 1) since I keep my files with folders with spaces. Since prompt works with files with spaces, it shouldn't be too hard to make the notebook work with those too, right?!? I will keep digging around to find which file causes 1). Rado On Apr 24, 8:48 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 6:24 pm, Rado rki...@gmail.com wrote: Hello, Hi Rado, I was trying to load some python files and found some weird behaviour of the load/attach commands. I have three test files (a normal file) /home/rado/.sage/test.py (a file with space in the name) /home/rado/.sage/test space.py (a file to take arguments from command line) /home/rado/.sage/ testarg.py In sage prompt: sage: cd /home/rado/.sage sage: load test File 'test' not found ... sage: load test.py Works sage: load test space.py Works (and probably shouldn't so it can enforce quotation marks) No, this was explicitly fixed since it was requested by users. I think if you add spaces to file names you have it coming, but I think it was worth fixing it. sage: load test space.py Works sage: load testarg.py arg1 File 'testarg.py arg1' not found ... Why would that even work? The attach doctstring says: USAGE: ``attach file1 file2 ...`` - space-separated list of .py, .spyx, and .sage files. So arg1 is not going to get passed as an argument. The error message should probably be specific and tell you that arg1 cannot be found. I am also not sure of the fix that allowed spaces in filenames does not break the attach command for multiple files. SNIP Hope this shows the inconsistency in the execution of load/attach in prompt and in notebook. What also worries me is that both fail at passing arguments to the scripted called. I feel that that the ipython %run syntax is the best (of course the decision is up to the developers). I found the code for the prompt in ~/sage-3.4/local/lib/python2.5/site- packages/sage/misc/interpreter.py and looked over it. I know enough python to understand the code there, and I can purpose a patch (once its decided how exactly this should work). The code you want to edit is in $SAGE_ROOT/devel/sage/sage. Once you have done changes you need to exit Sage, run sage -b and restart Sage to have the changes go live. (you can also run ./sage -br to build any changes and then start Sage). The files in devel/sage are in a mercurial repo, if you need some more pointers here let us know. I don't know where to look for the notebook interpreter code. I have no clue, but I would expect it to use the same code as the Sage command line interface. Rado Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: load/attach bugs
I can fix 2) at $SAGE_ROOT/devel/sage/sage/misc/interpreter.py but actually I need a fix for 1) since I keep my files with folders with spaces. Since prompt works with files with spaces, it shouldn't be too hard to make the notebook work with those too, right?!? Curiously the notebook handles this completely independently of the prompt. (This is obnoxious but has a long history and is unlikely to change right now.) Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: is_Integer() function semantics
Another option is sage: 3/2 + 1/2 in ZZ True sage: 3/2 + 1/3 in ZZ False I just ran into the True in ZZ returns True thing again. How do I check to see if I passed an option or True? Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: is_Integer() function semantics
On Apr 24, 2009, at 8:24 PM, Nick Alexander wrote: Another option is sage: 3/2 + 1/2 in ZZ True sage: 3/2 + 1/3 in ZZ False I just ran into the True in ZZ returns True thing again. How do I check to see if I passed an option or True? You can do x is True - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: load/attach bugs
Alright I got how to make ``load test space.py`` work for the notebook too. The problem is in: /home/rado/sage-3.4/devel/sage/sage/server/notebook/worksheet.py line 3558: for filename in L.split(): the python split function splits test space.py to 'test' and 'space.py'. I googled for a bit and found here http://stackoverflow.com/questions/79968/split-a-string-by-spaces-preserving-quoted-substrings-in-python that there is part of the python standard library for splitting shell. The fix is simple, just use import shlex for filename in shlex.split(L): I tried it at it works. I am completely new to software development, so don't know how to submit a patch (if this is patch-worthy). But at least now it is on the forum so stubborn people with spaces in their folder names can google this fix:) Rado On Apr 24, 10:23 pm, Nick Alexander ncalexan...@gmail.com wrote: I can fix 2) at $SAGE_ROOT/devel/sage/sage/misc/interpreter.py but actually I need a fix for 1) since I keep my files with folders with spaces. Since prompt works with files with spaces, it shouldn't be too hard to make the notebook work with those too, right?!? Curiously the notebook handles this completely independently of the prompt. (This is obnoxious but has a long history and is unlikely to change right now.) Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
