Yeah, do that. I'm not clear on what the actual suggestion is. Can you maybe give an example?
Aaron Meurer On Mon, Mar 26, 2012 at 11:49 PM, Jorge Cardona <[email protected]> wrote: > What do you think about the Z-notation? I would post it in a single > thread to see other comments. > > On Tue, Mar 27, 2012 at 1:46 AM, Aaron Meurer <[email protected]> wrote: >> 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. >> > > > > -- > 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.
