On Mon, Mar 26, 2012 at 11:33 PM, Jorge Cardona <[email protected]> wrote: > On Tue, Mar 27, 2012 at 1:23 AM, Aaron Meurer <[email protected]> wrote: >> On Mon, Mar 26, 2012 at 10:52 PM, Jorge Cardona <[email protected]> >> wrote: >>> Hi >>> >>> I was playing with Aaron's code in integration3, I just added a little >>> example to the DifferentialExtension and tried to add the repr >>> function but I did't knew which of the data was important to be shown >>> here, and I used the original function, polys of numerator and >>> denominator and the list of derivation in the extension, all this is >>> not really ellaborated, everything is just following your comments on >>> the docstring of the class. >> >> Well, there are two choices for __repr__. You can initialize it with >> just the function and variable, as is done in risch_integrate. The >> rest will be recalculated in __init__. Or you can put in all the >> attributes (in other words, do the same thing as __str__ except wrap >> it with DifferentialExtension()). Given that this object is only used >> internally, I would go for the latter, as it is more helpful for >> debugging. Actually, I would just make __str__ do that, and let >> __repr__ be defined from it automatically. >> >>> >>> I was following the code with Manuel's book, and tried to merge the >>> code with the actual master but a lot of conflicts has convinced me to >>> stop trying it. >> >> Yeah, this wil be very non-trivial. For one thing, I renamed risch.py >> to heurisch.py, and called my new file risch.py, so git has no idea >> how to handle changes made to the master risch.py. So those changes >> have to be merged manually. >> >> When I get free time, I will make the merge with master and do the >> additional changes necessary to get it pushed in (mostly integrating >> risch_integrate() with integrate(), but there are a few other things >> as well). If a project to work on this code is accepted, I will make >> this a high priority. >> >> Aaron Meurer >> >>> >>> I thing then that one step in a possible gsoc with the Risch algorithm >>> is just to copy all the code from your branch to a brand new branch >>> from master. First just accomplishing all what your actual code can >>> made, and then start to work on the trigonometric extensions and >>> polish the code in readability and extreme cases. >>> >>> I don't really know if this is enough for a GSOC since it seems to be >>> just a copy-paste in a new branch project, then I was planning to add >>> something to the same proposal, there are two aspects that are >>> interesting for me: >> >> No, please don't copy-paste the code. That defeats the whole purpose >> of using git. Your patch to my branch will count for the requirement. >> > > I wasn't meaning to really copy and paste, just like copy-paste, since > is just to make it merge and basically all risch is complete now.
Oh, OK. I would actually consider counting this, since the merge is so non-trivial (and as I said, there are a handful of other things that have to be done before this can be pushed in). Aaron Meurer > >>> >>> - Z notation, I don't know if it fits on sympy, it suppose to be a >>> language to specify computing systems, but since its already an ISO >>> standard i imagine it most be easy to constraint as a gsoc project, >>> but also we can use maybe Z-notation to describe all the sympy >>> machinery someday. >>> >>> - I found interesting the discussion about the expression subclassing >>> and how must be done in a flexible way, and maybe I'm can naively >>> think that a good design for the expressions on sympy must be formally >>> stated and proved, and z-notation is the perfect way for it. I would >>> like to help on this, but I see a lot of parts in which the discussion >>> has relevance that I almost fear to state anything here, som bugs make >>> me think that a well defined structure for all the mathematical >>> objects in sympy is needed. I can see I high connection between bus >>> like: "1735: Rename .func attribute", "1688: Functions should be >>> objects", "1941: Objects that know how to combine themselves", "383: >>> Implement function composition" and all the set theory and high-order >>> logic project. I don't really know how to mix them together, but it >>> seems to me that there is a need for a big rethinking of the core from >>> the very basic definition of mathematical expressions, set-theory and >>> logic. Again, and maybe again naively a good perspective would be to >>> sit down and think in a Z-notation definition of the core. >>> >>> - A different option is to add to the project some more integration >>> algorithm as the residue theorem, but I haven't taken the course of >>> complex analysis and maybe the theory will kill me. >>> >>> Bye. >>> >>> More about Z-notation: http://spivey.oriel.ox.ac.uk/~mike/zrm/ >>> >>> On Mon, Mar 19, 2012 at 3:32 PM, Aaron Meurer <[email protected]> wrote: >>>> On Mon, Mar 19, 2012 at 9:15 AM, Jorge Cardona <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> Aaron, I was following your code for the risch algorithm, as you have >>>>> previously comment is basically chapters 6 in rde.py, 7 in prde.py and >>>>> 5 in risch.py, and some algorithm sparse in the book also in risch.py. >>>>> >>>>> There are a lot of "TODO" in the code, some nonimplemented exceptions, >>>>> and this comment on risch_integrate: >>>>> >>>>> Only transcendental functions are supported. Currently, only exponentials >>>>> and logarithms are supported, but support for trigonometric functions >>>>> is >>>>> forthcoming. >>>>> >>>>> That means that right now you can only built the differential >>>>> extension of the integrand for logarithms and exponential functions? I >>>>> didn't found actually a formal way to built this on Bronstein's book, >>>>> I imagine it must be then a well know problem. since is just the >>>>> starting point for Risch Algorithm according to the section 5.2. Also >>>>> I can't connect in my head right now the relation of that problem with >>>>> the structure theorems in chapter 9. >>>> >>>> Yes, that's what it means. >>>> >>>> Bronstein's book describes this, but this is one of the few algorithms >>>> he does not give pseudocode for. Rather, the algorithm is partly what >>>> is explained in the first part of section 5.2 and partly the results >>>> of the structure theorems from chapter 9. >>>> >>>> Basically, you recursively take the exponential and logarithmic parts >>>> of an expression, and that is your extension. So if you have >>>> >>>> log(exp(x) + 1)*log(x), your extension would be QQ(x, log(x), exp(x), >>>> log(exp(x) + 1)) (the log(x) could actually go anywhere in the >>>> extension, the only important thing is that exp(x) is added before >>>> log(exp(x) + 1)). The reason why you have to have the structure >>>> theorems is that each extension must be transcendental over the >>>> others. For example, if you have >>>> >>>> log(x)*log(2*x), you cannot use QQ(x, log(x), log(2*x)), because >>>> log(2*x) is not transcendental over C(log(x)) (because log(2*x) == >>>> log(2) + log(x)). Here, C = const(QQ(x, log(x)) (i.e., we don't care >>>> that log(2) is transcendental over QQ; extending the constant field is >>>> not an issue). As another example, you cannot integrate exp(log(x)/2) >>>> with the algorithm, because this function is really x**(1/2), which is >>>> algebraic. The structure theorems will discover this for you, because >>>> when you try to add exp(log(x)/2) to QQ(x, log(x)), it will find the >>>> relation exp(log(x)/2)**2 = x, proving that exp(log(x)/2) is algebraic >>>> over QQ(log(x)). >>>> >>>>> >>>>> I will like to know then if a possible project on the Risch algorithm >>>>> would be planned on solve those "TODO" comments, and polish the code >>>>> to an easy merge with master? >>>> >>>> Well, you could look at it that way. If I remember correctly, I >>>> basically have TODOs for everything that needs to be done, including >>>> stuff like "TODO: implement support for trig extensions". >>>> >>>>> >>>>> Sadly I found hard to follow some aspects in the code, but the >>>>> comments help a lot, I will try to find some possible patch of your >>>>> code. >>>> >>>> The code will be very hard to follow unless you follow along in >>>> Bronstein's book. I think with the exception of the algorithm you >>>> described above (currently implemented in >>>> DifferentialExtension.__init__), and the loop in risch_integrate(), >>>> all the algorithms come straight from pseudocode in Bronstein's book >>>> (those are exceptions simply because Bronstein didn't include explicit >>>> pseudocode for them in his book, but rather just plain English >>>> descriptions). >>>> >>>> I won't lie to you: the easy parts of this algorithm have for the >>>> most part already been implemented. The majority of what remains >>>> comes from implementing the algorithms that are only described in >>>> plain English in his book. >>>> >>>> My best advice to you is to read through Bronstein's book, in order, >>>> and when you come across pseudocode, look it up in my branch to see >>>> how it is implemented. The pseudocodes from chapter 1 are all >>>> essential to the polys, and is implemented there (your best bet to >>>> find them is to grep the repository). Chapter 2 describes the >>>> rational integration algorithm, which is entirely implemented already >>>> in sympy/integrals/rationaltools.py. Only about half the pseudocode >>>> is implemented there, because the other half are less efficient >>>> algorithms given only for instructive purposes. Chapter 3 and chapter >>>> 4 are theoretical, and contain almost no pseudocode. These will be >>>> necessary if you want to understand the proofs of the later theorems, >>>> but if you don't care about that, you can probably get away with just >>>> skimming them, and making sure you at least understand the >>>> definitions. I've already told you about chapters 5-7. Chapter 8 >>>> relates to the algorithm for integrating trig functions, which hasn't >>>> been implemented at all yet. Chapter 9 is about the structure >>>> theorems. That chapter is very technical. You could probably just get >>>> away with just looking at the statement of the theorems at this point. >>>> >>>> When you come across pseudocode, try to play around with the functions >>>> interactively to see how they work. An idea for something you could >>>> so, which is not a TODO so much as I remember, would be to write >>>> doctests for all the internal functions in the Risch algorithm. >>>> Basically, you should try to find a simple yet instructive example, >>>> and put it in the docstring as >>>> >>>>>>> from sympy.integrals.risch import whatever_function >>>>>>> whatever_function(example) >>>> result >>>> >>>> This will help you learn how things work, and will also help future >>>> people learn how they work as well. >>>> >>>> Aaron Meurer >>>> >>>>> >>>>> Are there some sympy tools to work with algebraic structures as rings, >>>>> fields, extensions, and more? There are some on the polys module but >>>>> there is somethign like a Ring class, and Extension? >>>> >>>> Yes, these are the domains. When you create a Poly, the domain is >>>> inferred automatically, but you can also provide one explicitly. For >>>> extensions, the support is limited. Only algebraic number extensions >>>> are supported (as opposed to algebraic functions), and they can get >>>> quite slow as you extend by more than a few numbers. >>>> >>>> Aaron Meurer >>>> >>>>> >>>>> Bye. >>>>> >>>>> -- >>>>> Jorge Eduardo Cardona >>>>> [email protected] >>>>> jorgeecardona.blogspot.com >>>>> github.com/jorgeecardona >>>>> ------------------------------------------------ >>>>> Linux registered user #391186 >>>>> Registered machine #291871 >>>>> ------------------------------------------------ >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "sympy" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/sympy?hl=en. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "sympy" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/sympy?hl=en. >>>> >>> >>> >>> >>> -- >>> Jorge Eduardo Cardona >>> [email protected] >>> jorgeecardona.blogspot.com >>> github.com/jorgeecardona >>> ------------------------------------------------ >>> Linux registered user #391186 >>> Registered machine #291871 >>> ------------------------------------------------ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> > > > > -- > Jorge Eduardo Cardona > [email protected] > jorgeecardona.blogspot.com > github.com/jorgeecardona > ------------------------------------------------ > Linux registered user #391186 > Registered machine #291871 > ------------------------------------------------ > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
