[sage-devel] Re: request for testing: flint-1.0.spkg
Ah I just found another problem. Although c99 requires stdint.h to define these things, I am including sys/types.h which is not the accredited cross platform solution. I apparently consulted a dodgy document on the web which gets this wrong. On many systems sys/types.h #includes stdint.h, but apparently not on all systems. I'll fix this too in FLINT 1.01. As for the *system* not being c99 compliant, I don't see how this can be. Isn't c99 a compiler standard? So if you have gcc 3.4.1 or later, there should be a stdint.h accessible. If not, then so much for gcc being c99 compliant from 3.4.1 onwards. Bill. On Dec 7, 8:51 am, Bill Hart <[EMAIL PROTECTED]> wrote: > On 7 Dec, 04:30, mabshoff <[EMAIL PROTECTED] > > > > dortmund.de> wrote: > > On Dec 7, 12:02 am, Bill Hart <[EMAIL PROTECTED]> wrote: > > > > You hopefully mean uint64_t, not u_int64_t. There should be no > > > occurrences of u_int64_t left in FLINT. If that's not the case, please > > > let me know. > > > [EMAIL PROTECTED] flint-1.0$ grep -r u_int64_t * > > src/long_extras.c:static u_int64_t randval = 4035456057U; > > src/long_extras.c:randval = > > ((u_int64_t)randval*(u_int64_t)1025416097U+(u_int64_t)286824430U)% > > (u_int64_t)4294967311U; > > src/QS/block_lanczos.h:u_int64_t get_null_entry(u_int64_t *, long, > > long); > > src/QS/block_lanczos.h:u_int64_t * block_lanczos(unsigned long, > > unsigned long, unsigned long, la_col_t*); > > > Hey, it is *your* code, but I am always glad to help out ;) > > Oops, You are right. long_extras is being compiled when you do make > library. > > OK, these u_int64_t's should all be uint64_t's. And indeed uint64_t > should be long long on SPARC32. > > Since the compiler should be c99, probably just changing this to > uint64_t everywhere will fix the problem, since manifestly the machine > has a 64 bit type. > > I've changed it in the FLINT code and will commit it to SVN soon. This > is basically a bug, so I'll have to change it in FLINT 1.0 as well, > i.e. release FLINT 1.01. There are also a few typos on the manual > which I will commit at the same time. > > > > > > Also, if uint32_t is not available in 32 bit mode, your compiler is > > > either not c99 compliant or the machine does not have both a native 32 > > > bit type and a native 16 bit type, in which case FLINT will not work > > > on this machine. This is why the test fails. > > > gcc has a stdint.h in its own header tree under tr1, so I am not too > > happy about that. But there are various sys/types.h sys/int_types.h, > > sys/types32.h and so on in /usr/include. Since gmp works perfectly > > fine on that box (I believe longlong.h originates from there, but I > > didn't check) I should figure out what gmp does in that case. > > Well surely the only relevant file here is the stdint.h file. That is > the one that c99 is required to provide. > > > > > > You definitely should not be defining uint64_t if you are in 32 bit > > > mode. > > So this is now wrong. uint64_t does need to be defined after all. But > I still maintain that c99 should provide it for you on this machine. > > Hopefully we aren't targetting any machines which don't have a 64 bit > type available otherwise the quadratic sieve is not going to work. > > None of this has any bearing on the failing test though. For that, > uint64_t is irrelevant. > > > > > > But you do need to define uint16_t. The fact that it compiles at > > > all suggests something is very, very wrong. If the compiler is c99 > > > compliant, you should not need to define anything to make it compile. > > > If you do, FLINT can't support the machine at present. > > > > To debug this you need to know the values of: > > > > 1) FLINT_BITS (it's a macro in flint.h) > > > > 2) sizeof(uint32_t) > > > > 3) sizeof(uint16_t) > > > > If the machine truly is running in 32 bit mode the values you get > > > should be 32, 4 and 2. Only then will the FLINT tests pass. > > > > If you get 64 for number (1) then uint64_t and uint32_t should be > > > defined. In that case you should look at the values of > > > > 1) FLINT_BITS > > > > 2) sizeof(uint64_t) > > > > 3) sizeof(uint32_t) > > > > The values you should get in this case should be 64, 8, 4. Only then > > > will the FLINT tests pass. > > > I will dig into this in the next couple days, after I got ATLAS and > > PolyBoRi merged. Please ping me in a week or so if nothing happens. > > OK, all the info here should be correct, so I'll be interested to hear > what you come up with. Essentially you just need a 5 line program > which #includes flint.h and prints off the values above. I don't think > I have access to SPARC32 myself. > > > > > > > > As for the quadratic sieve, yes it is included in FLINT 1.0, but is a > > > completely new beast (and much faster). Simply make QS to build it. > > > The program is called mpQS. It is fairly similar to the old > > > QuadraticSieve program, and with any luck the output is formatted the > > > same. > > > > The program now *requires* that the inp
[sage-devel] Re: request for testing: flint-1.0.spkg
On 7 Dec, 04:30, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > On Dec 7, 12:02 am, Bill Hart <[EMAIL PROTECTED]> wrote: > > > You hopefully mean uint64_t, not u_int64_t. There should be no > > occurrences of u_int64_t left in FLINT. If that's not the case, please > > let me know. > > [EMAIL PROTECTED] flint-1.0$ grep -r u_int64_t * > src/long_extras.c:static u_int64_t randval = 4035456057U; > src/long_extras.c:randval = > ((u_int64_t)randval*(u_int64_t)1025416097U+(u_int64_t)286824430U)% > (u_int64_t)4294967311U; > src/QS/block_lanczos.h:u_int64_t get_null_entry(u_int64_t *, long, > long); > src/QS/block_lanczos.h:u_int64_t * block_lanczos(unsigned long, > unsigned long, unsigned long, la_col_t*); > > Hey, it is *your* code, but I am always glad to help out ;) Oops, You are right. long_extras is being compiled when you do make library. OK, these u_int64_t's should all be uint64_t's. And indeed uint64_t should be long long on SPARC32. Since the compiler should be c99, probably just changing this to uint64_t everywhere will fix the problem, since manifestly the machine has a 64 bit type. I've changed it in the FLINT code and will commit it to SVN soon. This is basically a bug, so I'll have to change it in FLINT 1.0 as well, i.e. release FLINT 1.01. There are also a few typos on the manual which I will commit at the same time. > > > Also, if uint32_t is not available in 32 bit mode, your compiler is > > either not c99 compliant or the machine does not have both a native 32 > > bit type and a native 16 bit type, in which case FLINT will not work > > on this machine. This is why the test fails. > > gcc has a stdint.h in its own header tree under tr1, so I am not too > happy about that. But there are various sys/types.h sys/int_types.h, > sys/types32.h and so on in /usr/include. Since gmp works perfectly > fine on that box (I believe longlong.h originates from there, but I > didn't check) I should figure out what gmp does in that case. Well surely the only relevant file here is the stdint.h file. That is the one that c99 is required to provide. > > > > > You definitely should not be defining uint64_t if you are in 32 bit > > mode. So this is now wrong. uint64_t does need to be defined after all. But I still maintain that c99 should provide it for you on this machine. Hopefully we aren't targetting any machines which don't have a 64 bit type available otherwise the quadratic sieve is not going to work. None of this has any bearing on the failing test though. For that, uint64_t is irrelevant. > > But you do need to define uint16_t. The fact that it compiles at > > all suggests something is very, very wrong. If the compiler is c99 > > compliant, you should not need to define anything to make it compile. > > If you do, FLINT can't support the machine at present. > > > To debug this you need to know the values of: > > > 1) FLINT_BITS (it's a macro in flint.h) > > > 2) sizeof(uint32_t) > > > 3) sizeof(uint16_t) > > > If the machine truly is running in 32 bit mode the values you get > > should be 32, 4 and 2. Only then will the FLINT tests pass. > > > If you get 64 for number (1) then uint64_t and uint32_t should be > > defined. In that case you should look at the values of > > > 1) FLINT_BITS > > > 2) sizeof(uint64_t) > > > 3) sizeof(uint32_t) > > > The values you should get in this case should be 64, 8, 4. Only then > > will the FLINT tests pass. > > I will dig into this in the next couple days, after I got ATLAS and > PolyBoRi merged. Please ping me in a week or so if nothing happens. > OK, all the info here should be correct, so I'll be interested to hear what you come up with. Essentially you just need a 5 line program which #includes flint.h and prints off the values above. I don't think I have access to SPARC32 myself. > > > > As for the quadratic sieve, yes it is included in FLINT 1.0, but is a > > completely new beast (and much faster). Simply make QS to build it. > > The program is called mpQS. It is fairly similar to the old > > QuadraticSieve program, and with any luck the output is formatted the > > same. > > > The program now *requires* that the input is not prime, is not a > > perfect power and has no small factors, i.e. you should remove all > > factors up to 1000 and run the elliptic curve method for a few rounds > > before calling the sieve. If you don't do this, mpQS will fail > > silently. Paul Zimmerman opened a ticket at SD6 explaining precisely > > how long to run GMP-ECM before running the quadratic sieve. I leave it > > up to you whether to sort this out now or keep the old sieve for now. > > There have been and will be no further changes to the old sieve so > > nothing needs changing if you want to stick with the old sieve until > > someone can sort out the trial factoring and ECM. > > Ok, that sounds great. I remember the ticket that Paul did and I > *should* work on that to actually learn something about mathematics > for once, but the way my current schedule look
[sage-devel] Re: request for testing: flint-1.0.spkg
On Dec 7, 10:21 am, Bill Hart <[EMAIL PROTECTED]> wrote: Bill, > Michael, if you want to fix the bug in the code you have in SAGE > without getting the new tarball tonight, simply replace the 64 with > FLINT_BITS on line 291 of fmpz_poly-test.c I will do that and see if the tests pass. > > I've checked that this bug is not a problem elsewhere in that file. > > Also you'll want to replace those handful of u_int64_t's with uint64_t > else you will have problems in itanium or AIX or whatever it is. > > Finally you'll want to grep for sys/types.h and replace with stdint.h > throughout FLINT. It should occur three or four times. > > Hlopefully fixing just these problems will make it compile out of the > box on your SPARC32. But I will wait for the 1.01 tarball to update the official FLINT.spkg, just to make sure that we ship vanilla releases in order to avoid deviations that makes updates harder. > > Bill Cheers, Michael --~--~-~--~~~---~--~~ 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] PDE toolbox
Hi, On Dec 7, 2007 6:50 AM, Joshua Kantor <[EMAIL PROTECTED]> wrote: > > I would be interested in helping with a PDE toolbox. I didn't want to > work on it alone as I'm pretty sure I'd make some stupid design > choices. It would be nice to start some work on PDE functionality in > SAGE. I would be very interested in this. Especially with finite elements solver. SciPy has some solvers, but even producing the element matrices would be enough. See also: http://groups.google.com/group/sympy/browse_thread/thread/f73b00d1bdf0255a http://groups.google.com/group/sympy/browse_thread/thread/6b8b4cbaa1914c45 and the project SymFe: http://code.google.com/p/symfe/ Basically, the way the equation is defined just need SAGE.calculus. But I would very much like this to be modular, so that we can use both maxima and sympy as a backend, so that I can use this in my own programs, because depending on the whole SAGE would be too much. However, it's a huge task. There are many related projects, mainly: http://www.fenics.org/wiki/FEniCS_Project http://www.fenics.org/wiki/SyFi But let's discuss at least the design. Let's use the same design as in: http://www.mathworks.com/products/pde/ or is there a better product out there? Ondrej --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
Michael, if you want to fix the bug in the code you have in SAGE without getting the new tarball tonight, simply replace the 64 with FLINT_BITS on line 291 of fmpz_poly-test.c I've checked that this bug is not a problem elsewhere in that file. Also you'll want to replace those handful of u_int64_t's with uint64_t else you will have problems in itanium or AIX or whatever it is. Finally you'll want to grep for sys/types.h and replace with stdint.h throughout FLINT. It should occur three or four times. Hlopefully fixing just these problems will make it compile out of the box on your SPARC32. Bill On Dec 7, 9:15 am, Bill Hart <[EMAIL PROTECTED]> wrote: > Ouch, the problem is solved. In fact this test will fail on *all* 32 > bit machines. There is a really silly bug in the test code itself. The > function it tests is most likely fine. > > So this is definitely a bug. I will issue FLINT 1.01 this evening, > fixing this and the other problems we've noted. > > Thanks for the reports. > > So for Solaris you have two options. Either you'll need to make the > gcc c99 compliant if it is not already, or you can #define uint16_t, > uint32_t and uint64_t. I don't think I use any intN_t types anywhere, > so you shouldn't need to define those. > > Bill. > > On Dec 7, 9:08 am, Bill Hart <[EMAIL PROTECTED]> wrote: > > > On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote: > > > > On my 32-bit x86 Debian testing Linux box, looking at install.log, one > > > test failed: > > > Testing _fmpz_poly_max_bits1()... FAIL! > > > (All other FLINT tests passed. The build is still running, so I don't > > > know whether Sage doctests will pass.) Let me know if you want more > > > information. > > > Hmm, this is an x86 machine. If it fails on this machine, I am now > > thinking I have a bug in the code rather than it being some kind of > > build problem. Perhaps this is what is happening on Michael's SPARC32. > > I better check my code. > > > The problem is more than likely going to be in the test code itself. > > I'll check it over with a fine tooth comb and see if I can find > > something wrong. > > > Bill. --~--~-~--~~~---~--~~ 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: having authors names in .py files
Also, I would add that these names are usually poorly maintained (at least for Sage) partly due to "the awkward question of how much work one must do to get one's own name listed there". Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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] having authors names in .py files
Hi, currrently *.py files in SAGE usually contain names who wrote them. The famous Karl Fogel's Producing Open Source Software discourages that: http://producingoss.com/en/managing-volunteers.html#territoriality mainly: People sometimes argue in favor of author or maintainer tags in source files on the grounds that this gives visible credit to those who have done the most work there. There are two problems with this argument. First, the tags inevitably raise the awkward question of how much work one must do to get one's own name listed there too. Second, they conflate the issue of credit with that of authority: having done work in the past does not imply ownership of the area where the work was done, but it's difficult if not impossible to avoid such an implication when individual names are listed at the tops of source files. In any case, credit information can already be obtained from the version control logs and other out-of-band mechanisms like mailing list archives, so no information is lost by banning it from the source files themselves. Ondrej --~--~-~--~~~---~--~~ 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: having authors names in .py files
On Dec 7, 2007 1:32 PM, David Joyner <[EMAIL PROTECTED]> wrote: > > I am certainly happy to share credit with anyone on any file I work on. > IMHO, anyone who does anything non-trivial has the write to put their > name on a xyz.py file, at least if they are happy to cede their copyright to > William Stein. In fact, for licensing issues, I would think it is useful to > know > who worked on which files. > If the concern is that it is hogging docstring real estate, then maybe > a new xyz.history file could be created which would have all this info in it? I think the idea of the OSS book (and also mine) is to use the Mercurial revision history for tracking who wrote each line. It's the psychology, for example when I modified the calculus.py, by adding a new function and a few lines, I don't feel I should add myself at the top of the file. When another 15 people like me are going to modify calculus.py, the authors will be quite misleading. The Mercurial nevertheless provides exact history who wrote what. Ondrej --~--~-~--~~~---~--~~ 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] quo_rem, __floordiv__, and polynomials
Hi, Here's a couple of questions that have occurred to me as I tried to make fraction fields of mpolynomials tolerable to work with. 1) In the "reduce" method in the file fraction_field_element.py (line 72), we call quo_rem to divide the gcd out of the numerator and denominator. Now, by definition the remainder should be 0 so we throw out the remainder. However, it seems to me that it should be faster to give the base_ring the information that we don't care about the remainder by using the "//" operator (which calls __floordiv__). 2) Ok, so I think #1 is obviously correct and I tried it to see if it made a speed difference. It did, but the wrong way -- __floordiv__ is slow for polynomial_integer_dense_ntl.pyx and the docstring explains that we don't know how this is defined. I'm not sure what David Harvey's exact questions are, but I think we should get it figured out. An obvious fact that I'd believe should hold is that: f.quo_rem(g)[0] == f//g That seems to remove any ambiguity. 3) What does quo_rem, __floordiv__ mean for mpolynomials? Magma's analog of __floordiv__ throws an error if the division doesn't come out exactly. I'm struggling to come up with an example, but it seems like the result of a __floordiv__ could be quite ambiguous at times. -- Joel --~--~-~--~~~---~--~~ 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: quo_rem, __floordiv__, and polynomials
On Dec 7, 2007, at 10:45 AM, Nick Alexander wrote: > >> If the divisor is monic, then everything is okay, but if the divisor >> is not monic, it's not clear what the remainder should be. I took the >> agnostic option for the moment. > > Why not make it agree with Magma's multivariate definition (used in > their Euclidean ring Groebner basis calculations)? > > The reference is > > http://magma.maths.usyd.edu.au/magma/htmlhelp/text1115.htm#11136 > > I can elaborate. For what it's worth, I have implemented some of > this in a .sage file but I couldn't make it very general -- the > polynomial hierarchy is hard to comprehend these days. Ok but if you do this, you need to implement it by hand, since NTL (the underlying implementation for most of Polynomial_integer_dense) isn't able to do this, as far as I know. david --~--~-~--~~~---~--~~ 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: PDE toolbox
On Dec 7, 2007, at 4:26 AM, Ondrej Certik wrote: > > Hi, > > On Dec 7, 2007 6:50 AM, Joshua Kantor <[EMAIL PROTECTED]> wrote: >> >> I would be interested in helping with a PDE toolbox. I didn't want to >> work on it alone as I'm pretty sure I'd make some stupid design >> choices. It would be nice to start some work on PDE functionality in >> SAGE. > > I would be very interested in this. Especially with finite elements > solver. SciPy has some solvers, but even producing the element > matrices would > be enough. > For variational problems, I've already written code in Maple to derive the element matrices. I presented a paper on in at the Maple 2005 Conference. Unfortunately, I've been having a difficult time translating some of the things I did from Maple to Sage. It was only for 1D problems (since that was all I needed), but it is modular enough to extend to others. The code derives the mass and stiffness matrices and then outputs them as MATLAB functions. I wrote the code because I needed something that can handle rotating flexible beams. > > > Basically, the way the equation is defined just need SAGE.calculus. > But I would very much like this to be modular, so that we can use both > maxima and sympy as a backend, so that I can use this in my own > programs, because depending on the whole SAGE would be too much. > > However, it's a huge task. There are many related projects, mainly: > > http://www.fenics.org/wiki/FEniCS_Project > http://www.fenics.org/wiki/SyFi I know about both of these, but I had never heard of the symfe work. Interesting, since my Maple toolbox is called SFEM. There is also a package for Maple called femLego: http://www.mech.kth.se/~gustava/femLego/ It's design is about solving the PDE once it has been derived. It uses Maple to write Fortran code, and compiles it with its own code. I nearly ended up using this, but see below. > But let's discuss at least the design. Let's use the same design as > in: > > http://www.mathworks.com/products/pde/ There are some problems with its design. It is basically an early version of FEMLAB, and it puts its focus strictly on solving PDEs once the formulation of the PDE has already been done. If a Ritz approach is used, the formulation of the PDE is never explicitly done and this design can't handle it. Plus, for systems with multiple coupled variables, the Galerkin approach becomes very complicated. I know because my SFEM package was originally an attempt to derive the weak form for use in FEMLAB. > > or is there a better product out there? > > Ondrej The difficulty is that most products seem to be trying to replace the major FE packages, but even those who do symbolic work, don't put any focus on the derivation. If one is going to use the weak formulation, this can be difficult. Tim. --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
Sounds sensible. I'll get to work on making that new tarball as soon as I get back from Real Job TM. In the meantime it would be great to hear if changing the u_int64_t's to uint64_t's and changing the #includes actually fixes it so it compiles out of the box on SPARC32. I think it probably should, since you seem to pick up a uint16_t from somewhere without defining it, so my thinking is that it probably is c99 compliant after all. Bill. On 7 Dec, 09:34, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > On Dec 7, 10:21 am, Bill Hart <[EMAIL PROTECTED]> wrote: > Bill, > > > Michael, if you want to fix the bug in the code you have in SAGE > > without getting the new tarball tonight, simply replace the 64 with > > FLINT_BITS on line 291 of fmpz_poly-test.c > > I will do that and see if the tests pass. > > > > > I've checked that this bug is not a problem elsewhere in that file. > > > Also you'll want to replace those handful of u_int64_t's with uint64_t > > else you will have problems in itanium or AIX or whatever it is. > > > Finally you'll want to grep for sys/types.h and replace with stdint.h > > throughout FLINT. It should occur three or four times. > > > Hlopefully fixing just these problems will make it compile out of the > > box on your SPARC32. > > But I will wait for the 1.01 tarball to update the official > FLINT.spkg, just to make sure that we ship vanilla releases in order > to avoid deviations that makes updates harder. > > > > > Bill > > > > Cheers, > > Michael --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote: > On my 32-bit x86 Debian testing Linux box, looking at install.log, one > test failed: > Testing _fmpz_poly_max_bits1()... FAIL! > (All other FLINT tests passed. The build is still running, so I don't > know whether Sage doctests will pass.) Let me know if you want more > information. Hmm, this is an x86 machine. If it fails on this machine, I am now thinking I have a bug in the code rather than it being some kind of build problem. Perhaps this is what is happening on Michael's SPARC32. I better check my code. The problem is more than likely going to be in the test code itself. I'll check it over with a fine tooth comb and see if I can find something wrong. Bill. --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
On Dec 7, 10:41 am, Bill Hart <[EMAIL PROTECTED]> wrote: > Sounds sensible. I'll get to work on making that new tarball as soon > as I get back from Real Job TM. > :) > In the meantime it would be great to hear if changing the u_int64_t's > to uint64_t's and changing the #includes actually fixes it so it > compiles out of the box on SPARC32. That doesn't work. The compiler doesn't use its own stdint.h instead. I have never figured out why. This doesn't matter to me any longer since after some IRC discussion with William we decided to move to Solaris 10 as primary dev platform for Sage on Solaris which does have a stdint.h :) > I think it probably should, since you seem to pick up a uint16_t from > somewhere without defining it, so my thinking is that it probably is > c99 compliant after all. Ahhh, in an ideal world those bugs would get fixed, but in reality we need to work around them. I spend a lot of my time on Sage fixing issues that aren't supposed to be there :) > Bill. With the FINT_BITS macro instead of "64" the test suite passes on that Sparc box. Cheers, Michael --~--~-~--~~~---~--~~ 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: quo_rem, __floordiv__, and polynomials
On Dec 7, 2007, at 8:48 AM, Joel B. Mohler wrote: > > Hi, > > Here's a couple of questions that have occurred to me as I tried to > make > fraction fields of mpolynomials tolerable to work with. > > 1) In the "reduce" method in the file fraction_field_element.py > (line 72), we > call quo_rem to divide the gcd out of the numerator and > denominator. Now, by > definition the remainder should be 0 so we throw out the > remainder. However, it > seems to me that it should be faster to give the base_ring the > information that > we don't care about the remainder by using the "//" operator (which > calls > __floordiv__). > > 2) Ok, so I think #1 is obviously correct and I tried it to see if > it made a > speed difference. It did, but the wrong way -- __floordiv__ is > slow for > polynomial_integer_dense_ntl.pyx and the docstring explains that we > don't know > how this is defined. I'm not sure what David Harvey's exact > questions are, but > I think we should get it figured out. An obvious fact that I'd > believe should > hold is that: > f.quo_rem(g)[0] == f//g > That seems to remove any ambiguity. I should mention that code is only several days old; it's the result of a bug-fix from the most recent bug days; it used to segfault on e.g. division by zero or division by a non-monic polynomial that didn't happen to be an exact divisor. If the divisor is monic, then everything is okay, but if the divisor is not monic, it's not clear what the remainder should be. I took the agnostic option for the moment. (BTW something that still needs to be fixed is that the code won't work if the leading coefficient is -1, which should work.) david --~--~-~--~~~---~--~~ 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: quo_rem, __floordiv__, and polynomials
> If the divisor is monic, then everything is okay, but if the divisor > is not monic, it's not clear what the remainder should be. I took the > agnostic option for the moment. Why not make it agree with Magma's multivariate definition (used in their Euclidean ring Groebner basis calculations)? The reference is http://magma.maths.usyd.edu.au/magma/htmlhelp/text1115.htm#11136 I can elaborate. For what it's worth, I have implemented some of this in a .sage file but I couldn't make it very general -- the polynomial hierarchy is hard to comprehend these days. 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] Re: matlab / toolbox replacements?
On Dec 7, 2007, at 1:15 AM, Fernando Perez wrote: > > You might want to have a look at the scipy sandbox. There's both a > multigrid and a spline package in there, in need of love and care. In > addition, the scipy.interpolate package (not in the sandbox, but in > the mainline) has had a FITPACK interface for basic splines for a long > time: > > """ > Interpolation Tools > === > > Wrappers around FITPACK functions: > > splrep-- find smoothing spline given (x,y) points on curve. > splprep -- find smoothing spline given parametrically > defined curve. > splev -- evaluate the spline or its derivatives. > splint-- compute definite integral of a spline. > sproot-- find the roots of a cubic spline. > spalde-- compute all derivatives of a spline at given > points. > bisplrep -- find bivariate smoothing spline representation. > bisplev -- evaluate bivariate smoothing spline. > > UnivariateSpline -- A more recent, object- > oriented wrapper; > finds a (possibly smoothed) > interpolating > spline. > InterpolatedUnivariateSpline > LSQUnivariateSpline > BivariateSpline -- A more recent, object- > oriented wrapper; > finds a interpolating spline > for a > bivariate function. > """ > > I have no idea of the state of spline/multigrid in the sandbox, but > they'd certainly be welcome contributions, and you'd probably find > others interested in helping in the scipy lists. > Thanks, I hadn't looked at that before. Unfortunately, it seems to do what a lot of the spline packages do which is hide the details. The names certainly seem to be the same as the SLATEC code and the spline toolbox, but it is missing a number of functions, especially those which work with the spline bases rather than the splines. There are also other fitting possibilities as deBoor describes in his book. Tim. --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
On Dec 7, 10:08 am, Bill Hart <[EMAIL PROTECTED]> wrote: > On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote: Bill, I will write that test program you asked for in the next couple hours. The sparc box is 64 bit, I am just compiling in 32 bit mode. If I find some time I will build in 64 bit mode, but then I need to build all dependencies in 64 bit, too, so that would take a while. > > > On my 32-bit x86 Debian testing Linux box, looking at install.log, one > > test failed: > > Testing _fmpz_poly_max_bits1()... FAIL! > > (All other FLINT tests passed. The build is still running, so I don't > > know whether Sage doctests will pass.) Let me know if you want more > > information. > > Hmm, this is an x86 machine. If it fails on this machine, I am now > thinking I have a bug in the code rather than it being some kind of > build problem. Perhaps this is what is happening on Michael's SPARC32. > I better check my code. > > The problem is more than likely going to be in the test code itself. > I'll check it over with a fine tooth comb and see if I can find > something wrong. > I believe so, too. Especially since we both had the failure with gcc 4.2.x. > Bill. Cheers, Michael --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
Ouch, the problem is solved. In fact this test will fail on *all* 32 bit machines. There is a really silly bug in the test code itself. The function it tests is most likely fine. So this is definitely a bug. I will issue FLINT 1.01 this evening, fixing this and the other problems we've noted. Thanks for the reports. So for Solaris you have two options. Either you'll need to make the gcc c99 compliant if it is not already, or you can #define uint16_t, uint32_t and uint64_t. I don't think I use any intN_t types anywhere, so you shouldn't need to define those. Bill. On Dec 7, 9:08 am, Bill Hart <[EMAIL PROTECTED]> wrote: > On Dec 7, 3:07 am, Carl Witty <[EMAIL PROTECTED]> wrote: > > > On my 32-bit x86 Debian testing Linux box, looking at install.log, one > > test failed: > > Testing _fmpz_poly_max_bits1()... FAIL! > > (All other FLINT tests passed. The build is still running, so I don't > > know whether Sage doctests will pass.) Let me know if you want more > > information. > > Hmm, this is an x86 machine. If it fails on this machine, I am now > thinking I have a bug in the code rather than it being some kind of > build problem. Perhaps this is what is happening on Michael's SPARC32. > I better check my code. > > The problem is more than likely going to be in the test code itself. > I'll check it over with a fine tooth comb and see if I can find > something wrong. > > Bill. --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
On 7 Dec, 03:07, Carl Witty <[EMAIL PROTECTED]> wrote: > On my 64-bit x86 Debian testing Linux box, running a prerelease of gcc > 4.3, compilation failed, because gcc 4.3 in "-std=c99" mode switches > to the standard meaning of inline, instead of the traditional gcc > meaning. I've posted a complete bug report as #1415. Carl, thanks for the report. This bug is quite possibly not in FLINT, but in GMP or even gcc itself. I use "static inline" throughout FLINT (earlier revisions did not, but I fixed this before FLINT 1.0) because the rules for "static inline" are the same in the c99 standard and in the gnuC "standard". I did also notice some posts online about problems in gcc 4.3 itself with this. So I don't know if they've all been fixed yet in the prerelease you have. Also, if I understand correctly, gcc 4.2 is supposed to warn me of any potential problems I'll have with inlines in 4.3, and nothing shows up. However I don't know why it doesn't warn about problems in GMP itself. I'm guessing this one will come out in the wash, so to speak. Bill. --~--~-~--~~~---~--~~ 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: having authors names in .py files
On Dec 7, 2007 9:50 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2007 1:32 PM, David Joyner <[EMAIL PROTECTED]> wrote: > > > > I am certainly happy to share credit with anyone on any file I work on. > > IMHO, anyone who does anything non-trivial has the write to put their > > name on a xyz.py file, at least if they are happy to cede their copyright to > > William Stein. In fact, for licensing issues, I would think it is useful to > > know > > who worked on which files. > > If the concern is that it is hogging docstring real estate, then maybe > > a new xyz.history file could be created which would have all this info in > > it? > > I think the idea of the OSS book (and also mine) is to use the > Mercurial revision history for tracking who wrote each line. > It's the psychology, for example when I modified the calculus.py, by > adding a new function and a few lines, I don't feel I should add > myself at the top of the file. When another 15 people like me are > going to modify calculus.py, the authors will be quite misleading. The > Mercurial nevertheless provides exact history who wrote what. I'm not an expert on mercurial, but I assumed that mercurial revision history is available to people using sage.math. What if Joe Shmoe decides to redistribute SAGE on www.cool-free-math-software.com? Will his version of SAGE also see who contributed to what? I personally would like to see this information in the distribution but maybe no one else does. > > Ondrej > > > > > --~--~-~--~~~---~--~~ 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] Scientific calculator in the notebook
I have been working on ways to make SAGE as easy to use as possible
for beginners because I am interested in encouraging high school
students to use SAGE. The approach I have been working on recently is
to embed a scientific calculator into the notebook that SAGE newbies
should be able to start using immediately with zero SAGE training.
The calculator is still at an early stage of development, but there is
enough running that people can start playing with it. Here is a
screenshot:
http://sage.math.washington.edu/home/tkosan/misc/mathrider_applet.png
And if people want to play with it, just open a worksheet in FireFox
and evaluate the following text in a cell:
html('http://sage.math.washington.edu/home/tkosan/mathrider/";
archive="mathrider.jar" MAYSCRIPT>')
At this point it only works in FireFox but hopefully it will
eventually work in IE too.
The Calculator, 2D plotter, and 3D plotter are not talking to the SAGE
server yet, but the text areas in the Cell tab are. Type something
simple like "m = 7" into the Send text area and press .
The code will be sent to the SAGE server for evaluation and a response
will be printed in the Receive text are. If one then goes to an empty
cell in the notebook and enters "print m", 7 will be printed.
At this point I am still trying to get my mind around the details of
the communications between the notebook and the server and I will
probably be asking questions about the communications protocol in the
near future.
Ted
--~--~-~--~~~---~--~~
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: having authors names in .py files
I am certainly happy to share credit with anyone on any file I work on. IMHO, anyone who does anything non-trivial has the write to put their name on a xyz.py file, at least if they are happy to cede their copyright to William Stein. In fact, for licensing issues, I would think it is useful to know who worked on which files. If the concern is that it is hogging docstring real estate, then maybe a new xyz.history file could be created which would have all this info in it? On Dec 7, 2007 6:26 AM, Martin Albrecht <[EMAIL PROTECTED]> wrote: > > Also, I would add that these names are usually poorly maintained (at least for > Sage) partly due to "the awkward question of how much work one must do to get > one's own name listed there". > > Martin > > > -- > name: Martin Albrecht > _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _www: http://www.informatik.uni-bremen.de/~malb > _jab: [EMAIL PROTECTED] > > > > > > --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
On Fri, 7 Dec 2007, Ted Kosan wrote: > > I have been working on ways to make SAGE as easy to use as possible > for beginners because I am interested in encouraging high school > students to use SAGE. The approach I have been working on recently is > to embed a scientific calculator into the notebook that SAGE newbies > should be able to start using immediately with zero SAGE training. +1 -- I've been wanting this feature for a while. > At this point I am still trying to get my mind around the details of > the communications between the notebook and the server and I will > probably be asking questions about the communications protocol in the > near future. I wrote most of the client-side communications stuff, and it is relatively easy to explain, so if you have any questions, feel free to send them my way. -- tom --~--~-~--~~~---~--~~ 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: Fwd: SAGE in University Week
It made it to the front page of Google News, via ScienceDaily! http://www.sciencedaily.com/releases/2007/12/071206145213.htm On Dec 6, 7:40 am, "William Stein" <[EMAIL PROTECTED]> wrote: > Hi, > > The local university magazine has a store about Sage at > >http://uwnews.org/uweek/uweekarticle.asp?articleID=38415 > > -- William > > I didn't write the article, but I've created a digg link to it: > >http://digg.com/software/Free_Open_Source_Mathematics_Software > > I think the only way this will be seen by people is if a bunch of you > visit the above link, become digg members (if not already) and moderate > the store up (or however it works). > > -- William > > -- Forwarded message -- > From: Selim Tuncel <[EMAIL PROTECTED]> > Date: Dec 5, 2007 10:17 PM > Subject: SAGE in University Week > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Dear Colleagues, > > Tomorrow's University Week will have an article about SAGE > featuring William Stein and a number of students. You can read the > article here: > > http://uwnews.org/uweek/uweekarticle.asp?articleID=38415 > > Selim > > -- > 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 [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: having authors names in .py files
> > > Again I strongly disagree with removing all the AUTHOR: blocks from > > > the Sage docstrings. The following is from the GPL v3: """ ... Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: * a) ... * b) Requiring preservation of specified reasonable legal notices or author attributions ... """ Disturbing discussions like this seriously make me consider adding some provision like this to at least the code I have contributed. If people were to start removing my name from software I have spent hard time writing, Sage would be down one developer. The example with graph.py is great, because in fact many code submissions Jason was making were coming in without names corresponding to the patches, simply because Jason was using a slightly different revision control program. If it weren't for his name in the code itself, it might not be there at all. Recall: we are not the borg. We all have names. What is the real objective here? I'd like to help develop the best math software in the world, and get credit for it. In the kind of job market many of us face, this is what differentiates different people vying for the same job. Ownership and credit are very different things. Tell me this- why are we so worried about owning something that is free, that anyone can change and distribute, and whose goal is to be available to everyone? -- Robert L. Miller --~--~-~--~~~---~--~~ 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: Let's involve SAGE in the Google Highly Open Participation Contest
Timothy wrote: > Just 8/9 minutes after sending my letter to Python GHOP two mentors > wrote back that they would love to have Sage tickets. In fact Titus > Brown says he has heard good things about Sage. > > http://groups.google.com/group/ghop-python/browse_thread/thread/247ff27b799d4c39 Wow, that was quick! It looks like your 11 hour investment of time paid off :-) I will try to send you some tickets this weekend which are related to adding problem solving examples to the Newbies book. Ted --~--~-~--~~~---~--~~ 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: Let's involve SAGE in the Google Highly Open Participation Contest
Just 8/9 minutes after sending my letter to Python GHOP two mentors wrote back that they would love to have Sage tickets. In fact Titus Brown says he has heard good things about Sage. http://groups.google.com/group/ghop-python/browse_thread/thread/247ff27b799d4c39 On Dec 6, 5:05 pm, "Ondrej Certik" <[EMAIL PROTECTED]> wrote: > > SAGE brought fair amount of people to Python, right? So I think it's > > perfectly suitable for PSF. > > I forgot to mention that Crunchy is also involved in that, so SAGE > notebook can be too. > > I mentioned SAGE notebook to Crunchy in May already. > > http://groups.google.com/group/crunchy-discuss/browse_thread/thread/2... > > So they must know about it. But SAGE is evolving very fast, so what I > wrote there is no longer true, now Crunchy seems slower than SAGE > notebook to me. > > I think SAGE is bringing dozens of completely new people to Python > (and numpy and scipy), that wouldn't use it otherwise, especially on > windows imho. So I think SAGE is a Python project in a way. > > Ondrej --~--~-~--~~~---~--~~ 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: Please review letter to Python GHOP
Thank you Jason, David, and Ted for your reviews. I made all the changes and sent the letter to the Python GHOP group. -- Dear Python's Project for the Google Highly Open Participation group, I am a 17 year old home schooled high school student in Seattle, Washington and contributor to a Python based open source mathematics software project called Sage (http://sagemath.org). Onrej Certik, creator of SymPy (http://sympy.org), suggested that the Sage project participate in this contest as a Python project. I think that is a wonderful idea because in the Sage project there are many of interesting and accessible problems to work on and numerous ways for pre-university students to contribute time. I would like to get Sage involved in the contest by introducing Sage, planning Sage involvement, and writing and supervising tickets. I do not want to be a contestant. Sage is a massive extension to Python for all kinds of mathematical computing. The goal of the Sage project is to develop an open source alternative to the math software Maple, Mathematica, MATLAB, and Magma. To achieve this goal in a reasonable amount of time, the Sage developers did not reinvent the wheel. Instead, the Sage project has produced a system with a wide range of functionality in less than three years by maintaining a distribution of the best available math software and writing a Python library that unifies the software and libraries and eliminates much of the complexity of many of these packages for the end users. Many people first started seriously using Python because of Sage. At every introductory talk on Sage, the advantages to using Python over other languages and its popularity are well emphasized. Thanks in great part to Python, Sage is an excellent system for teaching students about both math and computer science. Sage has a web environment called the Sage Notebook, and two free public notebook servers are available at http://sagenb.com and http://sagenb.org. A Sage worksheet is similar to a Mathematica notebook, and although it lacks many of the neat features of Crunchy, it does provide a fairly robust notebook system. Some of Sage's features include user accounts, worksheet sharing, tab completion, infinite loop survival, two and three dimensional graphics, interactive documentation, and public notebook security. The Sage Notebook is also an excellent platform for creating mathematical art. A good example of that is a worksheet called "New Found Spin" at https://sage.math.washington.edu:8102/home/pub/11/. Although most of the focus of Sage development is on aiding cutting edge mathematical research, Sage has good support for elementary algebra, geometry, trigonometry, and calculus. Also, some of Sage's upper level mathematics functionality is accessible to many high school and college students. For example, in the summer of 2006, under the direction of William Stein (lead developer of Sage) 24 talented high school students used Sage via the notebook in a computer lab to explore the congruent number problem and in the process were introduced to the Birch and Swinnerton-Dyer conjecture (http:// wstein.org/simuw06/). Then, in the next summer, another 24 students used Sage to comprehend Riemann's Hypothesis (http://wstein.org/ simuw/). I think that there are many ways that pre-university students can contribute to Sage. Timothy Clemans On Dec 7, 8:44 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote: > Timothy wrote: > > I have spent about 11 hours working on a letter to the Project, Google > > Highly Open Participation group to get Sage involved in that contest. > > William and Ondrej were very helpful and reviewed several drafts. > > Please review, ask questions and give comments? Thank you! > > I have included some editing thoughts below with deletions in red and > additions in green. I hope that the rich text mode worked and if not, let > me know and I will send you my suggestions in a separate document. > > Ted > > > > > Dear Python's Project for the Google Highly Open Participation group, > > > I am a 17 year old home schooled high school student in Seattle, > > Washington and contributor to a Python based open source mathematics > > software project called Sage (http://sagemath.org). Onrej Certik, > > creator of SymPy (http://sympy.org), suggested that the Sage project > > participate in this contest as a Python project. I think that is a > > wonderful idea because in the Sage project there are a lot of many > > interesting and accessible problems to work on and many numerous ways for > pre- > > university students to contribute time. I would like to get Sage > > involved in the contest by introducing Sage, planning Sage > > involvement, and writing and supervising tickets. I do not want to be > > a contestant. > > > Sage is a massive extension to Python for all kinds of mathematical > > computing. The goal of the Sage project is to develop an ope
[sage-devel] Please review letter to Python GHOP
Hi everyone, I have spent about 11 hours working on a letter to the Project, Google Highly Open Participation group to get Sage involved in that contest. William and Ondrej were very helpful and reviewed several drafts. Please review, ask questions and give comments? Thank you! - Dear Python's Project for the Google Highly Open Participation group, I am a 17 year old home schooled high school student in Seattle, Washington and contributor to a Python based open source mathematics software project called Sage (http://sagemath.org). Onrej Certik, creator of SymPy (http://sympy.org), suggested that the Sage project participate in this contest as a Python project. I think that is a wonderful idea because in the Sage project there are a lot of interesting and accessible problems to work on and many ways for pre- university students to contribute time. I would like to get Sage involved in the contest by introducing Sage, planning Sage involvement, and writing and supervising tickets. I do not want to be a contestant. Sage is a massive extension to Python for all kinds of mathematical computing. The goal of the Sage project is to develop an open source alternative to the math software Maple, Mathematica, MATLAB, and Magma. To achieve this goal in a reasonable about of time the Sage developers did not reinvent the wheel. Instead the Sage project has produced a system with a wide range of functionality in almost three years by maintaining a distribution of the best available math software and writing a Python library that unifies the software and libraries and eliminates much of the complexity of many of these packages for the end users. Many people first started seriously using Python because of Sage. At every introductory talk on Sage, the advantages to using Python over other languages and its popularity are well emphasized. Thanks in great part to Python, Sage is an excellent system for teaching students about both math and computer science. Sage has a web environment called the Sage Notebook, and two free public notebook servers are http://sagenb.com and http://sagenb.org. A Sage worksheet is similar to a Mathematica notebook and although it lacks many of the neat features of Crunchy it does provide a fairly robust notebook system. Some of the features of it are user accounts, worksheet sharing, tab completion, infinite loop survival, two and three dimensional graphics, interactive documentation, and public notebook security. The Sage Notebook is an excellent platform for creating mathematical art. A good example of that is a worksheet called "New Found Spin" at https://sage.math.washington.edu:8102/home/pub/11/. Although most of the focus of Sage development is on aiding cutting edge mathematical research, Sage has good support for elementary algebra, geometry, trigonometry, and calculus. Also some of Sage's upper level mathematics functionality is accessible to many high school and college students. For example in the summer of 2006, under the direction of William Stein, lead developer of Sage, 24 talented high school used Sage via the notebook in a computer lab to explore the congruent number problem and in the process were introducded to the Birch and Swinnerton-Dyer conjecture (http://wstein.org/simuw06/). Then in the next summer, another 24 students used Sage to comprehend Riemann's Hypothesis (http://wstein.org/simuw/). I think that there lots of ways pre-university students can contribute to Sage. Timothy Clemans --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
Carl wrote: > If the applet uses java.net.HTTPUrlConnection to talk to the server > from Java, it doesn't have to log in separately... the cookies from > the browser's login are automatically used by the Java > communications. At least, it works for me, and this document > indicates that it should be portable (unless we care about Netscape > 4 :): > http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/cookie_support.html I also experimented with using the AsyncHttpRequest class: http://swinglabs.org/hudson/job/SwingX-WS%20Continuous%20Build/javadoc/org/jdesktop/http/async/AsyncHttpRequest.html Currently, however, the applet is being served from a different server than the SAGE server it is communicating with. Doesn't this prevent it from contacting the SAGE server directly unless it is signed? Ted --~--~-~--~~~---~--~~ 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] a short Sage blog post at "Commence the Awesome"
Hi, See http://davestation.wordpress.com/2007/12/05/sage-math-software/ for a short Sage-related blog post by somebody.. -- William -- 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 [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: Scientific calculator in the notebook
On Dec 7, 12:46 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote: > William wrote: > > By the way, do you have any thoughts about technical communication > > issues with the server when using Java versus using Javascript to > > implement the scientific calculator. I think Ted's calculator client > > is a Java applet, > > which might impact how it would communicate with the Sage server. > > The applet uses JSObject to access the javascript environment of the > FireFox browser and it relies on the javascript notebook code in the > browser for all communications with the SAGE server: > > http://java.sun.com/products/plugin/1.3/docs/jsobject.html > > This approach worked well for eliminating the need for the applet to > log into the SAGE server and it automatically sets it inside the > context of an opened worksheet. If the applet uses java.net.HTTPUrlConnection to talk to the server from Java, it doesn't have to log in separately... the cookies from the browser's login are automatically used by the Java communications. At least, it works for me, and this document indicates that it should be portable (unless we care about Netscape 4 :): http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/cookie_support.html Carl --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
Ted Kosan wrote: > Nils wrote: > >> Scientific calculator programs already abound. > > What I like about a SAGE-based calculator is that it can be advertised > as being among the most powerful scientific calculators in the world. > People can be told that this calculator is like the wardrobe in the > Narnia series. When people use this calculator, its like falling into > a mathematical Narnia that is as rich and interesting as Narnia > itself. The other-worldly people who built the "calculator" (SAGE) > can be thought of as living inside of the calculator and anyone who > uses SAGE can enter that world and communicate with the world's > creators :-) > > > >> As a gentle >> introduction to sage, you might want to consider including a side- >> window where the sage commands that effect the same computation scroll >> by. That way, one could use it as a "scientific calculator-to-sage" >> translator and people might be able to pick up sage syntax while >> typing in on a familiar calculator. > > This is an excellent idea :-) > > My goal with this specific calculator is to change it into something > that progressively exposes SAGE functionality until the user has > evolved to the point of being an actual SAGE user. For example, I > would like to change the memory functionality so that the results of > calculations are saved in SAGE variables. I would also like to allow > the user to bind SAGE scripts to the unused buttons of the calculator. I like the direction you advocate (progessively exposing Sage). In middle and high school, I was introduced to a lot of math by reading my calculator manuals (well, at least it was a lot to me then!). Pressing a button on the calculator made me curious about what in the world standard deviation was, which led me to the manual, which fortunately listed the formula and a terse description of the quantities involved. Then I had to figure out the formula. Then came the "why?" questions. It was very exciting to me in a school that didn't teach calculus and had no real computer classes. But then again, I'm a geek :). But seriously, I think I would have loved learning about abstract algebra and category theory and graph theory, for example, if I had been exposed to Sage in high school. And I probably would have learned how to program in python then, instead of trying to wrap my head around C++! -Jason --~--~-~--~~~---~--~~ 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/Digg
Did you see the Wired Science blog post? http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html On Dec 7, 11:39 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 11:29 AM, Alfredo Portes <[EMAIL PROTECTED]> wrote: > > > Hi William, > > > I saw your post about the Digg submission. Somebody posted > > another one after yours, and I think it has a chance to make it > > to the frontpage. > > > http://digg.com/software/Free_software_brings_affordability_to_mathem... > > Awesome, thanks. I've put a link from my page to the above one. > > William --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
OK, flint-1.0.1 is available now at http://www.flintlib.org/ With any luck this fixes all the issues we've found. The only changes are the bug fixes and some corrections and omissions for the manual. Bill. On 7 Dec, 16:29, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > On Dec 7, 10:41 am, Bill Hart <[EMAIL PROTECTED]> wrote: > > > Sounds sensible. I'll get to work on making that new tarball as soon > > as I get back from Real Job TM. > > :) > > > In the meantime it would be great to hear if changing the u_int64_t's > > to uint64_t's and changing the #includes actually fixes it so it > > compiles out of the box on SPARC32. > > That doesn't work. The compiler doesn't use its own stdint.h instead. > I have never figured out why. This doesn't matter to me any longer > since after some IRC discussion with William we decided to move to > Solaris 10 as primary dev platform for Sage on Solaris which does have > a stdint.h :) > > > I think it probably should, since you seem to pick up a uint16_t from > > somewhere without defining it, so my thinking is that it probably is > > c99 compliant after all. > > Ahhh, in an ideal world those bugs would get fixed, but in reality we > need to work around them. I spend a lot of my time on Sage fixing > issues that aren't supposed to be there :) > > > Bill. > > With the FINT_BITS macro instead of "64" the test suite passes on that > Sparc box. > > Cheers, > > Michael > > --~--~-~--~~~---~--~~ 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: more SAGE publicity :-)
On Dec 7, 2007 4:02 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2007 12:58 PM, John Cremona <[EMAIL PROTECTED]> wrote: > > > > > > On 07/12/2007, William Stein <[EMAIL PROTECTED]> wrote: > > > > > > On Dec 7, 2007 11:29 AM, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote: > > > > > > > > On Fri, 7 Dec 2007, Yi Qiang wrote: > > > > > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > > > > > > > > > "A movement is afoot among some mathematicians in academia to make the > > > > > switch from expensive, closed-source calculation software to free, > > > > > open-source alternatives." > > > > > > > > Pretty cool. > > > > > > > > There should a wiki page which documents mention of SAGE in research > > > > (articles, books, etc.) and the media (newspapers, popular blogs). > > > > > > See > > > > > > http://sagemath.org/why.html > > > > > > > And also the similar page (where?) containing a list of mathematical > > research papers which menion Sage -- to which I think there will > > shortly be a new addition by David Harvey. > > > > [And while looking for taht page using the Sage search engine I > > discovered a paper by David Joyner which refers to a paper of my > > student Steve Wesemeyer -- small world!] > > That's here: > > http://sagemath.org/pub.html > > It really should be moved to a wiki! > > Could someone volunteer right now to move it to the wiki? I volunteer, but if someone to do it, I won't be disappointed! > > William > > > > > --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
Jason wrote:
> It looks like you're using the trick of asking Sage to evaluate some
> text using cell id -1. This is a hack right now, as cell ids are
> supposed to be nonnegative numbers. Currently, though, the output
> directories are created and the right .py file is created and sent to
> SAGE. Problems can crop up if you happen to have two requests going to
> Sage simultaneously (one request overwrites the other since they're both
> for cell -1). Also, Sage complains that cell -1 wasn't defined before
> sending the text to it. I think there may be other places in the code
> where the id is assumed to be nonnegative.
This is where I need to get my mind around the notebook code better.
What I am doing now is the following:
1) When the applet launches, it injects an applet_callback function
into the browser:
win = JSObject.getWindow(this);
win.eval("function applet_callback(status, response_text) {" +
"document.mathrider.response( status, response_text );"+
"}"
);
2) When the user enters code into the Send text area, the applet calls
the async_request function and gives the applet_callback function as
the callback (I have been experimenting with different values for
newcell and id to see what effect they have):
String code = sendTextArea.getText();
String encodedCode = URLEncoder.encode(code,"UTF8");
win.eval("async_request(worksheet_command('eval'),
applet_callback,
'newcell=1&id=11&input="+ encodedCode +"');");
3) The response method in the applet is called by the applet_callback
function to handle the response:
public void response( String status, String response_text )
{
receiveTextArea.append("\nStatus: " + status + " Response: " +
response_text + "\n");
}//end method.
Eventually, I see different parts of the applet communicating with the
server concurrently. To enable multiple concurrent submissions to the
server, I was thinking about maybe having response objects in the
applet handle the replies.
In light of this approach, I am going to have to study your
enhancement proposals further to better understand how they would
work.
Ted
--~--~-~--~~~---~--~~
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: more SAGE publicity :-)
On Dec 7, 2007 12:58 PM, John Cremona <[EMAIL PROTECTED]> wrote: > > > On 07/12/2007, William Stein <[EMAIL PROTECTED]> wrote: > > > > On Dec 7, 2007 11:29 AM, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, 7 Dec 2007, Yi Qiang wrote: > > > > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > > > > > > > "A movement is afoot among some mathematicians in academia to make the > > > > switch from expensive, closed-source calculation software to free, > > > > open-source alternatives." > > > > > > Pretty cool. > > > > > > There should a wiki page which documents mention of SAGE in research > > > (articles, books, etc.) and the media (newspapers, popular blogs). > > > > See > > > > http://sagemath.org/why.html > > > > And also the similar page (where?) containing a list of mathematical > research papers which menion Sage -- to which I think there will > shortly be a new addition by David Harvey. > > [And while looking for taht page using the Sage search engine I > discovered a paper by David Joyner which refers to a paper of my > student Steve Wesemeyer -- small world!] That's here: http://sagemath.org/pub.html It really should be moved to a wiki! Could someone volunteer right now to move it to the wiki? William --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
William wrote: > By the way, do you have any thoughts about technical communication > issues with the server when using Java versus using Javascript to > implement the scientific calculator. I think Ted's calculator client > is a Java applet, > which might impact how it would communicate with the Sage server. The applet uses JSObject to access the javascript environment of the FireFox browser and it relies on the javascript notebook code in the browser for all communications with the SAGE server: http://java.sun.com/products/plugin/1.3/docs/jsobject.html This approach worked well for eliminating the need for the applet to log into the SAGE server and it automatically sets it inside the context of an opened worksheet. JSObject also enables the applet to do things with the worksheet like bind a text area to a cell for enhanced editing capabilities (like syntax highlighting, search and replace, etc.). It can also inject javascript code into the browser as needed. On the javascript side, it can call the applet's public methods. > We should really really have a collection of simple example java applets that > communicate with a sage server, to explain how that can be done. As soon as we come up with a solid applet communications technique, I can help with this. Ted --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
On Dec 7, 2007 11:53 AM, Jason Grout <[EMAIL PROTECTED]> wrote:
>
>
> Ted Kosan wrote:
> > I have been working on ways to make SAGE as easy to use as possible
> > for beginners because I am interested in encouraging high school
> > students to use SAGE. The approach I have been working on recently is
> > to embed a scientific calculator into the notebook that SAGE newbies
> > should be able to start using immediately with zero SAGE training.
> >
> > The calculator is still at an early stage of development, but there is
> > enough running that people can start playing with it. Here is a
> > screenshot:
> >
> > http://sage.math.washington.edu/home/tkosan/misc/mathrider_applet.png
> >
> > And if people want to play with it, just open a worksheet in FireFox
> > and evaluate the following text in a cell:
> >
> > html(' > width="800" height="650"
> > codebase="http://sage.math.washington.edu/home/tkosan/mathrider/";
> > archive="mathrider.jar" MAYSCRIPT>')
> >
> > At this point it only works in FireFox but hopefully it will
> > eventually work in IE too.
> >
> > The Calculator, 2D plotter, and 3D plotter are not talking to the SAGE
> > server yet, but the text areas in the Cell tab are. Type something
> > simple like "m = 7" into the Send text area and press .
> > The code will be sent to the SAGE server for evaluation and a response
> > will be printed in the Receive text are. If one then goes to an empty
> > cell in the notebook and enters "print m", 7 will be printed.
> >
> > At this point I am still trying to get my mind around the details of
> > the communications between the notebook and the server and I will
> > probably be asking questions about the communications protocol in the
> > near future.
>
> Ted, I think this is fantastic.
>
> (Alex, William, or anyone else: I'd love to hear any corrections or
> insights you may have about what I've said below.)
>
> It looks like you're using the trick of asking Sage to evaluate some
> text using cell id -1. This is a hack right now, as cell ids are
> supposed to be nonnegative numbers. Currently, though, the output
> directories are created and the right .py file is created and sent to
> SAGE. Problems can crop up if you happen to have two requests going to
> Sage simultaneously (one request overwrites the other since they're both
> for cell -1). Also, Sage complains that cell -1 wasn't defined before
> sending the text to it. I think there may be other places in the code
> where the id is assumed to be nonnegative.
>
> That said, Sage actually does send back correct a response (if the cell
> hasn't been overwritten on a race condition).
>
> Here are two ideas to deal with the issue:
>
> 1. Have a namespace associated with each cell. Each namespace would
> correspond to a directory in the notebook directory, so that the cells
> in namespace "calculator" would be stored in "calculator/code/" and
> "calculator/data" directories. This would allow Ted to have his own
> private cell id space so that he can create virtually a notebook inside
> of the notebook, storing students' calculations in sort of a history
> interface.
>
> 2. Have a flag saying that the cell is a "virtual" cell and is sort of a
> one-off calculation. Any non-text results of the calculation are thrown
> away. I would find this useful in interactive widgets, where I just
> want to set the value of some variables based on some user interactions.
> I don't care about the non-text input and I don't want to keep track
> of cell ids. I just want to have Sage do a short calculation that
> affects the state of Sage and check the return value to see if there was
> an error.
>
>
> Also, it would be nice to allow for requests to be prioritized, so that,
> for example, Ted's calculator requests would always be queued right up,
> while some other calculations would have to wait their turn (and
> possibly be pushed back).
>
All I have to say is that these are both (1) excellent ideas and (2) probably
not difficult for me to implement.
Also, Nils idea to have an option to show how scientific calculator code is
translated to Sage is great!
Finally, it would be really cool to have similar scientific calculators, but for
special subject areas, e.g., graph theory, combinatorics, elliptic curves, etc.
These would rock.
-- William
--~--~-~--~~~---~--~~
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: Scientific calculator in the notebook
Ted Kosan wrote:
> I have been working on ways to make SAGE as easy to use as possible
> for beginners because I am interested in encouraging high school
> students to use SAGE. The approach I have been working on recently is
> to embed a scientific calculator into the notebook that SAGE newbies
> should be able to start using immediately with zero SAGE training.
>
> The calculator is still at an early stage of development, but there is
> enough running that people can start playing with it. Here is a
> screenshot:
>
> http://sage.math.washington.edu/home/tkosan/misc/mathrider_applet.png
>
> And if people want to play with it, just open a worksheet in FireFox
> and evaluate the following text in a cell:
>
> html(' width="800" height="650"
> codebase="http://sage.math.washington.edu/home/tkosan/mathrider/";
> archive="mathrider.jar" MAYSCRIPT>')
>
> At this point it only works in FireFox but hopefully it will
> eventually work in IE too.
>
> The Calculator, 2D plotter, and 3D plotter are not talking to the SAGE
> server yet, but the text areas in the Cell tab are. Type something
> simple like "m = 7" into the Send text area and press .
> The code will be sent to the SAGE server for evaluation and a response
> will be printed in the Receive text are. If one then goes to an empty
> cell in the notebook and enters "print m", 7 will be printed.
>
> At this point I am still trying to get my mind around the details of
> the communications between the notebook and the server and I will
> probably be asking questions about the communications protocol in the
> near future.
Ted, I think this is fantastic.
(Alex, William, or anyone else: I'd love to hear any corrections or
insights you may have about what I've said below.)
It looks like you're using the trick of asking Sage to evaluate some
text using cell id -1. This is a hack right now, as cell ids are
supposed to be nonnegative numbers. Currently, though, the output
directories are created and the right .py file is created and sent to
SAGE. Problems can crop up if you happen to have two requests going to
Sage simultaneously (one request overwrites the other since they're both
for cell -1). Also, Sage complains that cell -1 wasn't defined before
sending the text to it. I think there may be other places in the code
where the id is assumed to be nonnegative.
That said, Sage actually does send back correct a response (if the cell
hasn't been overwritten on a race condition).
Here are two ideas to deal with the issue:
1. Have a namespace associated with each cell. Each namespace would
correspond to a directory in the notebook directory, so that the cells
in namespace "calculator" would be stored in "calculator/code/" and
"calculator/data" directories. This would allow Ted to have his own
private cell id space so that he can create virtually a notebook inside
of the notebook, storing students' calculations in sort of a history
interface.
2. Have a flag saying that the cell is a "virtual" cell and is sort of a
one-off calculation. Any non-text results of the calculation are thrown
away. I would find this useful in interactive widgets, where I just
want to set the value of some variables based on some user interactions.
I don't care about the non-text input and I don't want to keep track
of cell ids. I just want to have Sage do a short calculation that
affects the state of Sage and check the return value to see if there was
an error.
Also, it would be nice to allow for requests to be prioritized, so that,
for example, Ted's calculator requests would always be queued right up,
while some other calculations would have to wait their turn (and
possibly be pushed back).
-Jason
--~--~-~--~~~---~--~~
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: Scientific calculator in the notebook
Scientific calculator programs already abound. As a gentle introduction to sage, you might want to consider including a side- window where the sage commands that effect the same computation scroll by. That way, one could use it as a "scientific calculator-to-sage" translator and people might be able to pick up sage syntax while typing in on a familiar calculator. By the way, my experience is that students don't necessarily know how to operate a standard scientific calculator anymore. They only use the superfancy graphing calculators. For instance, to calculate sin(1), they would actually type in [SIN] ( 1 ) [ENTER] or [SIN] 1 [ENTER] rather than 1 [SIN]. On Dec 7, 10:55 am, [EMAIL PROTECTED] wrote: > On Fri, 7 Dec 2007, Ted Kosan wrote: > > > I have been working on ways to make SAGE as easy to use as possible > > for beginners because I am interested in encouraging high school > > students to use SAGE. The approach I have been working on recently is > > to embed a scientific calculator into the notebook that SAGE newbies > > should be able to start using immediately with zero SAGE training. > > +1 -- I've been wanting this feature for a while. > > > At this point I am still trying to get my mind around the details of > > the communications between the notebook and the server and I will > > probably be asking questions about the communications protocol in the > > near future. > > I wrote most of the client-side communications stuff, and it is relatively > easy to explain, so if you have any questions, feel free to send them my way. > > -- tom --~--~-~--~~~---~--~~ 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: more SAGE publicity :-)
On Dec 7, 2007 11:12 AM, Yi Qiang <[EMAIL PROTECTED]> wrote: > > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > "A movement is afoot among some mathematicians in academia to make the > switch from expensive, closed-source calculation software to free, > open-source alternatives." Thanks! I just got off the phone with the Mike who wrote that blog post, and who might be writing an article for Wired on Sage. -- William --~--~-~--~~~---~--~~ 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: Let's involve SAGE in the Google Highly Open Participation Contest
Timothy Clemans wrote: > Just 8/9 minutes after sending my letter to Python GHOP two mentors > wrote back that they would love to have Sage tickets. In fact Titus > Brown says he has heard good things about Sage. > > http://groups.google.com/group/ghop-python/browse_thread/thread/247ff27b799d4c39 Wow, good job! It sounds like they're pretty excited about involving Sage. Jason --~--~-~--~~~---~--~~ 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: having authors names in .py files
> > Again I strongly disagree with removing all the AUTHOR: blocks from > > the Sage docstrings. I think doing this would > >(1) stupidly ignore a huge amount of what makes Sage work, > >(2) removes a valuable mechanism for getting a quick sense of > > who the main people are who consider themselves serious contributors > > to a file or function, > >(3) raises the barrier to *giving* people credit for their work. > >(4) completely goes contrary to the tradition in mathematics, where > > credit is everything -- which > > is why most mathematical objects are named after people (e.g., > > Bernoulli numbers, Tate curves, > > etc.). When some random mathematician, say, types > > sage: bernoulli_mod_p? > > I get > >... > > AUTHOR: > > -- David Harvey (2006-08-06) > >This tells me something very useful immediately - that there's a > > real specific > > person behind this code, maybe somebody I'll see at a conference soon and > > thank for their function, ask further questions about it, etc. etc. > > If as a random > > mathematician I had to rely on clicking around with Mercurial to get info > > like > > that it would never happen, and I probably wouldn't trust what I see > > anyways. > > > > I agree! I think I don't agree with this, but it's true that I am not doing mathematics. I think if someone devises something new, some new algorithm, or something, it's fine to put his name on it, but if it's just a code, I see it just as a code, nothing more. Clearly there are successful projects, like apache, that use this strategy (see that link I posted in my first email), so I don't think those people are stupid. I think both ways can work, so I just wanted to discuss this. I myself don't list my name in any functions or files I do, nor in SymPy or other projects. Mainly because I believe it's a work of many people and it's not fair to list just some. But anyway, I just wanted to know what you think about it. Ondrej --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
Nils wrote: > Scientific calculator programs already abound. What I like about a SAGE-based calculator is that it can be advertised as being among the most powerful scientific calculators in the world. People can be told that this calculator is like the wardrobe in the Narnia series. When people use this calculator, its like falling into a mathematical Narnia that is as rich and interesting as Narnia itself. The other-worldly people who built the "calculator" (SAGE) can be thought of as living inside of the calculator and anyone who uses SAGE can enter that world and communicate with the world's creators :-) > As a gentle > introduction to sage, you might want to consider including a side- > window where the sage commands that effect the same computation scroll > by. That way, one could use it as a "scientific calculator-to-sage" > translator and people might be able to pick up sage syntax while > typing in on a familiar calculator. This is an excellent idea :-) My goal with this specific calculator is to change it into something that progressively exposes SAGE functionality until the user has evolved to the point of being an actual SAGE user. For example, I would like to change the memory functionality so that the results of calculations are saved in SAGE variables. I would also like to allow the user to bind SAGE scripts to the unused buttons of the calculator. Ted --~--~-~--~~~---~--~~ 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: Please review letter to Python GHOP
Timothy wrote: > I have spent about 11 hours working on a letter to the Project, Google > Highly Open Participation group to get Sage involved in that contest. > William and Ondrej were very helpful and reviewed several drafts. > Please review, ask questions and give comments? Thank you! I have included some editing thoughts below with deletions in red and additions in green. I hope that the rich text mode worked and if not, let me know and I will send you my suggestions in a separate document. Ted > Dear Python's Project for the Google Highly Open Participation group, > > I am a 17 year old home schooled high school student in Seattle, > Washington and contributor to a Python based open source mathematics > software project called Sage (http://sagemath.org). Onrej Certik, > creator of SymPy (http://sympy.org), suggested that the Sage project > participate in this contest as a Python project. I think that is a > wonderful idea because in the Sage project there are a lot of many > interesting and accessible problems to work on and many numerous ways for pre- > university students to contribute time. I would like to get Sage > involved in the contest by introducing Sage, planning Sage > involvement, and writing and supervising tickets. I do not want to be > a contestant. > > Sage is a massive extension to Python for all kinds of mathematical > computing. The goal of the Sage project is to develop an open source > alternative to the math software Maple, Mathematica, MATLAB, and > Magma. To achieve this goal in a reasonable about amount of time, the Sage > developers did not reinvent the wheel. Instead, the Sage project has > produced a system with a wide range of functionality in almost less thanthree > years by maintaining a distribution of the best available math > software and writing a Python library that unifies the software and > libraries and eliminates much of the complexity of many of these > packages for the end users. > > Many people first started seriously using Python because of Sage. At > every introductory talk on Sage, the advantages to using Python over > other languages and its popularity are well emphasized. Thanks in > great part to Python, Sage is an excellent system for teaching > students about both math and computer science. > > Sage has a web environment called the Sage Notebook, and two free > public notebook servers are available at http://sagenb.com and http://sagenb.org. A > Sage worksheet is similar to a Mathematica notebook and, although it > lacks many of the neat features of Crunchy, it does provide a fairly > robust notebook system. Some of the features of it are Sage's features include user accounts, > worksheet sharing, tab completion, infinite loop survival, two and > three dimensional graphics, interactive documentation, and public > notebook security. > > The Sage Notebook is also an excellent platform for creating mathematical > art. A good example of that is a worksheet called "New Found Spin" at > https://sage.math.washington.edu:8102/home/pub/11/. > > Although most of the focus of Sage development is on aiding cutting > edge mathematical research, Sage has good support for elementary > algebra, geometry, trigonometry, and calculus. Also, some of Sage's > upper level mathematics functionality is accessible to many high > school and college students. For example, in the summer of 2006, (under > the direction of William Stein, lead developer of Sage), 24 talented > high school students used Sage via the notebook in a computer lab to explore > the congruent number problem and in the process were introducded introduced to > the Birch and Swinnerton-Dyer conjecture (http://wstein.org/simuw06/). > Then, in the next summer, another 24 students used Sage to comprehend > Riemann's Hypothesis (http://wstein.org/simuw/). > > I think that there lots of are many ways that pre-university students can contribute > to Sage. > > Timothy Clemans > > > --~--~-~--~~~---~--~~ 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: Please review letter to Python GHOP
typos: On Dec 7, 2007, at 11:01 PM, Timothy Clemans wrote: > Magma. To achieve this goal in a reasonable about of time the Sage => "amount of time" > the direction of William Stein, lead developer of Sage, 24 talented > high school used Sage via the notebook in a computer lab to explore => "high school students" david --~--~-~--~~~---~--~~ 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: Please review letter to Python GHOP
Timothy Clemans wrote: > Hi everyone, > > I have spent about 11 hours working on a letter to the Project, Google > Highly Open Participation group to get Sage involved in that contest. > William and Ondrej were very helpful and reviewed several drafts. > Please review, ask questions and give comments? Thank you! Two very minor typo corrections below... > > - > > Dear Python's Project for the Google Highly Open Participation group, > > I am a 17 year old home schooled high school student in Seattle, > Washington and contributor to a Python based open source mathematics > software project called Sage (http://sagemath.org). Onrej Certik, > creator of SymPy (http://sympy.org), suggested that the Sage project > participate in this contest as a Python project. I think that is a > wonderful idea because in the Sage project there are a lot of > interesting and accessible problems to work on and many ways for pre- > university students to contribute time. I would like to get Sage > involved in the contest by introducing Sage, planning Sage > involvement, and writing and supervising tickets. I do not want to be > a contestant. > > Sage is a massive extension to Python for all kinds of mathematical > computing. The goal of the Sage project is to develop an open source > alternative to the math software Maple, Mathematica, MATLAB, and > Magma. To achieve this goal in a reasonable about of time the Sage > developers did not reinvent the wheel. Instead the Sage project has > produced a system with a wide range of functionality in almost three > years by maintaining a distribution of the best available math > software and writing a Python library that unifies the software and > libraries and eliminates much of the complexity of many of these > packages for the end users. > > Many people first started seriously using Python because of Sage. At > every introductory talk on Sage, the advantages to using Python over > other languages and its popularity are well emphasized. Thanks in > great part to Python, Sage is an excellent system for teaching > students about both math and computer science. > > Sage has a web environment called the Sage Notebook, and two free > public notebook servers are http://sagenb.com and http://sagenb.org. A > Sage worksheet is similar to a Mathematica notebook and although it > lacks many of the neat features of Crunchy it does provide a fairly > robust notebook system. Some of the features of it are user accounts, > worksheet sharing, tab completion, infinite loop survival, two and > three dimensional graphics, interactive documentation, and public > notebook security. > > The Sage Notebook is an excellent platform for creating mathematical > art. A good example of that is a worksheet called "New Found Spin" at > https://sage.math.washington.edu:8102/home/pub/11/. > > Although most of the focus of Sage development is on aiding cutting > edge mathematical research, Sage has good support for elementary > algebra, geometry, trigonometry, and calculus. Also some of Sage's > upper level mathematics functionality is accessible to many high > school and college students. For example in the summer of 2006, under > the direction of William Stein, lead developer of Sage, 24 talented > high school used Sage via the notebook in a computer lab to explore You might change "high school used" to "high school students used". > the congruent number problem and in the process were introducded to > the Birch and Swinnerton-Dyer conjecture (http://wstein.org/simuw06/). > Then in the next summer, another 24 students used Sage to comprehend > Riemann's Hypothesis (http://wstein.org/simuw/). > > I think that there lots of ways pre-university students can contribute > to Sage. "that there lots of ways" -> "that there are lots of ways" (or "that there are many ways") > > Timothy Clemans Good luck! Jason --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
On Dec 7, 6:48 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote: > Carl wrote: > > If the applet uses java.net.HTTPUrlConnection to talk to the server > > from Java, it doesn't have to log in separately... the cookies from > > the browser's login are automatically used by the Java > > communications. At least, it works for me, and this document > > indicates that it should be portable (unless we care about Netscape > > 4 :): > > http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/cookie_support.html > > I also experimented with using the AsyncHttpRequest class: > > http://swinglabs.org/hudson/job/SwingX-WS%20Continuous%20Build/javadoc/org/jdesktop/http/async/AsyncHttpRequest.html > > Currently, however, the applet is being served from a different server > than the SAGE server it is communicating with. Doesn't this prevent > it from contacting the SAGE server directly unless it is signed? I was using an applet that was served by the Sage server. If you have a file $SAGE_ROOT/local/java/foo.jar, then it is available through the Sage server as https://localhost:8000/java/foo.jar (assuming default settings). Carl --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
William wrote: > Finally, it would be really cool to have similar scientific calculators, but > for > special subject areas, e.g., graph theory, combinatorics, elliptic curves, > etc. > These would rock. I have a couple of thoughts related to this. 1) Not only can the applet inject javascript code into the browser, but it can also inject SAGE code into a worksheet. When a given applet launches, it can automatically inject code into the SAGE environment on the server which can be used by the user to interact with the applet. For example, a graphing applet might inject an object called cgraph into the worksheet and then the user might type the following into a cell to view the graph on the applet: cgraph(x^2, 0, 10) cgraph will know how to communicate with the applet it came from and each applet can even have its own unique protocol using this "proxy object" technique With approach, the applet code will be very loosely coupled with the SAGE server code and applet development can occur without having to coordinate with the SAGE developers very much. 2) It should also be possible for the SAGE server to inject a data file into the applet that tells the applet what kind of GUI to create. Also, JavaSE comes with a javascript interpreter. Therefore, javascript can be injected into the applet from the server so people can create their own applets using Javascript and then the scripts can be saved in the notebook and used as needed. This might make it easier for people to create their own custom calculators and other applets. Ted --~--~-~--~~~---~--~~ 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: more SAGE publicity :-)
On 07/12/2007, William Stein <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2007 11:29 AM, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote: > > > > On Fri, 7 Dec 2007, Yi Qiang wrote: > > > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > > > > > "A movement is afoot among some mathematicians in academia to make the > > > switch from expensive, closed-source calculation software to free, > > > open-source alternatives." > > > > Pretty cool. > > > > There should a wiki page which documents mention of SAGE in research > > (articles, books, etc.) and the media (newspapers, popular blogs). > > See > > http://sagemath.org/why.html > And also the similar page (where?) containing a list of mathematical research papers which menion Sage -- to which I think there will shortly be a new addition by David Harvey. [And while looking for taht page using the Sage search engine I discovered a paper by David Joyner which refers to a paper of my student Steve Wesemeyer -- small world!] John > > > -- John Cremona --~--~-~--~~~---~--~~ 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: having authors names in .py files
On Dec 7, 2007 3:08 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > currrently *.py files in SAGE usually contain names who wrote them. > The famous Karl Fogel's Producing Open Source Software discourages > that: > > http://producingoss.com/en/managing-volunteers.html#territoriality > > mainly: > > People sometimes argue in favor of author or maintainer tags in source > files on the grounds that this gives visible credit to those who have > done the most work there. There are two problems with this argument. > First, the tags inevitably raise the awkward question of how much work > one must do to get one's own name listed there too. Second, they > conflate the issue of credit with that of authority: having done work > in the past does not imply ownership of the area where the work was > done, but it's difficult if not impossible to avoid such an > implication when individual names are listed at the tops of source > files. In any case, credit information can already be obtained from > the version control logs and other out-of-band mechanisms like mailing > list archives, so no information is lost by banning it from the source > files themselves. I agree with maybe 60% of producingoss.com and disagree with maybe 40% of that book, at least for Sage. The above is an example of some of the many things in that book that I disagree with (at least for Sage). > People sometimes argue in favor of author or maintainer tags in source > files on the grounds that this gives visible credit to those who have > done the most work there. I definitely argue that. > There are two problems with this argument. > First, the tags inevitably raise the awkward question of how much work > one must do to get one's own name listed there too. Just because something raises a question doesn't mean that something is a mistake to do!The answer in the case of Sage is that if a person feels they've done enough to explicitly list themselves in an AUTHOR block, e.g., for a function, for a file, whatever, then they've done enough. Full stop. By the way, a great example of a file that makes good use of the AUTHOR blocks is: http://www.sagemath.org/hg/sage-main/file/7110a20969c8/sage/rings/bernoulli_mod_p.pyx Finally, I have say that in mathematics research at least author credit is *everything*. It is by far the most important commodity there is. To argue for banning explicitly listing credits in places in code is frankly a very stupid waste of valuable gold. I've seen *precisely* this sort of thing be enforced with Magma in some cases, and it seriously aliented certain people, present company included. If somebody feels strongly enough to put AUTHOR: name (date) -- summary of what they did in a function docstring, then they deserve that right. > Second, they > conflate the issue of credit with that of authority: having done work > in the past does not imply ownership of the area where the work was > done, but it's difficult if not impossible to avoid such an > implication when individual names are listed at the tops of source > files. What's wrong with some implied ownership!? That's actually very very important. For example, to take a concrete situation, Robert Miller and Emily Kirkman spent a huge amount of time during the last year writing graph theory code. Their names are clearly listed in AUTHOR blocks at the tops of files. I've done some minor reorganization of docstrings and code, but definitely don't feel I should be listed -- it's their part of Sage. Now suppose some talented enthusiastic person, e.g., named Jason Grout, comes along and starts submitting patches all over the place for graph theory. It's clear what should happen -- Robert and Emily should get notified, get first dibs to referee, etc., until after a while Jason starts getting so confident he lists his name under AUTHOR, and he should be consulted too. Morever, "implied ownership" really isnt' an issue with Sage, beyond the basic respect it should entail, since the whole culture of the project is that anybody can work on any part of the system, as long as they _respectfully_ post patches, get them refereed etc. > In any case, credit information can already be obtained from > the version control logs and other out-of-band mechanisms like mailing > list archives, so no information is lost by banning it from the source > files themselves. There is a significant barrier to entry in getting credit information from version control logs, and they can be very misleading (e.g., in the case of moving chunks of code around). Again I strongly disagree with removing all the AUTHOR: blocks from the Sage docstrings. I think doing this would (1) stupidly ignore a huge amount of what makes Sage work, (2) removes a valuable mechanism for getting a quick sense of who the main people are who consider themselves serious contributors to a file or function, (3) raises the barrier to *giving* people credit for their work. (4) completely go
[sage-devel] Re: Scientific calculator in the notebook
On Dec 7, 2007 10:55 AM, <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, 7 Dec 2007, Ted Kosan wrote: > > > > > I have been working on ways to make SAGE as easy to use as possible > > for beginners because I am interested in encouraging high school > > students to use SAGE. The approach I have been working on recently is > > to embed a scientific calculator into the notebook that SAGE newbies > > should be able to start using immediately with zero SAGE training. > > +1 -- I've been wanting this feature for a while. > > > At this point I am still trying to get my mind around the details of > > the communications between the notebook and the server and I will > > probably be asking questions about the communications protocol in the > > near future. > > I wrote most of the client-side communications stuff, and it is relatively > easy to explain, so if you have any questions, feel free to send them my way. > > -- tom Tom, By the way, do you have any thoughts about technical communication issues with the server when using Java versus using Javascript to implement the scientific calculator. I think Ted's calculator client is a Java applet, which might impact how it would communicate with the Sage server. We should really really have a collection of simple example java applets that communicate with a sage server, to explain how that can be done. William --~--~-~--~~~---~--~~ 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] more SAGE publicity :-)
http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html "A movement is afoot among some mathematicians in academia to make the switch from expensive, closed-source calculation software to free, open-source alternatives." Cheers, Yi --~--~-~--~~~---~--~~ 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: request for testing: flint-1.0.spkg
On Dec 7, 5:51 am, Bill Hart <[EMAIL PROTECTED]> wrote: > This bug is quite possibly not in FLINT, but in GMP or even gcc > itself. I use "static inline" throughout FLINT (earlier revisions did > not, but I fixed this before FLINT 1.0) because the rules for "static > inline" are the same in the c99 standard and in the gnuC "standard". > > I did also notice some posts online about problems in gcc 4.3 itself > with this. So I don't know if they've all been fixed yet in the > prerelease you have. > > Also, if I understand correctly, gcc 4.2 is supposed to warn me of any > potential problems I'll have with inlines in 4.3, and nothing shows > up. However I don't know why it doesn't warn about problems in GMP > itself. When I compile FLINT 1.0 (as part of 2.9.alpha1) on my 32-bit Debian x86, with: gcc version 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) I do get warnings. Here's a small, representative chunk of install.log: gcc -std=c99 -I/home/cwitty/sage-2.9.alpha1/local/include/ -fPIC - funroll-loops -O3 -c mpn_extras.c -o mpn_extras.o In file included from mpn_extras.c:33: /home/cwitty/sage-2.9.alpha1/local/include/gmp.h:1600: warning: C99 inline functions are not supported; using GNU89 /home/cwitty/sage-2.9.alpha1/local/include/gmp.h:1600: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute /home/cwitty/sage-2.9.alpha1/local/include/gmp.h:1626: warning: C99 inline functions are not supported; using GNU89 /home/cwitty/sage-2.9.alpha1/local/include/gmp.h:1637: warning: C99 inline functions are not supported; using GNU89 So that does point to the actual problem being with GMP. Carl --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
On Dec 7, 2:23 pm, "Ted Kosan" <[EMAIL PROTECTED]> wrote: > 1) Not only can the applet inject javascript code into the browser, > but it can also inject SAGE code into a worksheet. When a given > applet launches, it can automatically inject code into the SAGE > environment on the server which can be used by the user to interact > with the applet. That would have excellent applications in other contexts too. There are some tasks that are more conveniently done interactively: Pick a viewpoint for a 3d picture, select the viewport for a graph, select colors in a graph, etc. Each of those options can be set on the commandline too. It would be wonderful to have applets that let you select these things and then give you back the command line for later use (so that you can generate the picture through another toolchain that produces a print-quality version, for instance, or inside a script that generates many similar graphs which need the same parameters set). If the interactive tools always have the option of "giving back" to the command line, you would really have the best of both worlds. --~--~-~--~~~---~--~~ 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: more SAGE publicity :-)
On Dec 7, 2007 11:29 AM, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote: > > On Fri, 7 Dec 2007, Yi Qiang wrote: > > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > > > "A movement is afoot among some mathematicians in academia to make the > > switch from expensive, closed-source calculation software to free, > > open-source alternatives." > > Pretty cool. > > There should a wiki page which documents mention of SAGE in research > (articles, books, etc.) and the media (newspapers, popular blogs). See http://sagemath.org/why.html --~--~-~--~~~---~--~~ 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/Digg
On Dec 7, 2007 11:29 AM, Alfredo Portes <[EMAIL PROTECTED]> wrote: > Hi William, > > I saw your post about the Digg submission. Somebody posted > another one after yours, and I think it has a chance to make it > to the frontpage. > > http://digg.com/software/Free_software_brings_affordability_to_mathematics Awesome, thanks. I've put a link from my page to the above one. William --~--~-~--~~~---~--~~ 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: more SAGE publicity :-)
On Fri, 7 Dec 2007, Yi Qiang wrote: > http://blog.wired.com/monkeybites/2007/12/math-geek-softw.html > > "A movement is afoot among some mathematicians in academia to make the > switch from expensive, closed-source calculation software to free, > open-source alternatives." Pretty cool. There should a wiki page which documents mention of SAGE in research (articles, books, etc.) and the media (newspapers, popular blogs). Regards, Ifti --~--~-~--~~~---~--~~ 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: Scientific calculator in the notebook
Jason Grout wrote: > > Ted, I think this is fantastic. > > (Alex, William, or anyone else: I'd love to hear any corrections or > insights you may have about what I've said below.) I meant to say "Tom, Alex, William, or anyone else:" Thanks, Tom, for your offer of help to us trying to understand the notebook. -Jason --~--~-~--~~~---~--~~ 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: having authors names in .py files
On 07/12/2007, William Stein <[EMAIL PROTECTED]> wrote: > > On Dec 7, 2007 3:08 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > currrently *.py files in SAGE usually contain names who wrote them. > > The famous Karl Fogel's Producing Open Source Software discourages > > that: > > > > http://producingoss.com/en/managing-volunteers.html#territoriality > > > > mainly: > > > > People sometimes argue in favor of author or maintainer tags in source > > files on the grounds that this gives visible credit to those who have > > done the most work there. There are two problems with this argument. > > First, the tags inevitably raise the awkward question of how much work > > one must do to get one's own name listed there too. Second, they > > conflate the issue of credit with that of authority: having done work > > in the past does not imply ownership of the area where the work was > > done, but it's difficult if not impossible to avoid such an > > implication when individual names are listed at the tops of source > > files. In any case, credit information can already be obtained from > > the version control logs and other out-of-band mechanisms like mailing > > list archives, so no information is lost by banning it from the source > > files themselves. > > I agree with maybe 60% of producingoss.com and disagree with maybe > 40% of that book, at least for Sage. The above is an example of some > of the many things in that book that I disagree with (at least for Sage). > > > People sometimes argue in favor of author or maintainer tags in source > > files on the grounds that this gives visible credit to those who have > > done the most work there. > > I definitely argue that. > > > There are two problems with this argument. > > First, the tags inevitably raise the awkward question of how much work > > one must do to get one's own name listed there too. > > Just because something raises a question doesn't mean that something > is a mistake to do!The answer in the case of Sage is that if a person > feels they've done enough to explicitly list themselves in an AUTHOR block, > e.g., for a function, for a file, whatever, then they've done enough. Full > stop. > > By the way, a great example of a file that makes good use of the AUTHOR > blocks is: > > http://www.sagemath.org/hg/sage-main/file/7110a20969c8/sage/rings/bernoulli_mod_p.pyx > > Finally, I have say that in mathematics research at least author > credit is *everything*. > It is by far the most important commodity there is. To argue for > banning explicitly > listing credits in places in code is frankly a very stupid waste of > valuable gold. > I've seen *precisely* this sort of thing be enforced with Magma in some cases, > and it seriously aliented certain people, present company included. > If somebody > feels strongly enough to put > >AUTHOR: >name (date) -- summary of what they did > > in a function docstring, then they deserve that right. > > > Second, they > > conflate the issue of credit with that of authority: having done work > > in the past does not imply ownership of the area where the work was > > done, but it's difficult if not impossible to avoid such an > > implication when individual names are listed at the tops of source > > files. > > What's wrong with some implied ownership!? That's actually > very very important. For example, to take a concrete situation, Robert > Miller and Emily Kirkman spent a huge amount of time during the last > year writing graph theory code. Their names are clearly listed in > AUTHOR blocks at the tops of files. I've done some minor reorganization > of docstrings and code, but definitely don't feel I should be listed -- it's > their part of Sage. Now suppose some talented enthusiastic person, e.g., > named Jason Grout, comes along and starts submitting patches all over > the place for > graph theory. It's clear what should happen -- Robert and Emily should get > notified, get first dibs to referee, etc., until after a while Jason > starts getting > so confident he lists his name under AUTHOR, and he should be consulted > too. > > Morever, "implied ownership" really isnt' an issue with Sage, beyond the > basic respect it should entail, since the whole > culture of the project is that anybody can work on any part of the system, as > long as they _respectfully_ post patches, get them refereed etc. > > > In any case, credit information can already be obtained from > > the version control logs and other out-of-band mechanisms like mailing > > list archives, so no information is lost by banning it from the source > > files themselves. > > There is a significant barrier to entry in getting credit information from > version control logs, and they can be very misleading (e.g., in the case > of moving chunks of code around). > > Again I strongly disagree with removing all the AUTHOR: blocks from > the Sage docstrings. I think doing this would >(1) stupidly ignore a huge amount of what makes Sage wor
