[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Thu, 23 Apr 2009 13:43:54 -0700 Ondrej Certik ond...@certik.cz wrote: On Thu, Apr 23, 2009 at 1:17 PM, Tim Lahey tim.la...@gmail.com wrote: On Apr 23, 2009, at 4:07 PM, William Stein wrote: Could you explain how assumptions are so important? Could you We already discussed this many times on this list, just search the archives. Without good assumptions, you cannot implement good integration, good solvers, good simplification, nothing. Of course, things like x+x is easy, but once you have for example Integral(complex expression involving many constants), sometimes you can simplify it, sometimes not and this very much depends on the assumptions for the constants. Or things like integrate(x**n, x). particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are ginac doesn't have any assumptions and so ginac doesn't have any advanced symbolic features. Of course, if the only thing that you are going to use ginac for is the core engine, then it should not matter much. But what I want from a CAS is to be able to do advanced symbolic calculations with symbols, so I need some way to tell it my assumptions about the symbols. Taking everything as complex numbers will not simplify things in many cases. particularly important in symbolic integration, which ginac doesn't do. Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? Because we attach assumptions to symbols, e.g. you define In [2]: x = Symbol(x, positive=True) and then you work with that: In [3]: sqrt(x**2) Out[3]: x In [4]: x = Symbol(x, negative=True) In [5]: sqrt(x**2) Out[5]: -x In [6]: x = Symbol(x) In [7]: sqrt(x**2) Out[7]: ╱ 2 ╲╱ x But this approach is the wrong one, because then the core engine has to take this into account and it slows things down. Our new system will keep the assumptions external, and define methods to work with them, like in mathematica, e.g. refine(). This should simplify the core and then we should be able to speed it up. Note that ginac has a similar mechanism, which it uses for the automatic simplifications it does. I haven't exposed this in the Sage interface. I don't know if Mike has either. Here is a list of the info flags ginac supports (Scroll down for the table): http://www.ginac.de/tutorial/Information-about-expressions.html Pynac has an infinity flag in addition to the ones listed there. I admit that I have no experience with general simplification routines, but I have the feeling that it all boils down to answering is_positive(), is_integer() queries about expressions. The trick is to be able to deduce the answers to these from a few bits of information gathered from the user. I don't know of any open source package which can provide this capability for Sage. I've heard that Reduce with its Redlog package is very powerful in this area. I doubt if it can be used from Sage though. Cheers, Burcin --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
Ondrej Certik wrote: On Wed, Apr 22, 2009 at 2:53 PM, Maurizio maurizio.gran...@gmail.com wrote: We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) PDE's are of course important, also it's my main research thing, but for sympy the assumptions are essential, because you cannot build a more advanced symbolics without a good assumption system. I am curious which approach Sage is going to use for this, since ginac doesn't have any assumptions. Is there anyone working on an assumptions framework in Sage? On the one hand, you can work in certain domains in Sage (i.e., polynomials over QQ, etc.), so some of this need may be taken care of there. But for a more general framework (like declaring that x0?) Hmmm...maybe we'll use sympy? :) Jason -- Jason Grout --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Thu, Apr 23, 2009 at 12:51 PM, Jason Grout jason-s...@creativetrax.com wrote: Ondrej Certik wrote: On Wed, Apr 22, 2009 at 2:53 PM, Maurizio maurizio.gran...@gmail.com wrote: We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) PDE's are of course important, also it's my main research thing, but for sympy the assumptions are essential, because you cannot build a more advanced symbolics without a good assumption system. I am curious which approach Sage is going to use for this, since ginac doesn't have any assumptions. Could you explain how assumptions are so important? Could you particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are particularly important in symbolic integration, which ginac doesn't do.Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? -- William Is there anyone working on an assumptions framework in Sage? On the one hand, you can work in certain domains in Sage (i.e., polynomials over QQ, etc.), so some of this need may be taken care of there. But for a more general framework (like declaring that x0?) Hmmm...maybe we'll use sympy? :) Jason -- Jason Grout -- 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 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: Indefinite Integration [WAS: programming: define a new function]
On Apr 23, 2009, at 4:07 PM, William Stein wrote: Could you explain how assumptions are so important? Could you particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are particularly important in symbolic integration, which ginac doesn't do.Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? -- William One place where I use assumptions regularly is with trig functions. If you have sin(n*pi) or cos(n*pi), stating the assumption that n is integer reduces the first to 0 and the second to alternating +1,-1. These crop up in modal analysis of physical systems regularly. I don't know if sympy's assumptions are suboptimal, since I haven't used sympy much, but I guess it is since they're planning on improvements. Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://www.linkedin.com/in/timlahey --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Thu, Apr 23, 2009 at 1:17 PM, Tim Lahey tim.la...@gmail.com wrote: On Apr 23, 2009, at 4:07 PM, William Stein wrote: Could you explain how assumptions are so important? Could you We already discussed this many times on this list, just search the archives. Without good assumptions, you cannot implement good integration, good solvers, good simplification, nothing. Of course, things like x+x is easy, but once you have for example Integral(complex expression involving many constants), sometimes you can simplify it, sometimes not and this very much depends on the assumptions for the constants. Or things like integrate(x**n, x). particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are ginac doesn't have any assumptions and so ginac doesn't have any advanced symbolic features. Of course, if the only thing that you are going to use ginac for is the core engine, then it should not matter much. But what I want from a CAS is to be able to do advanced symbolic calculations with symbols, so I need some way to tell it my assumptions about the symbols. Taking everything as complex numbers will not simplify things in many cases. particularly important in symbolic integration, which ginac doesn't do. Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? Because we attach assumptions to symbols, e.g. you define In [2]: x = Symbol(x, positive=True) and then you work with that: In [3]: sqrt(x**2) Out[3]: x In [4]: x = Symbol(x, negative=True) In [5]: sqrt(x**2) Out[5]: -x In [6]: x = Symbol(x) In [7]: sqrt(x**2) Out[7]: ╱ 2 ╲╱ x But this approach is the wrong one, because then the core engine has to take this into account and it slows things down. Our new system will keep the assumptions external, and define methods to work with them, like in mathematica, e.g. refine(). This should simplify the core and then we should be able to speed it up. -- William One place where I use assumptions regularly is with trig functions. If you have sin(n*pi) or cos(n*pi), stating the assumption that n is integer reduces the first to 0 and the second to alternating +1,-1. These crop up in modal analysis of physical systems regularly. I don't know if sympy's assumptions are suboptimal, since I haven't used sympy much, but I guess it is since they're planning on improvements. Exactly, all kinds of these assumptions, that are necessary for integration, simplifications, e.g. sometimes sqrt(x**2) reduces to x, sometimes to -x, sometimes to neither. Ondrej --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Tue, Apr 21, 2009 at 12:44 AM, mabshoff mabsh...@googlemail.com wrote: On Apr 21, 12:32 am, Robert Bradshaw rober...@math.washington.edu wrote: On Apr 20, 2009, at 11:44 PM, Maurizio wrote: Hi Michael, Actually, I thought that this discussion (especially people much more expert than me) has clarified the point that implementing integrals is not really just matter of a couple of months... but I would be glad to see this happen! Implementing something that can handle a huge number of integrals is a reasonable goal for a couple of months. Implementing something that can handle everything that we know how to handle in theory...well, that hasn't ever happened yet. Yep, certainly implementation are certainly better than other implementation here on average, but one could claim that neither Sympy nor Maxima are at the head of the class. Maxima can do many things, but often a little massaging is required by the user to get optimum results comparable to MMA for example. And I believe plainly and simply that this is not the role of the user of a CAS to be an exper at term maniplulation. If I write intgerate($FOO) I expect to get a correct answer without being required to transform the expression due to knowledge one has about the underlying implementation. I believe that too. I know there are some license issues with SymPy (not really issues, just differences probably) but I think there's no problem in taking inspiration and some pieces of code from it, right? There is a problem with just lifting code--but we can and do ship SymPy as part of Sage. Yes. One could take code from Sympy (the BSD license allows this) and make GPL ed changes on top of it. The main issue is just that our pattern matching engine via pynac will be more powerful, our Could you give some specific examples where the pynac pattern engine is more powerful? arithmetic is faster and the other abstract math bits in Sage are way more powerful than what is in Sympy. And the goal of Sympy is to be self contained and depending on certain operations in Sage is not an option and not wanted, so contributing such code back to Sympy is not We want sympy to run without Sage. But I have absolutely no problems calling Sage for certain things if it's available. In fact, I do want to call Sage if it's available. an option . There is the goal for Sympy to optionally depend on Pynac and use it when available, but no one is working on this, so this is not something we ought to be waiting for. Plainly and simply: Waiting on someone else to fix the problem for us has not worked, so we will do it ourselves. For the record, I offered William and you that I will work on this, if we manage to find funding for it over the summer. So just to be clear that I am very interested in this, and not just talking. But unfortunately I myself didn't find funding for it (and I haven't heard from you either that you found some possibility), so I had to find an internship somewhere else related more to my research (finite elements). We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. I'm saying this, because I can see this new symbolic stuff exciting, but without the right amount of interest on it, its development will always be a little slow Given that we ship SymPy, so anything it can handle we should be able to handle. I imagine when you want to integrate something, it will try to do it natively first, and that failing ask SymPy and/or maxima before returning a failure. Over time we'll depend less and less on the other two. Yep, that is the only way in my opinion. We control the Sage library and can coordinate releases with improvements in the Sage library - Sympy has not released as frequently as it used to be and unless someone steps up and helps Ondrej out I doubt that is going to change any time soon. We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) Besides, it will take almost a year to Sage too to release the new symbolics (started August 2008), so I don't think we are doing that bad. Also in terms of developers working just on symbolics, I think sympy has much more developers. I don't know if it's easy to extract just patches to Sage symbolics, to compare speeds of developments, but I would not be surprised if it turns out it's actually very comparable, or even less people are working on Sage symbolics than on sympy. That being said, I like that you pursue the pynac way, because first I also wanted to use ginac but using swig was just not the way, so William showed me with cython how to actually do it. And second, I welcome competition, because that's the only way to actually move forward, but for Sage and sympy. For example thanks to sympy, you completely abandoned your previous approach for symbolics, because after many months of
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Wed, Apr 22, 2009 at 9:08 AM, Ondrej Certik ond...@certik.cz wrote: welcome competition, because that's the only way to actually move forward, but for Sage and sympy. For example thanks to sympy, you but - both O. --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) That's definitely a very good thing, especially in getting people involved with development... Probably the best result is not just their short term, but also the chance of some long term commitment of good people. Besides, it will take almost a year to Sage too to release the new symbolics (started August 2008), so I don't think we are doing that bad. Also in terms of developers working just on symbolics, I think sympy has much more developers. I don't know if it's easy to extract just patches to Sage symbolics, to compare speeds of developments, but I would not be surprised if it turns out it's actually very comparable, or even less people are working on Sage symbolics than on sympy. That's a very good point. In my opinion, SAGE community is very good, and vast, and very well driven, but its focus it's actually quite far from symbolics (there's nothing bad about it), so I can see that for the time being, SymPy has some more inertia, thanks to the higher number of developers committed to symbolics (of course) rather than SAGE. At the same time, I think that SAGE can make a big step forward, once its community focuses on this task! Thanks a lot 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: Indefinite Integration [WAS: programming: define a new function]
On Wed, Apr 22, 2009 at 2:53 PM, Maurizio maurizio.gran...@gmail.com wrote: We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. How does assumptions affect this? If that's so important, you should probably get a lot of focus on that! But consider also PDE important ;) PDE's are of course important, also it's my main research thing, but for sympy the assumptions are essential, because you cannot build a more advanced symbolics without a good assumption system. I am curious which approach Sage is going to use for this, since ginac doesn't have any assumptions. We'll see. We managed to get 5 gsoc student this summer, so we are not at all dead, if this is what you mean. :) That's definitely a very good thing, especially in getting people involved with development... Probably the best result is not just their short term, but also the chance of some long term commitment of good people. Exactly. Getting people to work with you is absolutely essential, that's my priority number one. If you work alone, you cannot do anything in the long term. Ondrej --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
Hi Michael, Actually, I thought that this discussion (especially people much more expert than me) has clarified the point that implementing integrals is not really just matter of a couple of months... but I would be glad to see this happen! I know there are some license issues with SymPy (not really issues, just differences probably) but I think there's no problem in taking inspiration and some pieces of code from it, right? I'm saying this, because I can see this new symbolic stuff exciting, but without the right amount of interest on it, its development will always be a little slow Regards Maurizio On Apr 21, 1:12 am, mabshoff mabsh...@googlemail.com wrote: On Apr 20, 1:12 pm, Maurizio maurizio.gran...@gmail.com wrote: Hi Burcin, thanks for replying! SNIP I don't know what about those algorithms, but it seems to me that SymPy already implements some good heuristics, which can solve integrals that Mathematica can't. Well, there are many, many integrals that MMA can do that Sympy cannot. So it doesn't matter that in this specific case SymPy solves it. So can we take this as a starting point? I see that it is certainly possible to implement everything from the beginning, but a bootstrapped start seems better to me in the short term, because this could provide the user the functionalities needed. This could be useful to speed up the switch to the new symbolic system (I think you wouldn't do that without a good integration engine), and once there, you got a great exposure to bug fixing by users. Well, talking about it won't make it happen :). People working on Symbolics in Sage are well aware of Sympy and its capabilities, but it is BSD (i.e. some people won't work on it) and abstract mathematical capabilities aren't as well developed as in Sage and often quite a bit slower. Pynac is building Symbolics from the ground up and it has taken a while to get to where we are and another couple months more or less won't make a difference at this point. Thanks Maurizio Cheers, Michael --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Apr 20, 2009, at 11:44 PM, Maurizio wrote: Hi Michael, Actually, I thought that this discussion (especially people much more expert than me) has clarified the point that implementing integrals is not really just matter of a couple of months... but I would be glad to see this happen! Implementing something that can handle a huge number of integrals is a reasonable goal for a couple of months. Implementing something that can handle everything that we know how to handle in theory...well, that hasn't ever happened yet. I know there are some license issues with SymPy (not really issues, just differences probably) but I think there's no problem in taking inspiration and some pieces of code from it, right? There is a problem with just lifting code--but we can and do ship SymPy as part of Sage. I'm saying this, because I can see this new symbolic stuff exciting, but without the right amount of interest on it, its development will always be a little slow Given that we ship SymPy, so anything it can handle we should be able to handle. I imagine when you want to integrate something, it will try to do it natively first, and that failing ask SymPy and/or maxima before returning a failure. Over time we'll depend less and less on the other two. - Robert --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Apr 21, 12:32 am, Robert Bradshaw rober...@math.washington.edu wrote: On Apr 20, 2009, at 11:44 PM, Maurizio wrote: Hi Michael, Actually, I thought that this discussion (especially people much more expert than me) has clarified the point that implementing integrals is not really just matter of a couple of months... but I would be glad to see this happen! Implementing something that can handle a huge number of integrals is a reasonable goal for a couple of months. Implementing something that can handle everything that we know how to handle in theory...well, that hasn't ever happened yet. Yep, certainly implementation are certainly better than other implementation here on average, but one could claim that neither Sympy nor Maxima are at the head of the class. Maxima can do many things, but often a little massaging is required by the user to get optimum results comparable to MMA for example. And I believe plainly and simply that this is not the role of the user of a CAS to be an expert at term maniplulation. If I write intgerate($FOO) I expect to get a correct answer without being required to transform the expression due to knowledge one has about the underlying implementation. I know there are some license issues with SymPy (not really issues, just differences probably) but I think there's no problem in taking inspiration and some pieces of code from it, right? There is a problem with just lifting code--but we can and do ship SymPy as part of Sage. Yes. One could take code from Sympy (the BSD license allows this) and make GPL ed changes on top of it. The main issue is just that our pattern matching engine via pynac will be more powerful, our arithmetic is faster and the other abstract math bits in Sage are way more powerful than what is in Sympy. And the goal of Sympy is to be self contained and depending on certain operations in Sage is not an option and not wanted, so contributing such code back to Sympy is not an option . There is the goal for Sympy to optionally depend on Pynac and use it when available, but no one is working on this, so this is not something we ought to be waiting for. Plainly and simply: Waiting on someone else to fix the problem for us has not worked, so we will do it ourselves. I'm saying this, because I can see this new symbolic stuff exciting, but without the right amount of interest on it, its development will always be a little slow Given that we ship SymPy, so anything it can handle we should be able to handle. I imagine when you want to integrate something, it will try to do it natively first, and that failing ask SymPy and/or maxima before returning a failure. Over time we'll depend less and less on the other two. Yep, that is the only way in my opinion. We control the Sage library and can coordinate releases with improvements in the Sage library - Sympy has not released as frequently as it used to be and unless someone steps up and helps Ondrej out I doubt that is going to change any time soon. And by the way: the latest Symbolics code that is not yet available for review can already user either Sympy and/or Maxima to do integration. That code ought to be in Sage 4.0. - Robert Cheers, Michael --~--~-~--~~~---~--~~ 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: Indefinite Integration [WAS: programming: define a new function]
On Apr 20, 1:12 pm, Maurizio maurizio.gran...@gmail.com wrote: Hi Burcin, thanks for replying! SNIP I don't know what about those algorithms, but it seems to me that SymPy already implements some good heuristics, which can solve integrals that Mathematica can't. Well, there are many, many integrals that MMA can do that Sympy cannot. So it doesn't matter that in this specific case SymPy solves it. So can we take this as a starting point? I see that it is certainly possible to implement everything from the beginning, but a bootstrapped start seems better to me in the short term, because this could provide the user the functionalities needed. This could be useful to speed up the switch to the new symbolic system (I think you wouldn't do that without a good integration engine), and once there, you got a great exposure to bug fixing by users. Well, talking about it won't make it happen :). People working on Symbolics in Sage are well aware of Sympy and its capabilities, but it is BSD (i.e. some people won't work on it) and abstract mathematical capabilities aren't as well developed as in Sage and often quite a bit slower. Pynac is building Symbolics from the ground up and it has taken a while to get to where we are and another couple months more or less won't make a difference at this point. Thanks Maurizio Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
