[sage-devel] Re: plot float arguments
On Mar 22, 2:54 am, Jason Grout jason-s...@creativetrax.com wrote: I think the main reason is to give *massive* speedups (i.e., orders of magnitude). Can you post an example of the problems you are experiencing? I thought plotting are just some arithmetical operations for around hundret points, why can it slow down so much by using RR or QQ? Or do the functions to be plotted consume the most of the time if they are not computed with floats? As I now see, the problem might not have directly to do with truncation to floats, I provide the following simple example: parametric_plot((lambda x: log(x),lambda x: log(x)**2),(2**(-50),0.5)) this has an ugly break a bit below x=-10. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] difference between repr and print
sage: a = float(1-2**(-50)) sage: repr(a) '0.99911' sage: print(a) 1.0 Is that intended? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: difference between repr and print
On Mar 22, 3:03 am, Henryk Trappmann bo198...@googlemail.com wrote: sage: a = float(1-2**(-50)) sage: repr(a) '0.99911' sage: print(a) 1.0 Is that intended? This is Python's default behavior. repr uses 17 digits of precision while str only uses 12. It is covered in the Python tutorial: http://docs.python.org/tutorial/floatingpoint.html --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
I'm not really familiar with Reduce, and am not a CAS developer. I am a kind of interested observer and I try to be helpful by collecting info about existing CAS systems and ideas and submitting links to the experts - you guys. Since I am alot more familiar with physics/engineering/numerical applications, I wonder if you think it would be a good idea to maintain a version of Sage geared towards these types of applications, especially now that Scilab and Reduce have been released as GPL- compatible. Cheers, Hazem Thank you very much Hazem Honestly, I'm not aware of REDUCE capabilities, but I totally share Hazem's point of view. Just having a look at that article, I can see some interest for us to share (for example) the Z-transform features of REDUCE with any scientist/engineer out there. I'm not saying we should include REDUCE, also because I don't know whether maxima guys at least made z transform available, but I think we should at least consider taking some advantage from their open source code, especially if we are now working so hard in our own symbolic package. Could pynac take advantage of this? Regards Maurizio --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE possible improvement
On Mar 20, 10:31 pm, Jason Grout jason-s...@creativetrax.com wrote: Maurizio wrote: Not yet... I think I was previously asking whether some of you guys are interested in trying to contact them, if you do think it does makes sense. I mean, if this community is interested in having this feature, the Quantities developers are going to find some good feedback, otherwise, we could just probably end up losing a good occasion, because things are not ready yet (although I hope that's not the case)! I think there are a good number of people now that would like to have the feature, and as you well know, there are lots and *lots* of future users that would like to have the functionality. I'd say it's time to contact them and see if they can help. If there needs to be changes made to Quantities, then making them now, while it is still solidifying, would be advantageous. Hello, I am Darren Dale, the developer of Quantities. Thank you Maurizio for contacting me. I would like to request that discussions concerning Quantities on this list also be sent to my gmail account. My work will keep me very busy for the next 10 weeks, and since it seems this list gets a fair amount of traffic and I am not yet a sage user, I would prefer not to follow the list too closely, at least for now. Let me explain my background and that of quantities. I am a scientist at the Cornell High Energy Syncrotron Source (CHESS), and have been a developer on the matplotlib project for several years. I have been interested in having a units package for python for a long time. I have considered all the units packages discussed so far in this thread, but did not find one that suited my needs. I make heavy use of numpy arrays for my work, and wanted a numpy subclass that handled physical quantities. It has taken several iterations but I finally found an appropriate abstraction for such a package. Quantities is already in pretty good shape, in large part because it does not try to do too much. I am currently trying to improve Quantities interaction with numpy's builtin functions, however, I have run into some limitations in numpy, mainly in the implementation of ufuncs. If you are interested, please search the numpy archives for my name. I have suggested on that list how things could be improved, but the devs are busy preparing to release numpy-1.3. I will try to engage them again after 1.3 is out. I have been spending most of my effort on Quantities recently improving the unit tests. This uncovered a few bugs in numpy that have been fixed in time for the 1.3 release. If you run pq.test() with numpy-1.2, you will encounter errors that have been fixed in 1.3. I would be willing to consider how quantities can be improved so it can be used in the sage environment, but it sounds like there are some existing issues with the interaction of sage types and numpy arrays which need to be worked out first. Have I understood correctly? I have been meaning to change addition/subtraction in Quantities to allow things like m+cm without explicitly rescaling one of the operands. I will change it so the result has the same units as the left operand. I am not interested implementing the feature proposed in post #16 in this thread. Dealing with physical quantities can be somewhat thorny, because there are lots of use cases and everybody seems to have their own ideas about how it should behave. Case in point, the proposal in post #16 would keep units the way you like them for scalars, but it would create additional overhead in cases like 1m-0.99m. In that case, I guess the proposed behavior would be to yield 1um as the result, which means quantities would have to a) determine the appropriate final unit and b) would have to perform additional arithmetic. Quantities is not really designed to handle item a. I've tried to keep the package as simple as possible in order to keep the problem tractable in my limited free time. Item b would be unacceptable to those concerned about speed. Automatically rescaling the result becomes more complicated with arrays, since you would then have to inspect the min, max or mean in order to determine how to rescale the output, and there are plenty of compound operations sqrt(x +y**3/(...)...) where the user would only be interested in rescaling the final result, not the result of each individual step of arithmetic. There are plenty of examples, like operations involving constants for quantum mechanics or astrophysics, where the user wants the result in the units specified by the constants. I guess the question I have for this list is, what would be required for quantities to work in sage? I would prefer to try to work out the numpy issues I alluded to before quantities gets too much exposure, in case changes in API are required (unlikely). Darren --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to
[sage-devel] Re: plot float arguments
On Sun, Mar 22, 2009 at 3:55 AM, Henryk Trappmann bo198...@googlemail.com wrote: Another evil example: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2), (-1000,1000)) It seems that the plot algorithm is somehow deficient in those cases. In both cases, it's plotting points approximately evenly spaced throughout the given range; since the functions being plotted are very nonlinear, this gives bad results here. You can use marker= to see what's going on: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-1000,1000),marker='.') You can get a nicer plot by either increasing the plot_points, or decreasing the range: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-1000,1000),marker='.', plot_points=1) parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-10,10),marker='.') Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: FInally the link to download SAGElwlcd ISO!
On Sun, Mar 22, 2009 at 5:35 AM, Lucio Lastra luciolas...@gmail.com wrote: 4) Before I built this .iso I downloaded and tried Alfredo's 3.2.2 version. The point is that when you boot it up it consumes around 510 Mibs RAM (you can check it typing free at the command line). After you drop caches (as root in the terminal echo 3 /proc/sys/vm/drop_caches) it sticks around 310 Mibs RAM and that's it, unless you start killing processes it won't get lower. This is something that could have been addressed, if some feedback had been provided. That's one of the reasons it uses fluxbox and not xfce and when it boots up consumes around 382 Mibs and after you drop the caches it sticks in 215 Mibs. That's also why the menu is so minimal, I swear even my grandma could run sage and not get lost among the icons and that kind of stuff. Also one of the coolest things about fluxbox is that you can mod the menu as you want and it does reflect the changes just after you saved the menu file. The previous version *never* ran in xfce. The 3.4 version is the first one. The previous version uses the power hungry Ubuntu. The current 3.4 version consumes 404MB after booting. The menu creation is trivial because you *dont* have to edit files. My ideal distro for a LiveCD would be Arch, which I can probably have with a *full* desktop (gnome or KDE) with 300 MB. Finally don't worry about plagiarism, the construction of my .iso is based upon a total different process than Alfredo's. You can see the whole instructions to build it in the sagelwlcd.tar.gz file which can be downloaded from the link I posted you in point 3) The process to build the LiveCD with linux live scripts is the simplest I have found. It makes it trivial to make a LiveCD. Plus it contains a custom kernel to deal with no open source wireless cards drivers, etc. Again my points are not to discourage anybody to find better ways, but it would have been nice some feedback. Regards, Alfredo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: plot float arguments
On Mar 22, 3:45 pm, Carl Witty carl.wi...@gmail.com wrote: You can get a nicer plot by either increasing the plot_points, or decreasing the range: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-1000,1000),marker='.', plot_points=1) parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-10,10),marker='.') But I think that should be automatically handled by parametric_plot. You just can look at the angle at each inner point of the curve and if they are too much off from 180 degree you insert new points left and right of that point. Of course only if the points are not already close, to support non- smooth curves as well. I just wrote that myself. With the other advantage that also higher than float precision input works. It would be very cumbersome to manually adapt the number of plot_points for every single plot. And usually changing the range of a curve is not an option. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: FInally the link to download SAGElwlcd ISO!
Hi Alfredo and Lucio, Thanks to both of you for your very informative replies and all your great work on LiveCD's. I can imagine places with minimal hardware and minimal (or no) network access where these CD's (or USB drive installations) could be an invaluable help in the study of mathematics and a great way to spread Sage to an even larger base of users. When Lucio's project was posted, I'd forgotten all about Alfredo's work, which is why I inspected what Lucio had done and sent some feedback. And I can see now that you both have the same aims with slightly different routes to solutions. So perhaps the best of both can come together to make a super-lightweight and very easy-to-use version of Sage. If I can be of further help with testing, just holler. I'd like to support what you are doing since I think it is another key piece of promoting Sage. Thanks again for your efforts. Rob --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Encoding in the notebook, and I18N
In trying to use the notebook in spanish, there's something broken with the encoding which prevents using non-ascii characters. For example, if one changes the title of a worksheet to something with non-ascii characters, it seems to work at first, but when going back to the list of worksheets the title will display wrongly. I've investigated a bit, and the good news is, I think this must be pretty easy to fix, because is't *just* an issue with encodings. In fact, the notebook seems to be unicode-safe, except for the html serving: it's just that firefox *thinks* the html served by the notebook is in latin-1 encoding (iso-8859-1), but it is in fact in utf-8 encoding. Manually changing the encoding makes the page render ok (accents and all look good). Thus, the fix that is required is the following: a) add a Content-Type: text/html; charset=utf-8 header to the HTTP response given by twisted. This is probably the best and easier to implement --- I just couldn't find where to do it in the notebook source, but it must be easy for someone familiar with notebook code. b) alternatively, add a line meta http-equiv=Content-Type content=text/html; charset=utf-8 / to the head section of every page served by the notebook. This I could do by changing templates and searchreplace in the notebook source, etc... I wouldn't be sure to catch all instances, and in general I think (a) is preferrable. Gonzalo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
Hi Maurizio, On Sun, Mar 22, 2009 at 11:06 AM, Maurizio maurizio.gran...@gmail.com wrote: SNIP Honestly, I'm not aware of REDUCE capabilities, but I totally share Hazem's point of view. Just having a look at that article, I can see some interest for us to share (for example) the Z-transform features of REDUCE with any scientist/engineer out there. I'm not saying we should include REDUCE, also because I don't know whether maxima guys at least made z transform available, but I think we should at least consider taking some advantage from their open source code, especially if we are now working so hard in our own symbolic package. As regards a Maxima package for z transform, I think Alasdair McAndrew has written such a package about 2 years ago. You might want to search through the Maxima site, or email Alasdair yourself. He's a friendly person as far as I know, and he'll be happy to answer your query. But be warned that he's a very busy person. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
On Mar 22, 2009, at 9:37 PM, Minh Nguyen wrote: I don't think that maintaining another version of Sage is the way to go at the moment, since many developers have enough on their hands and little time to implement them. What I think is appropriate is to write a Sage interface to your favourite physics/engineering/numerical system, package your interface as an spkg, and announce your spkg on the sage-devel mailing list. A list of current spkg can be found at In my mind, what's generally necessary for engineering purposes is a) examples of Sage used for engineering and b) consistency across the various interfaces. Right now, one pretty much has to choose if you're going to work with polynomials or with symbolics. It would be nice if you could take a polynomial you've defined with Pynac, use the fast polynomial routines and go back to the Pynac routines for the other operations. Plus, there hasn't been a way to do integration with the Pynac symbolics. Cheers, Tim. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
Thank you all for your feedback. I agree that maintaining anoher version of Sage is probably spreading current resources too thin. I was asking to see if this was indeed the case. On the other hand, an engineering and physics oriented Sage could help boost Sage and bring in more resources from a largely untapped and enthusiastic audience. We would be competing more directly with Mathematica in particular, and other packages (MATLAB, etc.) in general, and making alot of waves and getting more attention that way. We could start simply by packaging a version of Sage that is smaller and drops most of the parts that are not widely used by most applied scientists and engineers, and emphasizes other packages and capabilities found in MATLAB for example. Documentation would necessarily have to be written or adapted with applied scientists in mind, and an aggressive promotion campaign among users of commercial computation software would be necessary. This version of Sage would be based on the main version, but would be a subset of it for simplicity's sake, more or less, with some optional packages treated as standard. It would be important not to include packages that have overlapping functionality, but choose only one of them. The distribution must be kept relatively small both for size and to keep it less confusing to a newbie. More integration would come with time. One great selling feature would be Cython, which provides the possibility to achive high computation speeds coupled with a nice and clean programming language. This is a big consideration for engineers and applied scientists and it is noteworhy that Python already has a growing user base among them. With Scilab we can even offer a MATLAB- like language as an option or as part of a mixed environment. Symbolic capabilties can be handled by a subset of the packages already offered (or soon to be offered) by Sage. I know what you are going to say: Hazem, whya don't you do it? I would love to, but honestly my time does not permit, even if I knew how to do it. I will keep it i mind, though. We can advertise for volunteers to take over and run the project, at least. best regards, Hazem On Mar 22, 9:45 pm, Tim Lahey tim.la...@gmail.com wrote: On Mar 22, 2009, at 9:37 PM, Minh Nguyen wrote: I don't think that maintaining another version of Sage is the way to go at the moment, since many developers have enough on their hands and little time to implement them. What I think is appropriate is to write a Sage interface to your favourite physics/engineering/numerical system, package your interface as an spkg, and announce your spkg on the sage-devel mailing list. A list of current spkg can be found at In my mind, what's generally necessary for engineering purposes is a) examples of Sage used for engineering and b) consistency across the various interfaces. Right now, one pretty much has to choose if you're going to work with polynomials or with symbolics. It would be nice if you could take a polynomial you've defined with Pynac, use the fast polynomial routines and go back to the Pynac routines for the other operations. Plus, there hasn't been a way to do integration with the Pynac symbolics. Cheers, Tim. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
Forgot to add that we would need to include some kind of spreadsheet- like capability, which is quite useful and convenient when one wants to create/edit matrices and arrays. Hazem On Mar 22, 11:23 pm, Hazem hazem.biqa...@gmail.com wrote: Thank you all for your feedback. I agree that maintaining anoher version of Sage is probably spreading current resources too thin. I was asking to see if this was indeed the case. On the other hand, an engineering and physics oriented Sage could help boost Sage and bring in more resources from a largely untapped and enthusiastic audience. We would be competing more directly with Mathematica in particular, and other packages (MATLAB, etc.) in general, and making alot of waves and getting more attention that way. We could start simply by packaging a version of Sage that is smaller and drops most of the parts that are not widely used by most applied scientists and engineers, and emphasizes other packages and capabilities found in MATLAB for example. Documentation would necessarily have to be written or adapted with applied scientists in mind, and an aggressive promotion campaign among users of commercial computation software would be necessary. This version of Sage would be based on the main version, but would be a subset of it for simplicity's sake, more or less, with some optional packages treated as standard. It would be important not to include packages that have overlapping functionality, but choose only one of them. The distribution must be kept relatively small both for size and to keep it less confusing to a newbie. More integration would come with time. One great selling feature would be Cython, which provides the possibility to achive high computation speeds coupled with a nice and clean programming language. This is a big consideration for engineers and applied scientists and it is noteworhy that Python already has a growing user base among them. With Scilab we can even offer a MATLAB- like language as an option or as part of a mixed environment. Symbolic capabilties can be handled by a subset of the packages already offered (or soon to be offered) by Sage. I know what you are going to say: Hazem, whya don't you do it? I would love to, but honestly my time does not permit, even if I knew how to do it. I will keep it i mind, though. We can advertise for volunteers to take over and run the project, at least. best regards, Hazem On Mar 22, 9:45 pm, Tim Lahey tim.la...@gmail.com wrote: On Mar 22, 2009, at 9:37 PM, Minh Nguyen wrote: I don't think that maintaining another version of Sage is the way to go at the moment, since many developers have enough on their hands and little time to implement them. What I think is appropriate is to write a Sage interface to your favourite physics/engineering/numerical system, package your interface as an spkg, and announce your spkg on the sage-devel mailing list. A list of current spkg can be found at In my mind, what's generally necessary for engineering purposes is a) examples of Sage used for engineering and b) consistency across the various interfaces. Right now, one pretty much has to choose if you're going to work with polynomials or with symbolics. It would be nice if you could take a polynomial you've defined with Pynac, use the fast polynomial routines and go back to the Pynac routines for the other operations. Plus, there hasn't been a way to do integration with the Pynac symbolics. Cheers, Tim. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
Hi Hazem, On Mon, Mar 23, 2009 at 3:28 AM, Hazem hazem.biqa...@gmail.com wrote: Forgot to add that we would need to include some kind of spreadsheet- like capability, which is quite useful and convenient when one wants to create/edit matrices and arrays. Yes, there has been discussion about this on sage-devel, and maybe on sage-support. From memory, some folks have posted proof-of-concept stuff, but I may be wrong. I think David Joyner is one of the people who have worked on a spreadsheet-like capability. Hazem On Mar 22, 11:23 pm, Hazem hazem.biqa...@gmail.com wrote: Thank you all for your feedback. I agree that maintaining anoher version of Sage is probably spreading current resources too thin. I was asking to see if this was indeed the case. On the other hand, an engineering and physics oriented Sage could help boost Sage and bring in more resources from a largely untapped and enthusiastic audience. We would be competing more directly with Mathematica in particular, and other packages (MATLAB, etc.) in general, and making alot of waves and getting more attention that way. We could start simply by packaging a version of Sage that is smaller and drops most of the parts that are not widely used by most applied scientists and engineers, and emphasizes other packages and capabilities found in MATLAB for example. Documentation would necessarily have to be written or adapted with applied scientists in mind, and an aggressive promotion campaign among users of commercial computation software would be necessary. This version of Sage would be based on the main version, but would be a subset of it for simplicity's sake, more or less, with some optional packages treated as standard. It would be important not to include packages that have overlapping functionality, but choose only one of them. The distribution must be kept relatively small both for size and to keep it less confusing to a newbie. More integration would come with time. Since the Windows port of Sage is currently underway and in its early stages, perhaps anyone who actually considers features and packages for physics/engineering/numerical stuff might consider working on those packages first in the Windows port. I'm saying this because the Windows port is rather small at the moment, something like 70MB at the moment with version 0.3.3. So while it's still small and manageable, one might be able to support engineering capabilities. Furthermore, because Windows is more familiar to many engineers (I may be wrong here), supporting engineering features in the Windows port is a good idea. For more info on the Windows port, please refer to this site: http://windows.sagemath.org/ One great selling feature would be Cython, which provides the possibility to achive high computation speeds coupled with a nice and clean programming language. This is a big consideration for engineers and applied scientists and it is noteworhy that Python already has a growing user base among them. With Scilab we can even offer a MATLAB- like language as an option or as part of a mixed environment. Symbolic capabilties can be handled by a subset of the packages already offered (or soon to be offered) by Sage. I know what you are going to say: Hazem, whya don't you do it? I would love to, but honestly my time does not permit, even if I knew how to do it. I will keep it i mind, though. From my perspective, there are many things I want to implement at the moment and I have at least 3 hrs per day to work on Sage, but I don't have necessary resources. So in a sense, I sort of understand what you're saying here. As regards Scilab and Sage, I think that Ronan Paixão has worked on a Sage-Scilab interface. From my reading of the Scilab license, I think it can be legally problematic to include Scilab in Sage, but I'm not a lawyer. David Joyner knows more about software licenses than I do. We can advertise for volunteers to take over and run the project, at least. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: REDUCE now available under BSD-like license
On Mar 22, 11:48 pm, Minh Nguyen nguyenmi...@gmail.com wrote: Hi Hazem, On Mon, Mar 23, 2009 at 3:28 AM, Hazem hazem.biqa...@gmail.com wrote: Forgot to add that we would need to include some kind of spreadsheet- like capability, which is quite useful and convenient when one wants to create/edit matrices and arrays. Yes, there has been discussion about this on sage-devel, and maybe on sage-support. From memory, some folks have posted proof-of-concept stuff, but I may be wrong. I think David Joyner is one of the people who have worked on a spreadsheet-like capability. Sage-applied (what I use to refer to the proposed distribution) does not need to have this in the first few versions, but it should be high on the list of priorities. I wonder if code from Gnumeric or calc can be adapted. On Mar 22, 11:23 pm, Hazem hazem.biqa...@gmail.com wrote: Thank you all for your feedback. I agree that maintaining anoher version of Sage is probably spreading current resources too thin. I was asking to see if this was indeed the case. On the other hand, an engineering and physics oriented Sage could help boost Sage and bring in more resources from a largely untapped and enthusiastic audience. We would be competing more directly with Mathematica in particular, and other packages (MATLAB, etc.) in general, and making alot of waves and getting more attention that way. We could start simply by packaging a version of Sage that is smaller and drops most of the parts that are not widely used by most applied scientists and engineers, and emphasizes other packages and capabilities found in MATLAB for example. Documentation would necessarily have to be written or adapted with applied scientists in mind, and an aggressive promotion campaign among users of commercial computation software would be necessary. This version of Sage would be based on the main version, but would be a subset of it for simplicity's sake, more or less, with some optional packages treated as standard. It would be important not to include packages that have overlapping functionality, but choose only one of them. The distribution must be kept relatively small both for size and to keep it less confusing to a newbie. More integration would come with time. Since the Windows port of Sage is currently underway and in its early stages, perhaps anyone who actually considers features and packages for physics/engineering/numerical stuff might consider working on those packages first in the Windows port. I'm saying this because the Windows port is rather small at the moment, something like 70MB at the moment with version 0.3.3. So while it's still small and manageable, one might be able to support engineering capabilities. Furthermore, because Windows is more familiar to many engineers (I may be wrong here), supporting engineering features in the Windows port is a good idea. For more info on the Windows port, please refer to this site: http://windows.sagemath.org/ I don't think that would be the best way to go about it. For one thing, Linux is quite popular in scientific circles, and for another, I don't want to promote a big split between Sage-main and Sage- applied. The starting point should be the same, and if we end up with 2 Sage-Windows distributions, then so be it. One great selling feature would be Cython, which provides the possibility to achive high computation speeds coupled with a nice and clean programming language. This is a big consideration for engineers and applied scientists and it is noteworhy that Python already has a growing user base among them. With Scilab we can even offer a MATLAB- like language as an option or as part of a mixed environment. Symbolic capabilties can be handled by a subset of the packages already offered (or soon to be offered) by Sage. I know what you are going to say: Hazem, whya don't you do it? I would love to, but honestly my time does not permit, even if I knew how to do it. I will keep it i mind, though. From my perspective, there are many things I want to implement at the moment and I have at least 3 hrs per day to work on Sage, but I don't have necessary resources. So in a sense, I sort of understand what you're saying here. As regards Scilab and Sage, I think that Ronan Paixão has worked on a Sage-Scilab interface. From my reading of the Scilab license, I think it can be legally problematic to include Scilab in Sage, but I'm not a lawyer. David Joyner knows more about software licenses than I do. My understanding is that the current Scilab is licenced under CeCILL, which is GPL-compatible. We can advertise for volunteers to take over and run the project, at least. Perhaps we can get an outside sponsor for this project? -- Regards Minh Van Nguyen Thanks Minh, Hazem --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To
[sage-devel] email notification on trac disabled?
For a while now, I haven't been receiving email notifications of changes in trac tickets. Has the notification option been turned off? Can we turn it back on? I notice that it's off by default http:// trac.sagemath.org/sage_trac/wiki/TracNotification, so maybe the default setting is being used now. John --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: email notification on trac disabled?
On Sun, Mar 22, 2009 at 10:21 PM, John H Palmieri jhpalmier...@gmail.com wrote: For a while now, I haven't been receiving email notifications of changes in trac tickets. Has the notification option been turned off? Can we turn it back on? I notice that it's off by default http:// trac.sagemath.org/sage_trac/wiki/TracNotification, so maybe the default setting is being used now. The current trac.sagemath.org mail notification section is the following: [notification] always_notify_owner = true always_notify_reporter = true always_notify_updater = true mime_encoding = base64 smtp_always_bcc = smtp_always_cc = sage-t...@googlegroups.com smtp_default_domain = smtp_enabled = true smtp_from = t...@math.washington.edu smtp_password = smtp_port = 25 smtp_replyto = wst...@math.washington.edu smtp_server = euler.math.washington.edu smtp_user = use_public_cc = false use_short_addr = false use_tls = false --- Nobody has changed the above recently. I did try restarting trac a few days ago, but that didn't resolve this problem. My best guess is that one of the UW math department machines has been changed so that it no longer accepts emails from the trac server, though it did a week ago. This possibility is I suppose consistent with the math machines having been rebooted / restructed some recently (?). I don't remember who setup the above. Was it Robert Bradshaw? My best guess for what to try next is to configure an smtp server directly on sagemath and set smtp_server to equal that instead of euler.math.washington.edu. But I want to wait until h...@math responds. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
