[sage-devel] Re: tabs in Sage library souces - #5653 and #5848
There's a positive review up for #5848, but clearly I wasn't fast enough. ;-) #5653 causes tab-completion in the notebook to display the docstring or source code formatted very nicely using HTML, just as it looks in the reference manual. Lots of color and syntax highlighting, and TeX rendered properly. Its worth experimenting with just to get a sneak preview. But it could also use a referee who knows the notebook and the documentation system. Hint, hint. Rob --~--~-~--~~~---~--~~ 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: GMP 4.3.0
On 22 Apr, 01:57, David Harvey dmhar...@cims.nyu.edu wrote: And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? The same argument applied to FLINT and zn_poly leads to curious conclusions. So which are you arguing MPIR should do. 1) Try and reuse as much code out there that is already written, i.e. port other people's code to the MPIR code base (which you complained about). 2) Do all the work from scratch and come up with our own new algorithms to improve the same functionality. You can't have this both ways. With regard to 1, we have so far reused: * Moller's GCD patches * Originally we used Jason Martin's and Pierrick Gaudry's patches (admittedly we found better code since then) * Some assembly code of a Japanese hacker * Bodrato and Zimmermann's Toom code (at least the LGPL components of this work) * Brian's MSVC port of GMP * Numerous patches available online for various build issues on various platforms We intend to use: * Paul Zimmermann's FFT code * More of Bodrato's LGPL Toom code With regard to 2 we have: * Written our own Toom sequence generator * Written our own assembly optimiser * Come up with a number of new innovations at the assembly level especially with regard to division by constants and combining functions together to push more bits through the CPU * Found an interesting way of tuning the asymptotically fast GCD code With regard to matching GMP feature for feature we need to: * Improve speed of assembly language code on systems other than K8 * Write a new optimised mul_basecase for K8 based on the optimal addmul_2 code we included in MPIR 1.1.0 - currently it is not used at all * Speed up the FFT * Add square and unbalanced Toom variants * Implement faster division by 1 and 2 limbs * Asymptotically fast XGCD * Asymptotically fast division * Optimise Toom 4 code Now, given that code for some of the above has been available for *years* under the GPL or LGPL v2+ and now appears in GMP 4.3.0 then I am sure you'll allow that it is not unreasonable to allow 6 months for us to catch up in all these areas. But tell me, would you rather have us: 1) Do all this stuff completely from scratch coming up with new algorithms for all the above 2) Port everyone's code that we can't use by rewriting it and make use of the new algorithms exposed in GMP, e.g. Montgomery's algorithm for division by 1 limb 3) Issue a GPL v3+ version of MPIR which just includes the various bits of GMP that do the above You seem to be after a 4th option 4) Go away and stop developing MPIR. Sorry, that is not going to happen, ever!! So which is it going to be? And are you going to help? Bill. --~--~-~--~~~---~--~~ 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: tabs in Sage library souces - #5653 and #5848
On Apr 21, 11:15 pm, Rob Beezer goo...@beezer.cotse.net wrote: There's a positive review up for #5848, but clearly I wasn't fast enough. ;-) Yeah, after talking about it with some people in IRC it seems that there wasn't any strong consensus. And John Palmieri had pointed out that he can easily rebase the patch, so my current plan for this path to get it into 3.4.2.final once we get closer. That way trac should be more or less empty of mergable patches and everybody should be happy. #5653 causes tab-completion in the notebook to display the docstring or source code formatted very nicely using HTML, just as it looks in the reference manual. Lots of color and syntax highlighting, and TeX rendered properly. Its worth experimenting with just to get a sneak preview. Yeah, that patch absolutely rocks and it is hard to understand why it is so great unless you play with it. One suggested improvement was to add some mechanism you could tear off or pop out a help page just like Google chat for example. But it could also use a referee who knows the notebook and the documentation system. Hint, hint. :) Rob 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: GMP 4.3.0
On 22 Apr, 01:58, David Harvey dmhar...@cims.nyu.edu wrote: I am talking about the mpn-level interface, which is relevant for a lot of the things I work on. If it helps, we have made a commitment to implementing the full public GMP interface in MPIR, including the mpn level. As GMP developers now have an open repo it should be trivial for us to see what the public interface is going to be ahead of GMP releases, no? BTW, I applaud the fact that GMP development is now more open in this regard. I see something good has come of all this already. Bill. --~--~-~--~~~---~--~~ 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: GMP 4.3.0
On 22 Apr, 02:02, David Harvey dmhar...@cims.nyu.edu wrote: Can someone show me a benchmark where MPIR is faster than GMP? I tried a few basic things and couldn't find any. Someone who knows the MPIR codebase better than me should be able to find something. Are you aware that our MPIRbench score on K8 is higher than GMP's? Our rsa bench is way ahead. We have *only* optimised for K8 at present and even there we still have quite a bit to do. Jason Moxham is now into about the 4th version of his assembly optimiser and from what I can tell, it is far more capable than the one you guys wrote. We'll soon have optimised code sequences for far more CPU's than GMP even currently distinguishes. In the Toom 7 region, MPIR is significantly ahead of GMP. Our GCD code is better tuned than GMP's. Other improvements pending, it should eventually be faster than GMP's. Our code base runs natively on some systems that it doesn't even run on GMP. That's an infinite improvement. But really, I'm a little annoyed that you try to lay this kind of pressure on us. You know GMP has had much fast code available for years. We finished sorting out build issues at MPIR 0.9.0 which was release on 10th January. So we have done all of the rest of the work on speeding things up in 3 months. How much did GMP get done in that same 3 months? How long has it taken to write all the GMP code to do all these nice new things it does? Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill. --~--~-~--~~~---~--~~ 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: GMP 4.3.0
Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill, David, We're all friends here. Let's not let this escalate. 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 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] Blank Jmol in live doc issue
This is about http://trac.sagemath.org/sage_trac/ticket/3167
If I open a new worksheet and execute
x,y=var('x,y')
plot3d(sin(x*y),(x,-4,4),(y,-4,4))
I see this in Opera's Java Console:
Jmol applet jmolApplet1__319875117923755__ destroyed
Jmol applet jmolApplet2__319875117923755__ initializing
AppletRegistry.checkIn(jmolApplet2__319875117923755__)
applet context: -applet
appletDocumentBase=http://localhost:8000/home/admin/11/
appletCodeBase=http://localhost:8000/java/jmol/
(C) 2008 Jmol Development
Jmol Version 11.6.16 2008-11-24 13:39
java.vendor:Sun Microsystems Inc.
java.version:1.6.0_13
os.name:Linux
memory:13.2/55.1
useCommandThread: false
appletId:jmolApplet2__319875117923755__
FileManager opening http://localhost:8000/java/jmol/appletweb/SageMenu.mnu
urlImage=jar:http://localhost:8000/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif
defaults = Jmol
backgroundColor = black
language=en_US
FileManager opening
http://localhost:8000/home/admin/11/cells/17/sage0-size500.jmol?1240378461
FileManager opening
http://localhost:8000/home/admin/11/sage0-size500-481666882.jmol.zip
FileManager.openStringInline()
The Resolver thinks Xyz
ModelSet: haveSymmetry:false haveUnitcells:false haveFractionalCoord:false
1 model in this collection. Use getProperty modelInfo or getProperty
auxiliaryInfo to inspect them.
ModelSet: autobonding; use autobond=false to not generate bonds
automatically
data model list
10
empty
Xx -6.0 -7.0 -3.0
Xx 0.0 -7.0 -3.0
Xx 6.0 -7.0 -3.0
Xx 7.0 -6.0 -3.0
Xx 7.0 0.0 -3.0
Xx 7.0 6.0 -3.0
Xx -7.0 -6.0 -3.0
Xx -7.0 -6.0 0.0
Xx -7.0 -6.0 3.0
Xx 5.5 5.5 5.5
end model list;
FileManager opening
http://localhost:8000/home/admin/11/sage0-size500-481666882.jmol.zip
reading pmesh data from
http://localhost:8000/home/admin/11/sage0-size500-481666882.jmol.zip|obj_832199.pmesh
If I do the same in a docbrowser sheet, I see
Jmol applet jmolApplet0__307075267903545__ initializing
urlImage=jar:http://localhost:8000/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif
AppletRegistry.checkIn(jmolApplet0__307075267903545__)
applet context: -applet
appletDocumentBase=http://localhost:8000/doc/live/tutorial/tour_plotting.html
appletCodeBase=http://localhost:8000/java/jmol/
(C) 2008 Jmol Development
Jmol Version 11.6.16 2008-11-24 13:39
java.vendor:Sun Microsystems Inc.
java.version:1.6.0_13
os.name:Linux
memory:14.2/58.9
useCommandThread: false
appletId:jmolApplet0__307075267903545__
FileManager opening http://localhost:8000/java/jmol/appletweb/SageMenu.mnu
defaults = Jmol
backgroundColor = black
language=en_US
FileManager opening
http://localhost:8000/home/_sage_/85/cells/33/sage0-size500.jmol?1240378560
FileManager opening
http://localhost:8000/doc/live/tutorial/sage0-size500-224802342.jmol.zip
script ERROR: io error reading
http://localhost:8000/doc/live/tutorial/sage0-size500-224802342.jmol.zip|SCRIPT:
java.io.FileNotFoundException:
http://localhost:8000/doc/live/tutorial/sage0-size500-224802342.jmol.zip
eval ERROR:
line 2 command 2 of file
/home/_sage_/85/cells/33/sage0-size500.jmol?1240378560:
script SCRIPT
line 1 command 1:
script
/home/_sage_/85/cells/33/sage0-size500.jmol?1240378560
which explains the blank applet (i.e., no plot). Apparently, the
notebook finds and serves up the zip file when it's requested relative
to the base URL of an ordinary worksheet, but it does not do the same
for a live doc worksheet.
Though I have not yet tried it, one fix that springs to mind is to
encode the full URL of the archive in plot.plot3d.base.show(). But this
seems to be a server (permissions?) issue. Once again, I'm in over my
head, so it would be great to get some input.
The logs above are from Sun's 64-bit JDK in Opera 9 on Fedora 9. I
don't know how to access the Java console in Firefox, but I've
experienced the same behavior in both the 32-bit and 64-bit versions.
--~--~-~--~~~---~--~~
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: tabs in Sage library souces - #5653 and #5848
In my experience (using emacs which puts tabs in) there has never been a problem in .py files, but .pyx files would fail to build unless I use the emacs untabify command before rebuilding a file I have edited. John 2009/4/22 mabshoff mabsh...@googlemail.com: Hello folks, up to now the rules on tabs in Sage library sources has been don't use them, but there was never any enforcement and/or systematic detection since no side effect of using tabs has even been detected. As it turns out #5653 exposes a case where tabs cause problems when rendering docstrings in a pretty way in the notebook. At #5848 John Palmieri posted a patch converting all tabs in the Sage library to spaces. This kind of patch is likely to break some patches that used to work and it is generally not too nice to do white space only patches for exactly that reason. But this case is somewhat special since it will allow #5653 to work better and once you have seen that patch in action in the notebook you will likely agree that a little short term pain is well worth the potential rebasing problem. If this goes into 3.4.1.final it needs to be done soon, i.e. less than two hours. John is happy to rebase the patch at #5848, so it could be the last patch to go into 3.4.2, too, for example. 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: is_Integer() function semantics
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: GMP 4.3.0
I apologise if this seemed rude. I should have made the point more subtly. I'm just trying to deal with it in an open way. David has taken clear exception to the use of MPIR in Sage by default, and some of his points are valid for the time being. But I want to be clear that MPIR is not going away and that if David's intention is to try and stamp out MPIR now while it is still not completely clear what advantages it will ultimately provide, his efforts will be wasted. I would save him that effort, especially given that the window of opportunity to do this is actually quite small. It was fully expected that GMP would temporarily have the jump on MPIR in a number of significant areas. Fully expected, and there were few surprises. The fact that they virtually threw everything they had at us, whether polished or not, was a surprise. One clear advantage of MPIR. It runs natively on Windows. Obviously that matters a lot to Sage. When and if GMP is prepared to deal with this, then David has the chance of making a case. Until then, there is no case. To take any other attitude is ignoring the elephant in the room. Virtually every contributor to MPIR has tried to get improvements accepted into GMP and failed. David Harvey managed it, but at the cost of signing over his copyright, having an organisation not directly involved in the project decide the license and having his code become so inextricably intertwined with that of TG's that he could not contribute it to both MPIR and GMP as he initially intended. Further, the GMP maintainer's attitude to native support for Windows is a matter of public record. The mandate for the MPIR fork of GMP is as strong as ever. It won't be going away, and I would save David from wasting his effort on trying to make it go away. I don't have any objections to making a GMP spkg, except the obvious. It is fundamentally wasted effort in comparison with just helping us improve MPIR. That said, if David wishes to provide support for GMP for Sage users, so long as he is prepared to do that work and not just expect someone else to do it, then +1 from me. It isn't my intention to alienate David, and never has been. Instead, I wish to prompt him to realise that Sage can gain a lot from the success of MPIR, both financially, in terms of platform support and ultimately I believe in terms of ultimate performance goals. I don't wish to appear to presume anything, but it is also my strong opinion that MPIR is a much more faithful representation of the Sage way of doing things than GMP is. If it isn't, help us to make it so by contributing. We currently have five people committed to making significant code improvements over the next year or so and the help of Mariah Lennox, Michael Abshoff, Jeff Gilchrist and from time to time, various others in relation to build and testing issues. We also have the prospect of some really significant funding for MPIR in the not too distant future and have been provided with significant resources for build testing of our code on hardware. But the project is not currently suffering from being over bloated. We can handle more contributors and look forward to them signing on. The more people that contribute, the quicker we will realise our goals. We already provide significant advantages over GMP in some areas and there is plenty more of that to come. People too easily forget that just one week ago, the tables were completely reversed. MPIR was *significantly* faster than GMP and still had all the other advantages over GMP such as native Windows support. All of a sudden, after two years, GMP does a release, and almost overnight David Harvey thinks it is reasonable to suggest that MPIR should be abandoned in favour of GMP. Come on, be reasonable! Bill. On 22 Apr, 07:58, Nick Alexander ncalexan...@gmail.com wrote: Seriously, it looks for all the world to me that you are intentionally trying to kick MPIR while it is down, knowing full well that a comparison is unfair at this point. I expect that by October/November this year we will match GMP feature for feature, and that will be regardless of whether another release is made. On top of that we'll have a whole load of new stuff GMP doesn't have. I promise you, we have some really, really nice stuff on the way, e.g. parallel code is one of the main new focuses, and development of that will start in about 4 weeks. Will you support us in October/November when there is a clear reason to do so? In the mean time, how about letting us get on with our work. Better still, how about contributing your improvements to *both* projects. Bill, David, We're all friends here. Let's not let this escalate. 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
[sage-devel] Re: worksheet question: what does Save quit do? What does Discard quit do?
On Mon, Apr 13, 2009 at 7:26 PM, Nick Alexander ncalexan...@gmail.com wrote: On 13-Apr-09, at 4:17 PM, David Joyner wrote: I don't know if this comment is relevant or not to this thread or not but I use the Discardquit button *very* frequently. I tell my students to log into the local Sage server, do the homework, and share it with me. They often leave the process going (I guess they just kill their browser?), so I open each one that is still running and hit the Dq button. I probably do that about 30-50 times each time a class assignment is due. It seems useful to me to have a command that quits the processes started by the worksheet and makes no other changes. Even less relevant: can't you select all those worksheets in the main screen and action - quit them? This doesn't make any sense for me. I see on the page which lists the worksheets (running or not) no action button. There is however a stop button. I guess you mean, select them then hit stop. 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: worksheet question: what does Save quit do? What does Discard quit do?
On Tue, Apr 14, 2009 at 1:12 AM, William Stein wst...@gmail.com wrote: On Mon, Apr 13, 2009 at 4:47 PM, David Joyner wdjoy...@gmail.com wrote: On Mon, Apr 13, 2009 at 7:26 PM, Nick Alexander ncalexan...@gmail.com wrote: On 13-Apr-09, at 4:17 PM, David Joyner wrote: I don't know if this comment is relevant or not to this thread or not but I use the Discardquit button *very* frequently. I tell my students to log into the local Sage server, do the homework, and share it with me. They often leave the process going (I guess they just kill their browser?), so I open each one that is still running and hit the Dq button. I probably do that about 30-50 times each time a class assignment is due. It seems useful to me to have a command that quits the processes started by the worksheet and makes no other changes. Even less relevant: can't you select all those worksheets in the main screen and action - quit them? I didn't think of that. Would action-quit also quit me from the notebook? No, as you'll see when you try it. You mean stop not action-quit i guess. --~--~-~--~~~---~--~~ 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: GMP 4.3.0
Hi all, On 22 Apr., 06:45, William Stein wst...@gmail.com wrote: 2009/4/21 David Harvey dmhar...@cims.nyu.edu: On Apr 21, 2:31 pm, Bill Hart goodwillh...@googlemail.com wrote: In some cases it would be less work to just contribute features directly to MPIR to bring the current code up to par. I think you are underestimating how much work it is to design, write and debug these things. And whatever happened to not reinventing the wheel? I suppose that's a Sage motto but not an MPIR one? david The phrase is Building the car instead of reinventing the wheel. This was a description that an Italian Sage user used to describe the Sage project in its early days, when the only developers were me, David Joyner, and David Kohel. To me, the emphasis is on building the car, i.e., creating a viable alternative to the Ma*'s, instead of an emphasis on reinventing the wheel. Successful car manufacturers such as BMW, Toyota, etc., do not just take a bunch of off-the-shelf components and assemble a car. They innovate by creating better engines, carefully refining manufacturing processes, and constantly rethinking everything from external airflow to cupholder ergonomics. Also some doctests related to modular symbols. I don't know enough about this area to tell whether it's xgcd related or whether it's really a new bug in GMP. Those are all caused by xgcd returning a different choice of valid answer. The xgcd choice impacts the (highly noncanonical) choice of homology class representatives for modular symbols. I have on my to-do-list for a long time now the task to introduce canonical choices for e.g. P1List and for bases of modular symbol spaces. It would help a lot when interfacing with C libraries that do certain calculations very fast, e.g. the set of Heilbronn matrices for massive p Hecke operators. And there still seem to be certain 32bit versus 64bit issues open due to the use of hash() (e.g. for composite levels). So these specific differences can be hoped for to vanish sooner or later. This leaves the issue of checking that gmp works -- and in particular, the doctests getting different results with gmp vs. mpir. I don't think the doctesting issue is an insurmountable hurdle -- we already have a system set up to change doctests on 32 vs. 64 bit systems; it would take a little doing, but I don't see why we couldn't set something up to have # gmp and # mpir for certain results. It seems like both the gmp and mpir devs would get some use out of this -- both would be able to check that they return consistent results across all of the doctests in sage that use their code, which is a good thing. Plus, one would have a list of known places where gmp and mpir have different behavior -- again, good for both camps. (Especially when end-users switching from gmp to mpir or vice-versa get different results with their code, for instance.) Seems like a very complex solution for very little benefit. I do not think the above would be too difficult. I implemented a tagged optional doctesting system, which is already in Sage, which would _almost_ make doing the above reasonably easy. In particular, we would extend the system so the following works: sage: line of input output output gmp gives # optional - gmp If one does sage -t -optional=gmp devel/sage/sage then the sage test suite would be run, but the output in tests that have # optional-gmp would expect that output. This would be easy to implement. It would be useful in other contexts as well, e.g., having Macaulay2 installed changes some doctest output in some cases, which is annoying, but which this system would fix. Doing make check may set some optional flags per default, e.g., after checking whether M2, gmp, etc. are installed. Who is going to go to the trouble of implementing and maintaining this? You, of course. :-) Though I would add the above extension to sage -t, since that would be fairly easy for me to do. Cool. Where's the patch to review? Honestly, I believe that such an extension is an enhancement of the Sage doctesting system/environment being of some importance, independently of the GMP versus MPIR topic discussed here. Concerning the latter, IMHO the Gnome project wouldn't nearly be where and what it is without the KDE project. And today, both projects profit from each other's existence. Cheers, gsw -- 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: GMP 4.3.0
2009/4/22 Georg S. Weber georgswe...@googlemail.com: I have on my to-do-list for a long time now the task to introduce canonical choices for e.g. P1List and for bases of modular symbol spaces. It would help a lot when interfacing with C libraries that do certain calculations very fast, e.g. the set of Heilbronn matrices for massive p Hecke operators. And there still seem to be certain 32bit versus 64bit issues open due to the use of hash() (e.g. for composite levels). This (canonical choices for P1List) is something which interests me greatly, and I would be interested in continuing that discussion, but not in this thread (perhaps on sage-nt?) John Cheers, gsw -- 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: GMP 4.3.0
Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. I sincerely believe the costs of the fork to the community outweigh the benefits. Probably no-one will believe me, but this whole kerfuffle started as a result of me trying some shuttle diplomacy to get the two projects talking. The personal animosities involved are quite astonishing. Hopefully my planned career as a mathematician will be more successful than my career as a diplomat. Anyway, forget it. Good luck with MPIR guys. 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: GMP 4.3.0
2009/4/22 David Harvey dmhar...@cims.nyu.edu: Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. Of course you are not unwelcome on this list! John 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: GMP 4.3.0
On Wed, Apr 22, 2009 at 6:22 AM, David Harvey dmhar...@cims.nyu.edu wrote: Oh look, I've been involved in Sage since mid-2006. This is the first major strategic decision with which I've disagreed so strongly, and the first time I've felt truly unwelcome on this list. It's quite depressing. I sincerely believe the costs of the fork to the community outweigh the benefits. Probably no-one will believe me, but this whole kerfuffle started as a result of me trying some shuttle diplomacy to get the two projects talking. The personal animosities involved are quite astonishing. Hopefully my planned career as a mathematician will be more successful than my career as a diplomat. Anyway, forget it. Good luck with MPIR guys. david You are certainly not unwelcome! 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] feature request
Hi, is it too late to include the multiprocessing package into sage 3.4.1? There is a backport of it for python 2.5 in Pypi, which is maintained by the author of the one which figures in the standard library from 2.6 on. thanks, Flávio --~--~-~--~~~---~--~~ 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: GMP 4.3.0
On Tue, Apr 21, 2009 at 9:38 AM, dmharvey dmhar...@cims.nyu.edu wrote: Hi folks, I have made a basic spkg for GMP 4.3.0: http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg I've only tested on a linux opteron system. It builds fine; there are various doctest failures that look related to non-canonical XGCD output. Quite possibly it won't yet even build on other sage-supported systems. Just one quick warning: If you try this on sage.math.washington.edu, it will appear to be substantially slower than the mpir included in vanilla sage-3.4.1, due to a bug in the GMP configuration script, which misdetect sage.math's Dunnington Xeon processors as Atom N270's (i.e., a netbook). Correctly configured, GMP is quite fast on sage.math. 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: feature request
On Wed, Apr 22, 2009 at 6:10 AM, Flavio Coelho fccoe...@gmail.com wrote: Hi, is it too late to include the multiprocessing package into sage 3.4.1? No, since we included it in Sage a year ago: teragon:~ wstein$ sage -- | Sage Version 3.4.1, Release Date: 2009-04-21 | | Type notebook() for the GUI, and license() for information.| -- sage:import processing sage: There is a backport of it for python 2.5 in Pypi, which is maintained by the author of the one which figures in the standard library from 2.6 on. thanks, Flávio -- 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: Interesting google summer of code apps
On Mon, Apr 20, 2009 at 8:15 PM, Jason Grout jason-s...@creativetrax.com wrote: In addition to the python summer of code projects, here are some other projects that may be interesting to Sage developers: * Scilab applications, including one that replaces maxima with a ginac-based symbolic system, another that explores moving algorithms to CUDA, etc. See http://socghop.appspot.com/org/home/google/gsoc2009/scilab * Several sympy projects: http://socghop.appspot.com/org/home/google/gsoc2009/portland_state All sympy projects are summarized here: http://code.google.com/p/sympy/wiki/GSoC2009 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: Indefinite Integration [WAS: programming: define a new function]
On Tue, Apr 21, 2009 at 12:44 AM, mabshoff mabsh...@googlemail.com wrote: On Apr 21, 12:32 am, Robert Bradshaw rober...@math.washington.edu wrote: On Apr 20, 2009, at 11:44 PM, Maurizio wrote: Hi Michael, Actually, I thought that this discussion (especially people much more expert than me) has clarified the point that implementing integrals is not really just matter of a couple of months... but I would be glad to see this happen! Implementing something that can handle a huge number of integrals is a reasonable goal for a couple of months. Implementing something that can handle everything that we know how to handle in theory...well, that hasn't ever happened yet. Yep, certainly implementation are certainly better than other implementation here on average, but one could claim that neither Sympy nor Maxima are at the head of the class. Maxima can do many things, but often a little massaging is required by the user to get optimum results comparable to MMA for example. And I believe plainly and simply that this is not the role of the user of a CAS to be an exper at term maniplulation. If I write intgerate($FOO) I expect to get a correct answer without being required to transform the expression due to knowledge one has about the underlying implementation. I believe that too. I know there are some license issues with SymPy (not really issues, just differences probably) but I think there's no problem in taking inspiration and some pieces of code from it, right? There is a problem with just lifting code--but we can and do ship SymPy as part of Sage. Yes. One could take code from Sympy (the BSD license allows this) and make GPL ed changes on top of it. The main issue is just that our pattern matching engine via pynac will be more powerful, our Could you give some specific examples where the pynac pattern engine is more powerful? arithmetic is faster and the other abstract math bits in Sage are way more powerful than what is in Sympy. And the goal of Sympy is to be self contained and depending on certain operations in Sage is not an option and not wanted, so contributing such code back to Sympy is not We want sympy to run without Sage. But I have absolutely no problems calling Sage for certain things if it's available. In fact, I do want to call Sage if it's available. an option . There is the goal for Sympy to optionally depend on Pynac and use it when available, but no one is working on this, so this is not something we ought to be waiting for. Plainly and simply: Waiting on someone else to fix the problem for us has not worked, so we will do it ourselves. For the record, I offered William and you that I will work on this, if we manage to find funding for it over the summer. So just to be clear that I am very interested in this, and not just talking. But unfortunately I myself didn't find funding for it (and I haven't heard from you either that you found some possibility), so I had to find an internship somewhere else related more to my research (finite elements). We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. I'm saying this, because I can see this new symbolic stuff exciting, but without the right amount of interest on it, its development will always be a little slow Given that we ship SymPy, so anything it can handle we should be able to handle. I imagine when you want to integrate something, it will try to do it natively first, and that failing ask SymPy and/or maxima before returning a failure. Over time we'll depend less and less on the other two. Yep, that is the only way in my opinion. We control the Sage library and can coordinate releases with improvements in the Sage library - Sympy has not released as frequently as it used to be and unless someone steps up and helps Ondrej out I doubt that is going to change any time soon. We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) Besides, it will take almost a year to Sage too to release the new symbolics (started August 2008), so I don't think we are doing that bad. Also in terms of developers working just on symbolics, I think sympy has much more developers. I don't know if it's easy to extract just patches to Sage symbolics, to compare speeds of developments, but I would not be surprised if it turns out it's actually very comparable, or even less people are working on Sage symbolics than on sympy. That being said, I like that you pursue the pynac way, because first I also wanted to use ginac but using swig was just not the way, so William showed me with cython how to actually do it. And second, I welcome competition, because that's the only way to actually move forward, but for Sage and sympy. For example thanks to sympy, you completely abandoned your previous approach for symbolics, because after many months of
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Wed, Apr 22, 2009 at 9:08 AM, Ondrej Certik ond...@certik.cz wrote: welcome competition, because that's the only way to actually move forward, but for Sage and sympy. For example thanks to sympy, you but - both O. --~--~-~--~~~---~--~~ 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: feature request
On Apr 22, 8:09 am, William Stein wst...@gmail.com wrote: On Wed, Apr 22, 2009 at 6:10 AM, Flavio Coelho fccoe...@gmail.com wrote: Hi, is it too late to include the multiprocessing package into sage 3.4.1? No, since we included it in Sage a year ago: While we ship pyprocessing we should really consider upgrading to multiprocessing since once we update to Python 2.6 we can just drop the spkg and it contains fixes not in pyprocessing, i.e. I could never get pyprocessing to work on FreeBSD. teragon:~ wstein$ sage -- | Sage Version 3.4.1, Release Date: 2009-04-21 | | Type notebook() for the GUI, and license() for information. | -- sage:import processing sage: There is a backport of it for python 2.5 in Pypi, which is maintained by the author of the one which figures in the standard library from 2.6 on. thanks, Flávio 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] 3.4.1 release tour updates
Hi folks, it would be good if you contributed a feature to Sage 3.4.1 to check the release tour at http://wiki.sagemath.org/sage-3.4.1 and edit what is there already in case it can be improved or add something in case it is missing. Minh: You seem to list both author[s] and reviewer[s] for credit, but it seems better to either only list the author or make clear who author [s] and reviewer[s] were. I see that Martin Albrecht already changed that for one ticket and I think he is correct. 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: trac ticket width and hgrc tips?
On Tue, Apr 21, 2009 at 8:44 PM, Pat LeSmithe qed...@gmail.com wrote: Besides username, and [diff] git = true for binary patches, are there other useful bits I should put in ~/.hgrc? I have these bits to turn on Mercurial queues (not enabled by default in Debian) and colordiff (install on Debian/Ubuntu with sudo apt-get install colordiff): [extensions] hgext.churn= extdiff = hgk= hgext.mq= [extdiff] cmd.cdiff = colordiff opts.cdiff = -uprN [defaults] # suppress noisy extdiff header message cdiff = -q -- Carlo Hamalainen http://carlo-hamalainen.net --~--~-~--~~~---~--~~ 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 21, 11:44 am, Pat LeSmithe qed...@gmail.com wrote:
Hi Pat,
Sage trac's stylesheet sets the width of a ticket's description, change
history, etc., to 700 pixels:
http://trac.sagemath.org/sage_trac/chrome/common/css/ticket.css
contains
#content.ticket { width: 700px; max-width: 100% }
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?
in
~/.mozilla/firefox/secret code.profile name/chrome/userContent.css
Note: I haven't tested this with other trac sites.
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: Interesting google summer of code apps
On Apr 22, 2009, at 8:38 AM, Ondrej Certik wrote: On Mon, Apr 20, 2009 at 8:15 PM, Jason Grout jason-s...@creativetrax.com wrote: In addition to the python summer of code projects, here are some other projects that may be interesting to Sage developers: * Scilab applications, including one that replaces maxima with a ginac-based symbolic system, another that explores moving algorithms to CUDA, etc. See http://socghop.appspot.com/org/home/google/ gsoc2009/scilab * Several sympy projects: http://socghop.appspot.com/org/home/google/gsoc2009/portland_state All sympy projects are summarized here: http://code.google.com/p/sympy/wiki/GSoC2009 There are two Cython projects as well: Kurt Smith, Fortran support, http://wiki.cython.org/kwsmith/soc09 Danilo Freitas, C++ support, http://wiki.cython.org/gsoc09/daniloaf - 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: programming: define a new function
Kudos to SymPy! I'm wondering why the python integration algorithms implemented there aren't in the short term adopted by SAGE. They are --- you can use them from sympy inside Sage. It's my goal that all sympy features are nicely integrated in Sage. I work on this as time permits. Also, in the pynac-based symbolics that Mike Hansen has been polishing up for full inclusion in Sage (to replace the maxima based symbolics), one can just do f.integrate(algorithm=sympy) and sage will compute the integral using sympy. He's already implemented this and I've seen it work well when I tried it out. Yes, that way Sage allows to call any of those libraries very easily in Sage and at the same time uses just one library by default, that currently is the best at integrating, I guess still Maxima. There is an integration test suite at: http://axiom-developer.org/axiom-website/CATS which has the Schaums integral series along with examples. Each integral result is subtracted from the Schaums answer and then simplified, hopefully to a constant. How does Sympy compare? Tim Daly --~--~-~--~~~---~--~~ 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: programming: define a new function
On Wed, Apr 22, 2009 at 1:29 PM, root d...@axiom-developer.org wrote: There is an integration test suite at: http://axiom-developer.org/axiom-website/CATS which has the Schaums integral series along with examples. Each integral result is subtracted from the Schaums answer and then simplified, hopefully to a constant. How does Sympy compare? As far as I know, it hasn't been tested with it yet. I'm planning support for it, but I need to do some work in order to get the test suite working with it. It's on my list. Cheers, Tim Lahey. --~--~-~--~~~---~--~~ 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?
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.
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: Final 3.4.1 source released
On an upgrade from 3.4 on Mac OS X 10.5.6 (intel) I get the following doctest errors: The following tests failed: sage -t devel/sage/sage/algebras/quaternion_algebra_element.py sage -t devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py sage -t devel/sage/sage/structure/sage_object.pyx The errors are a bit long so here is a link to the test.log: http://www-rohan.sdsu.edu/~monarres/test.log -- David Monarres dmmonar...@gmail.com There... I've run rings 'round you logically -- Monty Python's Flying Circus On Apr 21, 2009, at 10:49 PM, mabshoff wrote: Hello folks, as expected changes over 3.4.1.rc4 are minimal: Merged in Sage 3.4.1.final: #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup to #5219) [Reviewed by Gonzalo Tornaria] #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed by Dan Drake] To build an SSE2 only binary do the following: SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE make This will obviously have an impact on performance and I am afraid it could be significant for certain problems. If anyone bothers to do two builds please let us know. Good candidates for performance regressions would be linear algebra, i.e. anything that involves ATLAS. All the bits are as usual in sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ I am building my 3.4.2.alpha0 merge tree and should merge in a couple hours. Hopefully 3.4.2.alpha0 will drop tomorrow. 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: programming: define a new function
On Wed, Apr 22, 2009 at 12:43 PM, Tim Lahey tim.la...@gmail.com wrote: On Wed, Apr 22, 2009 at 1:29 PM, root d...@axiom-developer.org wrote: There is an integration test suite at: http://axiom-developer.org/axiom-website/CATS which has the Schaums integral series along with examples. Each integral result is subtracted from the Schaums answer and then simplified, hopefully to a constant. How does Sympy compare? As far as I know, it hasn't been tested with it yet. I'm planning support for it, but I need to do some work in order to get the test suite working with it. It's on my list. It's on our list too, so it will happen eventually. We definitely still need to improve our algorithms a lot, see e.g.: http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea but a nice thing is that it's in Python, so it's easy to work with. 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: programming: define a new function
On Wed, Apr 22, 2009 at 4:10 PM, Ondrej Certik ond...@certik.cz wrote: It's on our list too, so it will happen eventually. We definitely still need to improve our algorithms a lot, see e.g.: http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea but a nice thing is that it's in Python, so it's easy to work with. Ondrej At some point I probably should get around to joining that group. If you have any suggestions for the testing architecture, I'd be happy to hear them. I've now started using GitHub's issues to do bug/issue tracking for the code. Cheers, Tim Lahey. --~--~-~--~~~---~--~~ 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: Final 3.4.1 source released
On Apr 22, 12:54 pm, David M. Monarres dmmonar...@gmail.com wrote: Hi David, On an upgrade from 3.4 on Mac OS X 10.5.6 (intel) I get the following doctest errors: Thanks for the build report. The following tests failed: sage -t devel/sage/sage/algebras/quaternion_algebra_element.py sage -t devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py sage -t devel/sage/sage/structure/sage_object.pyx The errors are a bit long so here is a link to the test.log: http://www-rohan.sdsu.edu/~monarres/test.log The problems: sage -t devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py ** File /Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py, line 4941: sage: P = G(E.0) + G(E.1) + G(phi(F.0)); P Expected: (-867/3872*a - 3615/3872 : -18003/170368*a - 374575/170368 : 1) Got: (-51/1058*a + 141/1058 : -1581/12167*a - 9912/12167 : 1) ** File /Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py, line 4943: sage: P.division_points(2) Expected: [(1/8*a + 5/8 : -5/16*a - 9/16 : 1)] Got: [(1/2*a - 1/2 : 1/2*a - 5/2 : 1)] ** File /Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py, line 3185: sage: E.cremona_label() Expected: Traceback (most recent call last): ... RuntimeError: Cremona label not known for Elliptic Curve defined by y^2 + x*y + 3*y = x^3 + 2*x^2 + 4*x + 5 over Rational Field. Got: '10351a1' ** This is caused by you having some optional Cremona database installed and it is #5346 which has a trivial fix suggested by John - someone just has to put a patch up and unless someone beats me to it I will do it tonight :) The other two failures are upgrade specific and happen when when left over pyc and so files are around due to the Quaternion classes being moved. One brutal fix is to do delete devel/sage* and to do a -ba. The more fine tuned fix is to delete some py files and touch a couple others followed by a -b, but I would need to look up the details. -- David Monarres dmmonar...@gmail.com Cheers, Michael There... I've run rings 'round you logically -- Monty Python's Flying Circus On Apr 21, 2009, at 10:49 PM, mabshoff wrote: Hello folks, as expected changes over 3.4.1.rc4 are minimal: Merged in Sage 3.4.1.final: #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup to #5219) [Reviewed by Gonzalo Tornaria] #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed by Dan Drake] To build an SSE2 only binary do the following: SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE make This will obviously have an impact on performance and I am afraid it could be significant for certain problems. If anyone bothers to do two builds please let us know. Good candidates for performance regressions would be linear algebra, i.e. anything that involves ATLAS. All the bits are as usual in sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ I am building my 3.4.2.alpha0 merge tree and should merge in a couple hours. Hopefully 3.4.2.alpha0 will drop tomorrow. 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: Final 3.4.1 source released
On Apr 22, 1:50 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 22, 12:54 pm, David M. Monarres dmmonar...@gmail.com wrote: Hi David, SNIP The other two failures are upgrade specific and happen when when left over pyc and so files are around due to the Quaternion classes being moved. One brutal fix is to do delete devel/sage* and to do a -ba. Ehh, devel/sage/build obviously - or if you nuked devel/sage* just force a rebuild of the sage.spkg via sage -f spkg/standard/sage-3.4.1.spkg Sorry for the double post, but I didn't want to kill people's install by incorrect advice. 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: trac ticket width and hgrc tips?
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.
For the last trac install we had also changed the color scheme for the
diffs due to problems for people with red-green color blindness, so I
will try to restore that fix today since I assume it is still desired,
too.
Nick
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: Indefinite Integration [WAS: programming: define a new function]
We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) That's definitely a very good thing, especially in getting people involved with development... Probably the best result is not just their short term, but also the chance of some long term commitment of good people. Besides, it will take almost a year to Sage too to release the new symbolics (started August 2008), so I don't think we are doing that bad. Also in terms of developers working just on symbolics, I think sympy has much more developers. I don't know if it's easy to extract just patches to Sage symbolics, to compare speeds of developments, but I would not be surprised if it turns out it's actually very comparable, or even less people are working on Sage symbolics than on sympy. That's a very good point. In my opinion, SAGE community is very good, and vast, and very well driven, but its focus it's actually quite far from symbolics (there's nothing bad about it), so I can see that for the time being, SymPy has some more inertia, thanks to the higher number of developers committed to symbolics (of course) rather than SAGE. At the same time, I think that SAGE can make a big step forward, once its community focuses on this task! Thanks a lot Maurizio --~--~-~--~~~---~--~~ 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: programming: define a new function
On Wed, Apr 22, 2009 at 1:12 PM, Tim Lahey tim.la...@gmail.com wrote: On Wed, Apr 22, 2009 at 4:10 PM, Ondrej Certik ond...@certik.cz wrote: It's on our list too, so it will happen eventually. We definitely still need to improve our algorithms a lot, see e.g.: http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea but a nice thing is that it's in Python, so it's easy to work with. Ondrej At some point I probably should get around to joining that group. If you have any suggestions for the testing architecture, I'd be happy to hear them. We use py.test/nosetest compatible tests, but if you prefer Sage like doctests, that's fine too. I've now started using GitHub's issues to do bug/issue tracking for the code. I only use github for storing the git repository, haven't used their bugs/issues yet. 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: Indefinite Integration [WAS: programming: define a new function]
On Wed, Apr 22, 2009 at 2:53 PM, Maurizio maurizio.gran...@gmail.com wrote: We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) PDE's are of course important, also it's my main research thing, but for sympy the assumptions are essential, because you cannot build a more advanced symbolics without a good assumption system. I am curious which approach Sage is going to use for this, since ginac doesn't have any assumptions. We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) That's definitely a very good thing, especially in getting people involved with development... Probably the best result is not just their short term, but also the chance of some long term commitment of good people. Exactly. Getting people to work with you is absolutely essential, that's my priority number one. If you work alone, you cannot do anything in the long term. 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: programming: define a new function
On Wed, Apr 22, 2009 at 6:11 PM, Ondrej Certik ond...@certik.cz wrote: We use py.test/nosetest compatible tests, but if you prefer Sage like doctests, that's fine too. Good to know. I'm not actually using any unit test classes at the moment since I have the difficulty that each test has different steps to properly compare the output to the Schaum's result. The multiple solutions also pose an additional difficulty. Cheers, Tim Lahey. --~--~-~--~~~---~--~~ 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: Final 3.4.1 source released
I am having an error in building 3.4.1 on an intel mac running 10.5. The error is in mpir: Deleting assembly files which depend on PIC assembly working or 32 bit OSX on Intel hardware checking build system type... Invalid configuration `penryn-apple- darwin9.6.0': machine `penryn-apple' not recognized configure: error: /bin/sh ./config.sub penryn-apple-darwin9.6.0 failed Failed to configure. The chip is an intel Core 2 Duo, 2.4 Ghz, on a Macbook. This was on a fresh source build, not an upgrade. -M. Hampton On Apr 22, 12:49 am, mabshoff mabsh...@googlemail.com wrote: Hello folks, as expected changes over 3.4.1.rc4 are minimal: Merged in Sage 3.4.1.final: #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup to #5219) [Reviewed by Gonzalo Tornaria] #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed by Dan Drake] To build an SSE2 only binary do the following: SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE make This will obviously have an impact on performance and I am afraid it could be significant for certain problems. If anyone bothers to do two builds please let us know. Good candidates for performance regressions would be linear algebra, i.e. anything that involves ATLAS. All the bits are as usual in sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ I am building my 3.4.2.alpha0 merge tree and should merge in a couple hours. Hopefully 3.4.2.alpha0 will drop tomorrow. 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: programming: define a new function
On Wed, Apr 22, 2009 at 3:27 PM, Tim Lahey tim.la...@gmail.com wrote: On Wed, Apr 22, 2009 at 6:11 PM, Ondrej Certik ond...@certik.cz wrote: We use py.test/nosetest compatible tests, but if you prefer Sage like doctests, that's fine too. Good to know. I'm not actually using any unit test classes at the moment since I have the difficulty that each test has different steps to properly compare the output to the Schaum's result. The multiple solutions also pose an additional difficulty. I think sympy will do very poorly if the assumptions are needed, we are still working on the assumptions. So if it turns out too difficult, just skip sympy for the time being, we'll get back to it later. 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: programming: define a new function
On Wed, Apr 22, 2009 at 6:31 PM, Ondrej Certik ond...@certik.cz wrote: I think sympy will do very poorly if the assumptions are needed, we are still working on the assumptions. So if it turns out too difficult, just skip sympy for the time being, we'll get back to it later. The problem arises with all the different integration systems. Usually some kind of simplification is needed on the integral returned, even if there aren't multiple solutions. This complicates the testing procedure since the steps to perform the simplification are often specific to the returned result. I'm currently aiming to finish the test suite just for Sage/Maxima and I'll go back and address the various issues (like testing SymPy) once that's complete. Cheers, Tim Lahey. --~--~-~--~~~---~--~~ 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: programming: define a new function
On Wed, Apr 22, 2009 at 3:35 PM, Tim Lahey tim.la...@gmail.com wrote: On Wed, Apr 22, 2009 at 6:31 PM, Ondrej Certik ond...@certik.cz wrote: I think sympy will do very poorly if the assumptions are needed, we are still working on the assumptions. So if it turns out too difficult, just skip sympy for the time being, we'll get back to it later. The problem arises with all the different integration systems. Usually some kind of simplification is needed on the integral returned, even if there aren't multiple solutions. This complicates the testing procedure since the steps to perform the simplification are often specific to the returned result. I'm currently aiming to finish the test suite just for Sage/Maxima and I'll go back and address the various issues (like testing SymPy) once that's complete. Ok, awesome. I am interested in all bugs that you find. Thanks for all the work you are doing, 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: programming: define a new function
On Wed, Apr 22, 2009 at 3:35 PM, Tim Lahey tim.la...@gmail.com wrote: The problem arises with all the different integration systems. Usually some kind of simplification is needed on the integral returned, even if there aren't multiple solutions. This complicates the testing procedure since the steps to perform the simplification are often specific to the returned result. I'm currently aiming to finish the test suite just for Sage/Maxima and I'll go back and address the various issues (like testing SymPy) once that's complete. Would it be better to test the results numerically? (For instance, evaluate the integral returned and the desired result at 100 random points to high precision, and ensure that the relative error between the answers at each point is small.) Of course, this wouldn't count as a proof that the result was correct, but IMHO it would be good enough (it seems unlikely that integration bugs would result in wrong answers that were numerically almost equivalent to the right answer). (Actually, I might actually trust a numeric result more than a symbolic simplification-based result, given the theoretical possibility that a simplification bug might cancel out an integration bug, leading to a false pass in the test suite; especially if simplification and integration are done in the same system.) 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: programming: define a new function
On Wed, Apr 22, 2009 at 6:54 PM, Carl Witty carl.wi...@gmail.com wrote: Would it be better to test the results numerically? (For instance, evaluate the integral returned and the desired result at 100 random points to high precision, and ensure that the relative error between the answers at each point is small.) How can one do that with symbolic variables? Most of the test integrals have symbolic constants (w.r.t the integration) so it isn't just the integration variable. I thought about numerical testing, but it isn't generally feasible. Of course, this wouldn't count as a proof that the result was correct, but IMHO it would be good enough (it seems unlikely that integration bugs would result in wrong answers that were numerically almost equivalent to the right answer). (Actually, I might actually trust a numeric result more than a symbolic simplification-based result, given the theoretical possibility that a simplification bug might cancel out an integration bug, leading to a false pass in the test suite; especially if simplification and integration are done in the same system.) It's possible to have simplification bugs, but I'll have to rely upon separate tests of the simplification system. Cheers, Tim Lahey. --~--~-~--~~~---~--~~ 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: programming: define a new function
On Wed, Apr 22, 2009 at 3:59 PM, Tim Lahey tim.la...@gmail.com wrote: On Wed, Apr 22, 2009 at 6:54 PM, Carl Witty carl.wi...@gmail.com wrote: Would it be better to test the results numerically? (For instance, evaluate the integral returned and the desired result at 100 random points to high precision, and ensure that the relative error between the answers at each point is small.) How can one do that with symbolic variables? Most of the test integrals have symbolic constants (w.r.t the integration) so it isn't just the integration variable. I thought about numerical testing, but it isn't generally feasible. Couldn't you just pick random values for all of the symbolic constants, as well? 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: programming: define a new function
On Wed, Apr 22, 2009 at 7:03 PM, Carl Witty carl.wi...@gmail.com wrote: Couldn't you just pick random values for all of the symbolic constants, as well? Yes, but over what range? If you do that, you've just ensured that it is correct for those points. It also could get expensive if you have multiple constants combined with the integration variable. It's an option to consider, but I'd probably only consider for those that don't simplify to the same result. It could also be done as an optional flag. I'll add it to the list of things to consider. If someone wants to add issues/bugs for me, it can be done at: http://github.com/tjl/sage_int_testing/issues It requires a GitHub account (which is free). Or one can e-mail me directly and I'll add it. Cheers, Tim. --~--~-~--~~~---~--~~ 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: Interesting google summer of code apps
On Apr 20, 8:15 pm, Jason Grout jason-s...@creativetrax.com wrote: In addition to the python summer of code projects, here are some other projects that may be interesting to Sage developers: * Scilab applications, including one that replaces maxima with a ginac-based symbolic system, another that explores moving algorithms to CUDA, etc. Seehttp://socghop.appspot.com/org/home/google/gsoc2009/scilab I checked on this, since it would be rather interesting to see Google fund a computer algebra system to replace Maxima. What I see is an (improved) way to link to maxima from Scilab. The (student?) would prefer to replace Maxima with Ginac because there is more programmers on C++ than Lisp, so more people would enhance the tool. This approach is the one I prefer. On that basis we should write programs in Chinese. There are so many more... :) RJF --~--~-~--~~~---~--~~ 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: Final 3.4.1 source released
Hi Marshall. I think I have a fix for this. But I've started a thread on the MPIR development list for this: http://groups.google.co.uk/group/mpir-devel/browse_thread/thread/34a4e60f556c8ba3 Bill. On 22 Apr, 23:31, Marshall Hampton hampto...@gmail.com wrote: I am having an error in building 3.4.1 on an intel mac running 10.5. The error is in mpir: Deleting assembly files which depend on PIC assembly working or 32 bit OSX on Intel hardware checking build system type... Invalid configuration `penryn-apple- darwin9.6.0': machine `penryn-apple' not recognized configure: error: /bin/sh ./config.sub penryn-apple-darwin9.6.0 failed Failed to configure. The chip is an intel Core 2 Duo, 2.4 Ghz, on a Macbook. This was on a fresh source build, not an upgrade. -M. Hampton On Apr 22, 12:49 am, mabshoff mabsh...@googlemail.com wrote: Hello folks, as expected changes over 3.4.1.rc4 are minimal: Merged in Sage 3.4.1.final: #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup to #5219) [Reviewed by Gonzalo Tornaria] #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed by Dan Drake] To build an SSE2 only binary do the following: SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE make This will obviously have an impact on performance and I am afraid it could be significant for certain problems. If anyone bothers to do two builds please let us know. Good candidates for performance regressions would be linear algebra, i.e. anything that involves ATLAS. All the bits are as usual in sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ I am building my 3.4.2.alpha0 merge tree and should merge in a couple hours. Hopefully 3.4.2.alpha0 will drop tomorrow. 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: programming: define a new function
It's on our list too, so it will happen eventually. We definitely still need to improve our algorithms a lot, see e.g.: http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea but a nice thing is that it's in Python, so it's easy to work with. Ondrej At some point I probably should get around to joining that group. If you have any suggestions for the testing architecture, I'd be happy to hear them. I've now started using GitHub's issues to do bug/issue tracking for the code. What's the github name? Tim Daly --~--~-~--~~~---~--~~ 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 4.0 release plan
Hello, while there should be a quick 3.4.2 to mop up patches from trac before the big 4.0 jump today we had a planning session during the UW status meeting about the goals for Sage 4.0. The result is at http://wiki.sagemath.org/plan/sage-4.0 It still needs a little polish, i.e. the issues for Solaris as well as 64 bit OSX support need to be fleshed out, but the 75% coverage target has a lot of concrete projects and/or suggestions on what to attack. If anyone has some other suggestions for large projects that are doable in the next 3 weeks please let us know. 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: programming: define a new function
On Apr 22, 2009, at 5:13 PM, root wrote: It's on our list too, so it will happen eventually. We definitely still need to improve our algorithms a lot, see e.g.: http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea but a nice thing is that it's in Python, so it's easy to work with. Ondrej At some point I probably should get around to joining that group. If you have any suggestions for the testing architecture, I'd be happy to hear them. I've now started using GitHub's issues to do bug/issue tracking for the code. What's the github name? The issue tracker: http://github.com/tjl/sage_int_testing/issues and the main repository: http://github.com/tjl/sage_int_testing/tree/master Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://www.linkedin.com/in/timlahey --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
