[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 -D to quit. > C:=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.=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 -D to quit. > > C:=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.=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 -D to quit. >> C:=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.=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 -D to quit. > C:=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.=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] Re: number field arithmetic
On 3/27/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~$ magma
> Magma V2.13-5 Tue Mar 27 2007 07:12:02 on sage [Seed = 1950028839]
> Type ? for help. Type -D to quit.
> > C:=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
Joel,
If you want to time what PARI is really capable of, ignoring all issues
of SAGE and memory management that might get in the way, you
should do tests like this:
sage: gp.eval('k=Mod(x,x^2+1); gettime; for(i=1,10^5,b=k*k);
print(gettime/1000.0)')
'0.260'
Interestingly, PARI is *exactly* the same speed as MAGMA,
and it's better than MAGMA at the divide by 2 tests (probably because
there's less implicit conversion code going in on PARI):
sage: gp.eval('k=Mod(x,x^2+1); gettime; for(i=1,10^5,b=k/2);
print(gettime/1000.0)')
'0.156000'
You could get timings like above (+Python object creation time!)
by directly writing your .pyx number field element wrapper
to use the PARI C library. You would want to do this in a way
that deals sensibly with the really subtle issues involved in PARI's (lack of?)
memory management, and hopefully doesn't mess up the SAGE pari
wrapper in gen.pyx.
Anyway, I'm just letting you know that this is another potentially viable
option to pursue if you want frickin' fast number field arithmetic in SAGE.
-- William
>
> [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.=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] 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] Re: help wanted: Conway Polynomial Database
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] 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: question: how to upgrade
If you've made your changes in sage-main, it will try and merge them in automatically when you do sage -upgrade. You have to check in your local changes first. Probably the safest way is to re-name your current sage-main to something else (e.g. sage-old). Then do a sage - upgrade, and it will create a fresh sage-main. You can then "pull" your changes manually from sage-old into sage-main using hg_sage (from within sage) or sage -hg [command] (from the command line). To be more explicit, cd sage-old sage -hg commit cd sage-main sage -hg incoming ../sage-old [list of all the changes you made] sage -hg pull ../sage-old [applies sage-old changes to sage-main branch] sage -hg merge If the merge goes well do sage -hg commit Depending on how often you make changes, you may want to look into hg's branch cloning abilities. If you think your changes would be of general interest, submit a patch and you may get them bundled with the next sage -upgrade :). On Mar 27, 2007, at 11:26 PM, Kyle Schalm wrote: > 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Decimal number literals
Thank you. This is exactly the kind of information I was looking for. I knew about the range of values limitation, but was only vaguely aware of the rest. The situation I'm thinking of is the default implicit ring (e.g. when one enters "3.2") in which case the lack of support for rounding modes wouldn't probably be a big issue (if one cares about such things, one would probably want to specify it explicitly). The lack of precision/portability/consistency could be a major issue though. Of course all options would be available explicitly, but do you think this last point is severe enough to write off using them as the default implicit ring despite their relative inefficiency? Perhaps one could claim that they only really have 51 bits of precision (or are the answers sometimes way off, other than inf/nan)? - Robert On Mar 27, 2007, at 10:34 PM, cwitty wrote: > 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/ -~--~~~~--~~--~--~---
