On Nov 26, 2007 6:34 AM, Joel B. Mohler <[EMAIL PROTECTED]> wrote: > Well, if I had to pick a nasty point to sage I would agree that it's huge-ness > is seriously annoying. The slow import of "sage.all" really kills the > pleasure for writing python programs which you want to use from bash, but I > realize that I'm a bit unusual to actually use it that way. I would love
Ondrej says: > And I think SAGE will eventually get there. The speed of import can be > cured, by importing things on the fly, etc. etc. Ondrej is 100% right. This slow import is not necessarily a function of sage being huge, but of nobody lately going through and auditing what happens when one does $ sage -ipython >>> import sage.all I've done this in the past several times and each time greatly sped things up. Doing this can be helpful: $ echo "%prun import sage.all" |sage -ipython Then commenting things out, etc., etc. For example, importing numpy takes (or at least used to take) a surprisingly long time, so I have to be careful to make sure Sage doesn't import that by default on startup. Same goes for matplotlib -- never ever import that at the module level -- make the import lazy, and things are much faster. I think the sage startup time could be greatly reduced with some work. > more modularity, but I'm not convinced it's possible. I mean, this huge-ness > is a wart in many ways, but quite frankly I've not seen any other mathematics > package which I would look forward to using for a lifetime of mathematics (at When I'm actually doing real work, research, teaching, etc. this hugeness is not a wart to me at least in any way at all. It means that the resources are there to do what I want. Instead of hunting around for, installing, building, learning new programs, I get work done. To quote Michael Stoll when he switched from lots of little tools to Magma 10 years ago: "it is very nice to have everything under one roof". He cares about getting research done. Period. And could care less about "unix philosophy". At the end of the day, I tend to agree. > I am wondering though what kind of support for matrices and polynomials (for > examples) you might envision with sympy. I see that you currently have > support listed for these things, but if it's pure python the sage equivalents > are going to be much faster. It seems that you could gain so much by sharing > these goals with sage. The sage equivalents only work when all coefficients of the polynomial lie in a specific ring. Sympy does polynomial multiplication generically, which requires generic files. > and we really need a symbolic alternative -- sympy seems just the thing. I > think sage's symbolic side should be strong enough that we really shouldn't > have to break out the special polynomial declarations unless you are doing > something very special purpose. This might require a very very smart > symbolic engine to detect when it is working with polynomials and use > polynomial algorithms behind the scenes instead of more generic symbolic > ones. I think if we could pull that off, then even the number theorists > might find themselves working with the symbolic expressions. This would be a > huge step towards mathematica level friendliness imo. You're right. In fact I already work with symbolic expressions frequently, when it makes sense to do so. :-) But personally my first priority is creating a viable alternative to the big systems, before trying to do some sort of open ended research system that's really hard to write. Ondrej: > which goes into my patch, with x==Spec(QQ) and y==5, it pass all my > ifs, and then it segfaults. The workaround is to check that they have > the same parent, or just call _verify_canonical_coercion_c, that does > exactly that for me. It is wrong / abusive to call _verify_canonical_coercion_c because that function is never supposed to fail. You should check that the parents are the same explicitly and if not pass through to the next case. William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
