I wonder if we can take advantage of the low-level interpretation from a compiler to make the parsing easier, for example, LLVM's intermediate language. I haven't really studied that much, so I don't know if it would really be useful or not.
Aaron Meurer On Wed, Mar 21, 2012 at 9:36 AM, Matthew Rocklin <mrock...@gmail.com> wrote: > I think you're right that rebuilding everything that goes into a compiler is > far too much work for a GSoC student (or really this whole community). I > think that Andy is suggesting more local edits - surface level only. Lets > just walk through the code and see what simplifications we can make using > SymPy that gcc couldn't know about. We'll leave the actual compilation to > gcc/gfortran/javac/etc.... > > If we encounter something like a for loop we probably ignore it and just > look at what we can do to the expressions inside. We don't need to > understand all of the code, we're just trying to improve small pieces of > it. > > I don't think that code compilation should be a project though, I think that > parsing should be. I think that Andy's idea becomes feasible once SymPy can > read other code. Andy's idea is only one possible result of this though. A > good parsing module could make SymPy useful in a lot of new ways. > > Later today I'll put code parsing on the ideas page (if someone doesn't beat > me to it). > > > On Wed, Mar 21, 2012 at 2:26 AM, Joachim Durchholz <j...@durchholz.org> wrote: >> >> Am 20.03.2012 18:35, schrieb Andy Ray Terrel: >> >>> Well I was thinking more of taking a piece of c code, but it could be >>> take a python function, grab the code object and manipulate that. >>> >>> What I really want is to play around with symbolic code optimizations >>> and since we have quite a few tools to go from symbolics to code, it >>> seems easy to do simple things in the other directions. >> >> >> Real (non-toy) code contains extra stuff for handling error conditions, >> optimizing memory usage, etc. >> Extracting the real logic from all that sounds like it would be really, >> really hard. >> >> The other question is: what do you want to optimize for? >> Space? Time? Code size? >> What's your execution model - number of subroutine calls? Number of >> operator calls? How do you estimate the number of rounds spent in a loop (or >> the depth of a recursive call)? How do you estimate the size of data >> structures created? How do you determine how long some data structure will >> live? >> >> Not all of the questions are relevant for all optimization goals. >> This is going to be a good GSoC project if a goal is found that does not >> require answers to the ultra-hard questions. So the project should not be >> "optimize C functions" (that's a task for multiple lifetimes), but something >> more specific. With an implementation strategy, and an eye towards why this >> isn't going to require solving the halting problem or similarly hard things. >> >> >> > I realize >>> >>> this isn't super well formed but after seeing a number of these >>> symbolic executor papers, I think it is probably a good way to go. >> >> >> I haven't seen these papers. If they pick specific things that don't >> require doing hard stuff, this could be fun. >> Extra points if it is going to make SymPy more useful. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> 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 sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
