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. >> >> - 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.
