[sage-devel] number field arithmetic
Hi, I have some questions about arithmetic speed. I'm comparing my pyrexified version of the number field with patch at: http://sage.math.washington.edu/home/jbmohler/patches/number_field_element_2007_03_26.patch As we might expect, after hammering at the integers for quite a long time, magma beats the number field arithmetic too. The speed difference is comparable for addition, subtraction, and multiplication. However, we've got issues with division. Some speed comparisons are at the bottom. First question, magma blows us way on division. Obviously, division by an integer (as in the timing below) could be made much faster by utilizing the fact that we have a scalar. However, this doesn't seem to be the issue since I/I produces comparable timings. Is there a much better way to find an inverse than the extended euclidean algorithm? I observe that the old python implementation asked pari for the inverse and it was also extremely slow -- perhaps for other reasons. And here's a more general question. What's the current state of our SageX art for making these things fast? Does someone have a trick up their sleeve to get these basic arithmetic operations a bit faster from the python shell? -- Joel P.S.: Speed comparisons (all on sage.math). I've included the basic integer arithmetic example to show that the everything is off at about the same factor (6-10). [EMAIL PROTECTED]:~$ magma Magma V2.13-5 Tue Mar 27 2007 07:12:02 on sage [Seed = 1950028839] Type ? for help. Type Ctrl-D to quit. CI:=QuadraticField(-1); time for x in [1..10] do a:=I*I; end for; Time: 0.260 time for x in [1..10] do a:=I/2; end for; Time: 0.370 time for x in [1..10] do a:=1+1; end for; Time: 0.020 sage: C.I=QuadraticField(-1) sage: time for i in xrange(10): a=I*I CPU times: user 1.79 s, sys: 0.03 s, total: 1.82 s Wall time: 1.82 sage: time for i in xrange(10): a=I/2 CPU times: user 10.24 s, sys: 0.12 s, total: 10.37 s Wall time: 10.37 sage: time for i in xrange(10): a=1+1 CPU times: user 0.27 s, sys: 0.00 s, total: 0.27 s Wall time: 0.27 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: number field arithmetic
On 3/27/07, Joel B. Mohler [EMAIL PROTECTED] wrote: P.S.: Speed comparisons (all on sage.math). I've included the basic integer In all your timings below that involve a constant (e.g., 1 or 2), you should factor out the constant from the test. E.g., do a = 1; b = 2; then do the test with a and b. Otherwise the Integer( ) function is being called every time on a Python int, and you're (1) testing the wrong thing, and (2) testing something that won't reflect how actual code will behave. Having the preparser factor out constants could be done, and will be someday, at least for .sage files. \ [EMAIL PROTECTED]:~$ magma Magma V2.13-5 Tue Mar 27 2007 07:12:02 on sage [Seed = 1950028839] Type ? for help. Type Ctrl-D to quit. CI:=QuadraticField(-1); time for x in [1..10] do a:=I*I; end for; Time: 0.260 time for x in [1..10] do a:=I/2; end for; Time: 0.370 time for x in [1..10] do a:=1+1; end for; Time: 0.020 sage: C.I=QuadraticField(-1) sage: time for i in xrange(10): a=I*I CPU times: user 1.79 s, sys: 0.03 s, total: 1.82 s Wall time: 1.82 sage: time for i in xrange(10): a=I/2 CPU times: user 10.24 s, sys: 0.12 s, total: 10.37 s Wall time: 10.37 sage: time for i in xrange(10): a=1+1 CPU times: user 0.27 s, sys: 0.00 s, total: 0.27 s Wall time: 0.27 -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: number field arithmetic
On Mar 27, 2007, at 10:26 AM, Joel B. Mohler wrote: First question, magma blows us way on division. Obviously, division by an integer (as in the timing below) could be made much faster by utilizing the fact that we have a scalar. However, this doesn't seem to be the issue since I/I produces comparable timings. But I/I is not scalar division, if you are representing I as the polynomial X in the ring Q[X]/(1+X^2). Is there a much better way to find an inverse than the extended euclidean algorithm? In general, I don't think so, but it's quite possible (in fact I think very likely) that magma has special code to deal with quadratic extensions, in which case obviously everything can be done much more efficiently. For more data points, you could try two things: (1) try the same tests as below, but for a more complicated number field, at least degree 4, with a pretty random looking defining polynomial, and (2) compare magma's performance in quadratic fields against its general number field stuff. And here's a more general question. What's the current state of our SageX art for making these things fast? Does someone have a trick up their sleeve to get these basic arithmetic operations a bit faster from the python shell? At the moment there are so many different reasons that the code could be slow, I don't think you've at all pinned it down to a sagex issue yet. david P.S.: Speed comparisons (all on sage.math). I've included the basic integer arithmetic example to show that the everything is off at about the same factor (6-10). [EMAIL PROTECTED]:~$ magma Magma V2.13-5 Tue Mar 27 2007 07:12:02 on sage [Seed = 1950028839] Type ? for help. Type Ctrl-D to quit. CI:=QuadraticField(-1); time for x in [1..10] do a:=I*I; end for; Time: 0.260 time for x in [1..10] do a:=I/2; end for; Time: 0.370 time for x in [1..10] do a:=1+1; end for; Time: 0.020 sage: C.I=QuadraticField(-1) sage: time for i in xrange(10): a=I*I CPU times: user 1.79 s, sys: 0.03 s, total: 1.82 s Wall time: 1.82 sage: time for i in xrange(10): a=I/2 CPU times: user 10.24 s, sys: 0.12 s, total: 10.37 s Wall time: 10.37 sage: time for i in xrange(10): a=1+1 CPU times: user 0.27 s, sys: 0.00 s, total: 0.27 s Wall time: 0.27 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: number field arithmetic
On Tue, Mar 27, 2007 at 07:36:18AM -0700, William Stein wrote: On 3/27/07, Joel B. Mohler [EMAIL PROTECTED] wrote: P.S.: Speed comparisons (all on sage.math). I've included the basic integer In all your timings below that involve a constant (e.g., 1 or 2), you should factor out the constant from the test. E.g., do a = 1; b = 2; then do the test with a and b. Otherwise the Integer( ) function is being called every time on a Python int, and you're (1) testing the wrong thing, and (2) testing something that won't reflect how actual code will behave. Good point! Corrected timings are below. That explains why the number field arithmetic was slower by a smaller multiplicative factor. [EMAIL PROTECTED]:~$ magma Magma V2.13-5 Tue Mar 27 2007 07:12:02 on sage [Seed = 1950028839] Type ? for help. Type Ctrl-D to quit. CI:=QuadraticField(-1); time for x in [1..10] do a:=I*I; end for; Time: 0.260 time for x in [1..10] do a:=I/2; end for; Time: 0.370 time for x in [1..10] do a:=1+1; end for; Time: 0.020 [EMAIL PROTECTED]:~$ sage -- | SAGE Version 2.4, Release Date: 2007-03-25 | | Type notebook() for the GUI, and license() for information.| -- Loading SAGE library. Current Mercurial branch is: nf sage: C.I=QuadraticField(-1) sage: time for i in xrange(10): a=I*I CPU times: user 1.80 s, sys: 0.02 s, total: 1.82 s Wall time: 1.82 sage: two=2 sage: time for i in xrange(10): a=I/two CPU times: user 9.94 s, sys: 0.13 s, total: 10.07 s Wall time: 10.07 sage: one=1 sage: time for i in xrange(10): a=one+one CPU times: user 0.10 s, sys: 0.01 s, total: 0.11 s Wall time: 0.11 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Sage rep. at ECCAD?
Hi All, Are any Sage evangelists planning to attend the East Coast Computer Algebra Day? http://eccad07.washcoll.edu/ --jason -- Jason Worth Martin Asst. Prof. of Mathematics James Madison University http://www.math.jmu.edu/~martin phone: (+1) 540-568-5101 fax: (+1) 540-568-6857 Ever my heart rises as we draw near the mountains. There is good rock here. -- Gimli, son of Gloin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage rep. at ECCAD?
I see Didier Deshommes has registered. I just did as well, but don't know (if or) when I'll how up (it depends on other variables). On 3/27/07, Jason Martin [EMAIL PROTECTED] wrote: Hi All, Are any Sage evangelists planning to attend the East Coast Computer Algebra Day? http://eccad07.washcoll.edu/ --jason -- Jason Worth Martin Asst. Prof. of Mathematics James Madison University http://www.math.jmu.edu/~martin phone: (+1) 540-568-5101 fax: (+1) 540-568-6857 Ever my heart rises as we draw near the mountains. There is good rock here. -- Gimli, son of Gloin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: number field arithmetic
On 3/27/07, David Harvey [EMAIL PROTECTED] wrote: Is there a much better way to find an inverse than the extended euclidean algorithm? In general, I don't think so, but it's quite possible (in fact I think very likely) that magma has special code to deal with quadratic extensions, in which case obviously everything can be done much more efficiently. Undoubtedly MAGMA has special code for quadratic fields. I don't know the situation today, but for a very long time my understanding is that MAGMA's quadratic field arithmetic was simply a wrapper around the highly optimized quadratic field arithmetic in the PARI C library. (MAGMA used KANT for general number fields and PARI for quadratic fields.) For more data points, you could try two things: (1) try the same tests as below, but for a more complicated number field, at least degree 4, with a pretty random looking defining polynomial, and (2) compare magma's performance in quadratic fields against its general number field stuff. Agreed. Also, consider creating the same loops in %sagex block in the notebook. It's very good to have a sense of how that performs as well, since writing in SageX is an important and viable option when writing in SAGE. -- Willia --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] help wanted: Conway Polynomial Database
Hi, Would anybody like to volunteer to recreate the Conway polynomials database from the raw text data? I screwed up and lost any code used to create it. Let me know if you're interested in helping. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] phc interface; numerical roots
Hi, I am interested in using phc through sage, and it looks like phc.py is pretty broken. I've hacked it up to work in blackbox mode (i.e. you type 'phc -b inputfile outputfile' and it doesn't ask any questions), and if there is any interest I can try to clean up my efforts. Does anyone know if there are tools in SAGE for parsing the output of phc? That is what I am really interested in; I will start writing one if it doesn't exist. A related question is: what is the easiest/best way to get the numerical roots of a polynomial in SAGE? For simplicity, assume that the polynomial has coefficients in QQ. -Marshall Hampton --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: help wanted: Conway Polynomial Database
On 3/27/07, David Joyner [EMAIL PROTECTED] wrote: I can help for about 1 week starting Thursday. Thanks. I think the whole project will only take you a few hours, actually. (I would do it, but I'm teaching a lot -- by my standards -- this quarter.)Write to me when you're available and I'll explain more. On 3/27/07, William Stein [EMAIL PROTECTED] wrote: Hi, Would anybody like to volunteer to recreate the Conway polynomials database from the raw text data? I screwed up and lost any code used to create it. Let me know if you're interested in helping. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: help wanted: Conway Polynomial Database
Feel free to bug me if you want help to export the data from GAP in any particular format. The data there is a little old, Aug 2006, but still pretty extensive. I'm not sure if the point if to double-check them from the raw text. I'd be interested in checking for agreement and coverage if the data source is particular different from GAP as well. On Mar 27, 1:00 pm, David Joyner [EMAIL PROTECTED] wrote: I can help for about 1 week starting Thursday. On 3/27/07, William Stein [EMAIL PROTECTED] wrote: Hi, Would anybody like to volunteer to recreate the Conway polynomials database from the raw text data? I screwed up and lost any code used to create it. Let me know if you're interested in helping. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Decimal number literals
On Mar 27, 2007, at 11:01 AM, Nick Alexander wrote: On 26 Mar 2007, at 16:42, Robert Bradshaw wrote: In working with higher-precision real numbers, I've come across this odd behavior: sage: RealField(200)(1.2) 1.199955591079014993738383054733276367187500 I understand what's going on, it's creating a 53-bit float approximation for 1.2, then coercing that exactly into the real field of higher precision. I was thinking perhaps of pre-parsing this to a DecimalLiteral class thus postponing the binary approximation until we know what ring it should live in (e.g. via coercion or arithmetic). I am thinking that arithmetic between two such literal decimals would involve calling create_RealNumber() on both arguments (as the preparser does now) and then performing the arithmetic (to avoid slowness (or re-implementation) of the decimals package). It worries me that sage: type(1.1) DecimalLiteral sage: type(1.1 + 1.2) some real field I find that confusing. Would it be sensible to preparse into a field that handled arbitrary precision (maybe the mpfi fields?) and then use the existing coerce/call mechanism to handle the specific field in question? Unfortunately, we don't have a field right now that has arbitrary precision, though in a way this would be one. One could (potentially) make/use a lazy real field, but I am almost certain that arithmetic in such a field would be slow enough that it would be a bad choice for the default field. I do want to leverage the coercion/calling mechanism, but the problem is that every float is truncated down to 53 bits of precision on parsing before anything else can get to it. An alternative is making decimals a full field. sage: type(1.1) DecimalLiteral sage: type(1.1 + 1.2) DecimalLiteral sage: 1.1 + 1.25 1.35 sage: 3.14159 ^ 10 # here we turn a number with 5 digits of precision to one with 50? 93647.25646787226922299505202262723704312737441654490401 sage: type(1.2 / 1.1) # can't be represented as a finite decimal, and the / operator often returns elements of a different field some real field sage: type(sqrt(1.1)) # same some real field I'm not sure this is the best approach. Right now one works implicitly in some default real field, but (typically) enters input as decimal strings. I think this is a good model, but makes it difficult/non-obvious when creating/mixing numbers with higher than default of precision. P.S. Also, I was wondering what the implications would be of making the default 53-bit filed into QDF rather than RealField (53). (Other than vastly increased efficiency of course.) I expect lots of doctests would break. The number of different Real Field implementations is getting such that I have no idea which one to use in which situation. Yes, I am aware that lots of doctests would break, but if its just a change in the last decimal or two(?) I'm OK with fixing that. I'm wondering if anyone knows of any algorithms/etc. that rely on MPFR 53- bit rather than native cdef doubles (also 53 bit). Are there any ways that MPFR is better at this precision that native doubles (which are much faster)? For real fields we have: - MPFR (this is the default, and RR is a 53-bit MPFR): Arbitrary (fixed) precision, based on gmp. - RDF: Stores real numbers as cdef doubles, very fast (though not quite as fast as python floats (yet)). Sorry about the typo above, I meant using RDF by default. - floats: not sage objects, but the fastest if you want to do arithmetic in python (think int vs Integer) - RQDF (from __future__): 212 bit precision based on the exact sum of 4 doubles. Arithmetic almost equal to 212-bit MPFR. Trig functions almost 50% faster, other special functions on par to 50% slower. I think there may be potential here for additional speedup here especially in the object creation/destruction phase. MPFI: This is interval arithmetic over the reals, which is useful but a different goal. Thank you for your comments, Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: phc interface; numerical roots
On Mar 27, 10:07 am, Hamptonio [EMAIL PROTECTED] wrote: Hi, I am interested in using phc through sage, and it looks like phc.py is pretty broken. I've hacked it up to work in blackbox mode (i.e. you type 'phc -b inputfile outputfile' and it doesn't ask any questions), and if there is any interest I can try to clean up my efforts. Does anyone know if there are tools in SAGE for parsing the output of phc? That is what I am really interested in; I will start writing one if it doesn't exist. I can't say anything about this. A related question is: what is the easiest/best way to get the numerical roots of a polynomial in SAGE? For simplicity, assume that the polynomial has coefficients in QQ. Investigate x.roots via x.roots?, x.roots?? and friends such as x.factor. (Assuming x = QQ['x'].gen()). Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] sage-2.4.1
Hello, I've released sage-2.4.1. It has: * d roe: massively updated p-adics code * r bradshaw: much misc code; Coleman integration * misc bug fixes This should be a painless upgrade for you. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: the SAGE notebook and GAP; Re: [GAP Support] GUI for GAP in Windows
Regarding (3), I'm arguing that is what is in your best interest. As far as I know, almost *nobody* has tried working with the SAGE notebook using notebook(system=gap) so if things don't work optimally when doing so, it's not surprising. Moreover, I want to emphasize that it would be possible to create a SAGE/GAP Notebook that would only require Python and some Python libraries, and very little of the rest of SAGE. Indeed, when the SAGE notebook runs, it loads only a small part of the SAGE libraries. Nobody has made a standalone Python package version of the SAGE notebook, which installs into an existing Python install, but it would not only be possible, but would be reasonably easy. It would mainly require creating a modified setup.py. In any case, it would be *vastly* *vastly* easier than doing (1) above, and certainly much easier than (2) as well. I haven't done it, because I have no need to personally. Regarding the above, I wanted to mention that Dorian and I are very interested in a general standalone notebook. We have been working on this, focusing on: security, generality, cross-browser compatibility, and supporting multiple users building off of Twisted, Mochikit, and SQLite. Alex --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Decimal number literals
On Mar 27, 12:12 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Yes, I am aware that lots of doctests would break, but if its just a change in the last decimal or two(?) I'm OK with fixing that. I'm wondering if anyone knows of any algorithms/etc. that rely on MPFR 53- bit rather than native cdef doubles (also 53 bit). Are there any ways that MPFR is better at this precision that native doubles (which are much faster)? MPFR is better than native doubles in at least two ways: MPFR has a much wider range of possible values (up to about 2^(2^31), instead of about 2^1024), and MPFR gives the best possible rounded floating-point value for all supported floating-point operations in all rounding modes. I will call this best possible answer the precise answer; an answer which is not the best possible answer is imprecise (even if it is off by only the least significant bit). As far as I know, virtually all modern computer architectures support IEEE double-precision arithmetic, which guarantees that the basic operations (+,-,*,/,sqrt) are precise, but says very little about other operations. Other operations may not be portable across architectures (or even operating systems). Also, other operations may not work correctly in rounding modes other than round-to-nearest. In the rest of this message, I will use IEEE compliance to refer to this basic requirement, ignoring other IEEE requirements like exception handling. SAGE currently has no support for rounding modes other than round-to- nearest for native doubles. The situation is more complicated for 32-bit x86 processors, which are not IEEE compliant by default. I believe that SAGE on 32-bit x86 is not IEEE compliant for RDF, for Python doubles, or for SAGEX doubles (and it's possible that each of these gives a different answer). So for portable, precise computation with control over rounding modes, MPFR is the way to go. Native doubles are useful if: 1) you don't need portability or precision, or 2) you only need basic operations (+,-,*,/,sqrt) in round-to-nearest mode, and you're not on 32-bit x86. IEEE compliance for 32-bit x86 can be greatly improved by setting a processor flag (although there's no flag that gives the correct behavior on overflows; an x86 running in this mode might compute a finite value when a truly IEEE compliant processor would give an answer of Infinity). For modern x86 processors, you can also get full IEEE compliance by using SSE2 instructions instead of 80387 instructions for floating-point arithmetic; a version of SAGE compiled this way would probably be faster, but would not run on older or cheaper processors (pre-Pentium 4 Intel processors, for instance). Hope this helps. Carl Witty --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
[sage-devel] question: how to upgrade
pardon my ignorance, as i'm sure it's been explainedbefore, but if i've made local changes to the sage code, what's the proper way to upgrade? if i type sage -upgrade, will it clobber my changes? how do i merge in the new features in going from, say, 2.3 to 2.4.1? thanks. kyle --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~--~~~~--~~--~--~---
