[sage-devel] Re: predefined symbolic variable names
Nick wrote: I use RR(expr) and find it at least as usable as the N[expr] notation of Mathematica. and William wrote: We should learn a lot about how Mathematica/Maple, etc., work, and why, but then make a _choice_ for SAGE that is a reasonable trade-off between various options. Python is flexible enough that individual users can always create such customizations for themselves. For example, people who like N being make it numeric might just put this in their .sage/init.sage file: I don't have a preference for the name N over the name RR just because this is what Mathematica uses :-) I have been using the numerical_approx method over using RR(expr) mainly because I am trying to emulate the way I found myself using //N in Mathmatica ( I used //N much more than the N[] function). When doing a multi-step calculation, I wanted to keep the results symbolic as much as possible, but I also wanted to take frequent quick peeks at the numerical approximates of these results in order to determine if they were reasonable or not. So, I would place a quick //N at the end of the result I received, take a look at its numerical approximate, and then erase the //N and move to the next step. Since //N is placed at the end of a line, it was easy to put there and easy to erase. I have found myself using numerical_approx() instead of RR() because it is also placed at the end of the line and so is relatively easy to locate the cursor there and add it. With RR(), one has to wrap the code in a function and then unwrap it when finished, which I have found takes more time (and is more error prone) than just having to deal with code that is all at the end of a line. My main complaint with numerical_approx so far is that it is a lot of typing when used for taking quick peeks at the numerical approximate of a symbolic expression. I am thinking that a shorter method name, perhaps .RR() to keep it in sync with the existing RR(expr), would be helpful :-) 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: predefined symbolic variable names
On 7/10/07, Ted Kosan [EMAIL PROTECTED] wrote: I have found myself using numerical_approx() instead of RR() because it is also placed at the end of the line and so is relatively easy to locate the cursor there and add it. With RR(), one has to wrap the code in a function and then unwrap it when finished, which I have found takes more time (and is more error prone) than just having to deal with code that is all at the end of a line. My main complaint with numerical_approx so far is that it is a lot of typing when used for taking quick peeks at the numerical approximate of a symbolic expression. I am thinking that a shorter method name, perhaps .RR().. I would be happy to introduce a short-cut alias for numerical_approx, e.g., N() or n() or ??. You can try out a few by doing this: sage: import sage.calculus.calculus sage: sage.calculus.calculus.SymbolicExpression.N = sage.calculus.calculus.SymbolicExpression.numerical_approx # all one line sage: a = sin(2) + pi + cos(2/3) sage: a.N() 4.83677734119242 Something simple like a.N() might be quite reasonable as a shortcut for a.numerical_approx(), and would be very simple to implement (just one line of code in an appropriate place). Thoughts? 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: predefined symbolic variable names
On Tue, Jul 10, 2007 at 02:54:31PM -0700, William Stein wrote: On 7/10/07, David Harvey [EMAIL PROTECTED] wrote: I don't really like the idea of modules that imitate various environments, i.e. I don't think it's possible or desirable for us to try to look specifically like any other system. Mathematica semantics are so different from SAGE's, it would be misleading to suggest anything like that. I agree completely with this. We should learn a lot about how Mathematica/Maple, etc., work, and why, but then make a _choice_ for SAGE that is a reasonable trade-off between various options. Python is flexible enough that individual users can always create such customizations for themselves. For example, people who like N being make it numeric might just put this in their .sage/init.sage file: I think the init file idea needs to be pushed harder. I already do this and the flexibility is absolutely critical to my happiness. I even have my init file call another file in the current directory so I can have different things defined depending on which project I'm working on (Of course, that idea doesn't have much merit from the notebook). We could publish init files for various CAS's. I realize we can't match semantics, but for myself I don't think the semantics are the hard part -- the hard part is remembering the new function name. We could also publish init files for various branches of mathematics -- applied, number theory, etc. I realize this could lead to support questions when people do dumb things in their init file, but I think it is easily worth to publish this huge amount of flexibility. -- 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: predefined symbolic variable names
On 7/11/07, Joel B. Mohler [EMAIL PROTECTED] wrote: I think the init file idea needs to be pushed harder. I already do this and the flexibility is absolutely critical to my happiness. I even have my init file call another file in the current directory so I can have different things defined depending on which project I'm working on (Of course, that idea doesn't have much merit from the notebook). We could publish init files for various CAS's. I realize we can't match semantics, but for myself I don't think the semantics are the hard part -- the hard part is remembering the new function name. We could also publish init files for various branches of mathematics -- applied, number theory, etc. I realize this could lead to support questions when people do dumb things in their init file, but I think it is easily worth to publish this huge amount of flexibility. I think this is definitely worth a try, and will probably be pretty fun to do. It may or may not be successful (e.g., if you type foo? the examples could easily fail because of how you customized your session -- this could be very bad). It would make sense to do something like this at least for the following systems, in order of priority: 1. mathematica 2. matlab 3. maple 4. magma 5. pari 6. gap For some of these, it is hard to think of where to begin, since there are thousands of commands (e.g., matlab has over 8000 commands). One could begin by creating a mathematica.sage that defines common commands like Integrate Sin Cos Derivative (?) N etc., with the case conventions of mathematica. This file could look like: Integrate = integrate Sin = sin Cos = cos ... N = RDF# or something more sophisticated?? I.e., take number of digits as input... ... Thoughts? Volunteers? 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] Where are the up-to-date spkgs?
Hi, I now have someone here at my company that is going to help maintain spkgs. We have a number of spkgs that i) SAGE currently doesn't have and ii) SAGE does have but we have updated or added bug fixes. A while back there was agreement on a new standard format for what the structure of an spkg is. didier converted the existing SAGE spkgs to this new format and created .hg directories for each and posted them here: http://sage.math.washington.edu/home/dfdeshom/custom/spkg/ First question: are these spkgs being maintained as the most up-to-date versions? If not, where can we find the current spkgs that have the .hg directories. We are going to clone these and begin incorporating our changes to the existing spkgs. We will post the resulting spkgs on sage.math where our changes can be pulled back into the master copies. We will also put spkgs that SAGE doesn't on sage.math (in the new format with .hg directories). Brian --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
I would be willing to chip in some effort on the mathematica.sage file, although not in the very near future. I plan to begin migrating my undergraduate courses to sage from mathematica for fall semester 2008. I hope to convince other faculty do to the same, but it won't be easy. I am mainly interested in the mathematica.sage effort as a way to make it easier for my colleagues to port their labs to sage. -Marshall On Jul 11, 1:32 pm, William Stein [EMAIL PROTECTED] wrote: On 7/11/07, Joel B. Mohler [EMAIL PROTECTED] wrote: I think the init file idea needs to be pushed harder. I already do this and the flexibility is absolutely critical to my happiness. I even have my init file call another file in the current directory so I can have different things defined depending on which project I'm working on (Of course, that idea doesn't have much merit from the notebook). We could publish init files for various CAS's. I realize we can't match semantics, but for myself I don't think the semantics are the hard part -- the hard part is remembering the new function name. We could also publish init files for various branches of mathematics -- applied, number theory, etc. I realize this could lead to support questions when people do dumb things in their init file, but I think it is easily worth to publish this huge amount of flexibility. I think this is definitely worth a try, and will probably be pretty fun to do. It may or may not be successful (e.g., if you type foo? the examples could easily fail because of how you customized your session -- this could be very bad). It would make sense to do something like this at least for the following systems, in order of priority: 1. mathematica 2. matlab 3. maple 4. magma 5. pari 6. gap For some of these, it is hard to think of where to begin, since there are thousands of commands (e.g., matlab has over 8000 commands). One could begin by creating a mathematica.sage that defines common commands like Integrate Sin Cos Derivative (?) N etc., with the case conventions of mathematica. This file could look like: Integrate = integrate Sin = sin Cos = cos ... N = RDF# or something more sophisticated?? I.e., take number of digits as input... ... Thoughts? Volunteers? 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: Where are the up-to-date spkgs?
On 7/11/07, Brian Granger [EMAIL PROTECTED] wrote: I now have someone here at my company that is going to help maintain spkgs. We have a number of spkgs that i) SAGE currently doesn't have and ii) SAGE does have but we have updated or added bug fixes. A while back there was agreement on a new standard format for what the structure of an spkg is. didier converted the existing SAGE spkgs to this new format and created .hg directories for each and posted them here: http://sage.math.washington.edu/home/dfdeshom/custom/spkg/ First question: are these spkgs being maintained as the most up-to-date versions? If not, where can we find the current spkgs that have the .hg directories. We are going to clone these and begin incorporating our changes to the existing spkgs. We will post the resulting spkgs on sage.math where our changes can be pulled back into the master copies. We will also put spkgs that SAGE doesn't on sage.math (in the new format with .hg directories). Hi, I got swamped by teaching, SAGE Days 4, SIMUW, and... buying a house this week (!), so I haven't been able to move anything forward. Fortunately, I have no formal responsibilities for the next two months, so a lot is likely to happen in the near future. My plan is to start working on Friday very hard on making a release of SAGE-2.7. I anticipate this will take less than 2 days. SAGE-2.7 will include scipy as a *standard* package (and will require gfortran as a dependency on linux, and install gfortran on os x). In order to get this release out in a timely fashion, my plan is to use the existing spkg's, i.e., not switch to the versions that Didier created, since that would add a lot of extra time, and delay a much-needed release that is basically ready to go. Then as soon as SAGE-2.7 is released, the next goal will be to make another release, e.g., SAGE-2.7.1, where the main change will be moving to the new package structure. In summary: 1. Monday, July 16: Release SAGE-2.7 2. Friday, July 20: Release SAGE-2.7.1, which is SAGE-2.7.1, but with the package system reworked, and the build issues with lots of people installing scipy that will undoubtedly arise mostly fixed. What do you think? The src subdirectory here: http://modular.math.washington.edu/home/was/sage2.7/ has the latest version of my versions of packages. Most of the new work in SAGE-2.7 involves the fortran package, the scipy package, the lapack package, and changes to the standard SAGE Python library code. On many test systems it all does build and work together now. It doesn't work on powerpc OS X, but we've figured out how to fix that. -- 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: predefined symbolic variable names
On 7/11/07, Hamptonio [EMAIL PROTECTED] wrote: I would be willing to chip in some effort on the mathematica.sage file, although not in the very near future. I plan to begin migrating my undergraduate courses to sage from mathematica for fall semester 2008. I hope to convince other faculty do to the same, but it won't be easy. I am mainly interested in the mathematica.sage effort as a way to make it easier for my colleagues to port their labs to sage. Thanks! Let me know what happens. And definitely feel free to post a list of the reasons migrating from Mathematica to SAGE definitely won't be easy. Obviously, bad 3d graphics support is one reason, but I would love to hear about any and all other reasons as they arise. I want to be as aware as possible about them, so we have some hope of addressing as soon as possible. -- 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: predefined symbolic variable names
Well the biggest reason is just inertia: my department has been using mathematica for years, and everyone has a full set of computer labs and handouts and demos already done in mathematica. Why learn a new system and have to port everything over? We don't even directly pay for the license as a department, as far as I know, so there just isn't much motivation to change. My biggest selling points for sage are that the students can get it for their own computers for free, and I can set up a server so they can access it online. So realistically, I expect no one else will want to use sage in fall 2008. But if I get good feedback from students, and offer to help port mathematica labs to sage, maybe I can win some folks over. Incidentally, this is one reason I think it is crucial to get an R interface for sage ASAP. I think I could convince our stats faculty to give sage a try if it had R, and then I could argue that we should use sage for consistency across the department; it would also start exposing our grad students to sage. -Marshall On Jul 11, 2:38 pm, William Stein [EMAIL PROTECTED] wrote: On 7/11/07, Hamptonio [EMAIL PROTECTED] wrote: I would be willing to chip in some effort on the mathematica.sage file, although not in the very near future. I plan to begin migrating my undergraduate courses to sage from mathematica for fall semester 2008. I hope to convince other faculty do to the same, but it won't be easy. I am mainly interested in the mathematica.sage effort as a way to make it easier for my colleagues to port their labs to sage. Thanks! Let me know what happens. And definitely feel free to post a list of the reasons migrating from Mathematica to SAGE definitely won't be easy. Obviously, bad 3d graphics support is one reason, but I would love to hear about any and all other reasons as they arise. I want to be as aware as possible about them, so we have some hope of addressing as soon as possible. -- 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: Where are the up-to-date spkgs?
I got swamped by teaching, SAGE Days 4, SIMUW, and... buying a house this week (!), so I haven't been able to move anything forward. Fortunately, I have no formal responsibilities for the next two months, so a lot is likely to happen in the near future. Nice! My plan is to start working on Friday very hard on making a release of SAGE-2.7. I anticipate this will take less than 2 days. SAGE-2.7 will include scipy as a *standard* package (and will require gfortran as a dependency on linux, and install gfortran on os x). In order to get this release out in a timely fashion, my plan is to use the existing spkg's, i.e., not switch to the versions that Didier created, since that would add a lot of extra time, and delay a much-needed release that is basically ready to go. Then as soon as SAGE-2.7 is released, the next goal will be to make another release, e.g., SAGE-2.7.1, where the main change will be moving to the new package structure. In summary: 1. Monday, July 16: Release SAGE-2.7 2. Friday, July 20: Release SAGE-2.7.1, which is SAGE-2.7.1, but with the package system reworked, and the build issues with lots of people installing scipy that will undoubtedly arise mostly fixed. What do you think? The timing will work out fine. We will begin getting all of our packages into the new format and put them on sage.math. Once you have the packages system reworked, we can't think about merging our spkgs with yours. Unfortunately I am leaving on a 2 week trip/vacation (up to the San Juans) starting the 21st, so the merging might not be able to take place until early August. But all of our spkgs should be on sage.math in the new format before then. Brian The src subdirectory here: http://modular.math.washington.edu/home/was/sage2.7/ has the latest version of my versions of packages. Most of the new work in SAGE-2.7 involves the fortran package, the scipy package, the lapack package, and changes to the standard SAGE Python library code. On many test systems it all does build and work together now. It doesn't work on powerpc OS X, but we've figured out how to fix that. -- 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/ -~--~~~~--~~--~--~---
